《HTTP权威指南》三四章

最新推荐文章于 2023-10-30 01:58:31 发布

Even

最新推荐文章于 2023-10-30 01:58:31 发布

阅读量914

点赞数

分类专栏： HTTP

本文链接：https://blog.csdn.net/cqlf__/article/details/41450939

版权

HTTP 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

第三章。HTTP报文

• 报文是如何流动的；
• HTTP 报文的三个组成部分（起始行、首部和实体的主体部分）；
• 请求和响应报文之间的区别；
• 请求报文支持的各种功能（方法）；
• 和响应报文一起返回的各种状态码；
• 各种各样的 HTTP 首部都是用来做什么的。

报文的流动：

流入 inbound

流出 outbound

报文的流动图：

HTTP报文的三个部分

请求报文和响应报文的区别：

请求报文的格式：

    
    
     
     
      
      <method> <request- URL> <version>
     
     
     
     
      
      <headers>
     
     
     
     
      
      <entity- body>

响应报文的格式：

     
     
      
      
       
       <version> <status> <reason- phrase>
      
      
      
      
       
       <headers>
      
      
      
      
       
       <entity- body>

一组 HTTP 首部总是应该以一个空行（仅有 CRLF）结束，甚至即使没有首
部和实体的主体部分也应如此。但由于历史原因，很多客户端和服务器都在没有实
体的主体部分时，（错误地）省略了最后的 CRLF。为了与这些流行但不符合规则的
实现进行互通，客户端和服务器都应该接受那些没有最后那个 CRLF 的报文。

请求报文的常见method

响应报文的状态码分类：

版本号说明了应用程序支持的最高 HTTP 版本。
HTTP/2.22 就比 HTTP/2.3 的
版本要高，因为 22 比 3 大。.后面的是小版本号

首部分类
HTTP 规范定义了几种首部字段。应用程序也可以随意发明自己所用的首部。 HTTP
首部可以分为以下几类。
• 通用首部
既可以出现在请求报文中，也可以出现在响应报文中。
• 请求首部
提供更多有关请求的信息。
• 响应首部
提供更多有关响应的信息。
• 实体首部
描述主体的长度和内容，或者资源自身。
• 扩展首部
规范中没有定义的新首部。

成功状态码和其对应的含义

比较常见的3XX的有：

第四章连接管理

• HTTP 是如何使用 TCP 连接的；.
• TCP 连接的时延、瓶颈以及存在的障碍；
• HTTP 的优化，包括并行连接、 keep-alive（持久连接）和管道化连接；
• 管理连接时应该以及不应该做的事情。

HTTP 连接实际上就是 TCP 连接及其使用规则。 TCP 连接是因特网上的可靠连接。

下图是浏览器访问一个网站的全部过程。

HTTP是应用层的TCP，TCP的数据通过IP分组的小数据块来发送的。

用TCP套接字编程

HTTP 紧挨着 TCP，位于其上层，所以 HTTP 事务的性能在很大程度上取决于底层
TCP 通道的性能。

HTTP 事务的时延有以下几种主要原因。
(1 ) 客户端首先需要根据 URI 确定 Web 服务器的 IP 地址和端口号。如果最近没有对
URI 中的主机名进行访问，通过 DNS 解析系统将 URI 中的主机名转换成一个 IP
地址可能要花费数十秒的时间 3。
(2) 接下来，客户端会向服务器发送一条 TCP 连接请求，并等待服务器回送一个请
求接受应答。每条新的 TCP 连接都会有连接建立时延。这个值通常最多只有一
两秒钟，但如果有数百个 HTTP 事务的话，这个值会快速地叠加上去。
(3) 一旦连接建立起来了，客户端就会通过新建立的 TCP 管道来发送 HTTP 请求。
数据到达时， Web 服务器会从 TCP 连接中读取请求报文，并对请求进行处理。
(4) 然后， Web 服务器会回送 HTTP 响应，这也需要花费时间。

由于因特网自身无法确保可靠的分组传输（因特网路由器超负荷的话，可以随意丢

弃分组），所以 TCP 实现了自己的确认机制来确保数据的成功传输。

每个 TCP 段都有一个序列号和数据完整性校验和。每个段的接收者收到完好的段

时，都会向发送者回送小的确认分组。如果发送者没有在指定的窗口时间内收到确

认信息，发送者就认为分组已被破坏或损毁，并重发数据。

HTTP连接的处理

实际上，浏览器确实使用了并行连接，但它们会将并行连接的总数限制为一个较小

的值（通常是 4 个）。服务器可以随意关闭来自特定客户端的超量连接。

持久连接

TTP/1 .1（以及 HTTP/1 .0 的各种增强版本）允许 HTTP 设备在事务处理结束

之后将 TCP 连接保持在打开状态，以便为未来的 HTTP 请求重用现存的连接。在事

务处理结束之后仍然保持在打开状态的 TCP 连接被称为持久连接。

重用已对目标服务器打开的空闲持久连接，就可以避开缓慢的连接建立阶段。而且，

已经打开的连接还可以避免慢启动的拥塞适应阶段，以便更快速地进行数据的传输。

盲中继

就是说keep-alive会导致一个哑代理的一个问题

与 HTTP/1 .0+ 的 keep-alive 连接不同， HTTP/1 .1 持久连接在默认情况下是激活
的。除非特别指明，否则 HTTP/1 .1 假定所有连接都是持久的。要在事务处理结束
之后将连接关闭， HTTP/1 .1 应用程序必须向报文中显式地添加一个 Connection:
close 首部。这是与以前的 HTTP 协议版本很重要的区别，在以前的版本中， keepalive 连接要么是可选的，要么根本就不支持。

除非响应中包含了 Connection: close 首部，不然 HTTP/1 .1 连接就仍维持在打开状态

尽管服务器不应该试图在传输报文的过程中关闭连接，而且在关闭连接之前至少

应该响应一条请求，但不管 Connection 首部取了什么值， HTTP/1 .1 设备都可

以在任意时刻关闭连接。

HTTP/1 .1 允许在持久连接上可选地使用请求管道。