「 图解HTTP 」 读书笔记 第三章

HTTP 报文内的 HTTP 信息

1. HTTP 报文

用于 HTTP 协议交互的信息被称为 HTTP 报文。

• 请求端（客户端）的 HTTP 报文叫请求报文

• 响应端 （服务器端）的 HTTP 报文叫响应报文

• HTTP 报文本身是由多行数据构成的字符串文本

HTTP 报文大致可分为报文首部和报文主体两块。

HTTP报文构成.png

2. 请求报文及响应报文的结构

• 请求报文结构

  请求报文结果.png

• 响应报文结构

  响应报文结构.png

• 请求报文实例

  请求报文实例.png

• 响应报文实例

  响应报文实例.png

请求报文和响应报文的首部内容由以下数据组成

• 请求行

  包含用于请求的方法，请求 URI 和 HTTP 版本。

• 状态行

  包含表明响应结果的状态码，原因短语和 HTTP 版本。

• 首部字段

  包含表示请求和响应的各种条件和属性的各类首部，一般有四种首部。

  • 通用首部

  • 请求首部

  • 响应首部

  • 实体首部

• 其他

  可能包含 HTTP 的 RFC 里未定义的首部（Cookie 等）

3. 编码提升速率

HTTP 在传输数据时可以按照数据原貌直接传输，也可以在传输过程中通过编码提升传输速率。

通过在传输时编码，能有效处理大量的访问请求。

编码的操作需要计算机来完成，因此会消耗更多的 CPU 资源。

3.1 报文实体和实体主体的差异

• 报文（message）

  是 HTTP 通信中的基本单位，由 8位组 字节流组成，通过 HTTP 通信传输。

• 实体（entity）

  作为请求和响应的有效载荷数据被传输，其内容由实体首部和实体主体组成。

HTTP 报文的主体用于传输请求或响应的实体主体

通常报文主体等于实体主体，只有当传输中进行编码时，实体主体的内容发生变化，才导致它和报文主体的差异。

3.2 压缩传输的内容编码

内容编码指明应用在实体内容上的编码格式，并保持实体原样压缩。内容编码后的实体由客户端接受并负责解码。

内容编码.png

常见的内容编码由以下几种：

• gzip（GNU zip）

• compress（UNIX 系统的标准压缩）

• deflate（zlib）

• identity（不进行编码）

3.3 分割发送的分块传输码

把实体主体分块的功能称为分块传输码（Chunked Transfer Coding）。

分块传输码.png

分块传输码会将实体主体分成多个部分（块），每一块都会用十六进制来标识块的大小，而实体主体的最后一块会使用 0(CR+LF) 来标记。

使用分块传输码的实体主体会由接受的客户端负责解码，恢复到编码前的实体主体。

HTTP/1.1 中存在一种称为传输码（Transfer Coding）的机制，它可以在通信时按照某种编码方式传输，但只定义作用于分块传输编码中。

4. 发送多种数据的多部分对象集合

HTTP 协议中采用 多部分对象集合，可以使发送的一份报文主体含有多类型实体，通常在图片或文本文件上传时使用。

多部分对象集合包含的对象如下：

• multipart/form-data

  在 Web 表单文件上传时使用。

  Content-Type: multipart/form-data; boundary=AaB03x
  
  --AaB03x
  Content-Disposition: form-data; name="field1"
  
  Joe Blow
  --AaB03x
  Content-Disposition: form-data; name="pics"; filename="file1.txt"
  Content-Type: text/plain
  
  ...（file1.txt的数据）...
  --AaB03x--
  

• multipart/byteranges

  状态码 206（Partial Content 部分内容）响应报文包含了多个范围的内容时使用。

  HTTP/1.1 206 Partial Content
  Date: Fri, 13 Jul 2012 02:45:26 GMT
  Last-Modified: Fri, 31 Aug 2007 02:02:20 GMT
  Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
  --THIS_STRING_SEPARATES
  Content-Type: application/pdf
  Content-Range: bytes 500-999/8000
              
  ...（范围指定的数据）...
  --THIS_STRING_SEPARATES
  Content-Type: application/pdf
  Content-Range: bytes 7000-7999/8000
              
  ...（范围指定的数据）...
  --THIS_STRING_SEPARATES--
  

在 HTTP 报文中使用多部分对象集合时，需要在首部字段加上 Content-type。

使用 boundary 字符串来划分多部分对象集合指明的各类实体。

在 boundary 字符串指定的各个实体的起始行之前插入 " -- " 标记，如（-
-AaB03x、--THIS_STRING_SEPARATES）。

在多部分对象集合对应的字符串的最后插入"--"(如：--AaB03x--、--THIS_STRING_SEPARATES--) 作为结束。

多部分对象集合的每个部分类型中，都可以含有首部字段，还可以在某个部分中嵌套使用多部分对象集合。

5. 获取部分内容的范围请求

指定范围发送的请求叫做范围请求（Range Request）。

对一份 10000 字节大小的资源，使用范围请求，可以只请求 5001~10000 字节内的资源。

范围请求.png

指定范围请求，会用到首部字段 Range 指定资源的 byte 范围。

byte 范围的指定形式如下：

• 5001~10000 字节

  Range: bytes=5001-10000
  

• 从 5001 字节之后全部的

  Range: bytes=5001-
  

• 从一开始到 3000 字节和 5000~7000 字节的多重范围

  Range: bytes=-3000, 5000-7000
  

针对范围请求，响应会返回状态码为 206 Partial Content 的响应报文。

多重范围的范围请求，响应会在首部字段 Content-type 标明 mulitpart/byteranges 后返回响应报文。

如果服务器端无法响应范围请求，则会返回状态码 200 OK 和完整的实体内容。

6. 内容协商返回最合适的内容

当浏览器默认语言为中文或英语，访问相同 URI 的 Web 页面时，则会显示对应语言的 Web 页面。这样的机制称为内容协商（Content Negotiation）。

内容协商.png

内容协商是指客户端和服务器端就响应的资源内容进行交涉，然后提供给客户端最合适的资源。内容协商会以响应资源的语言、字符集、编码方式等作为判断的基准。

包含在请求报文中的某些首部字段就是判断的基准，如：

• Accept

• Accept-Charset

• Accept-Encoding

• Accept-Language

• Content-Language

内容协商类型如下：

• 服务器驱动协商（Server-driven Negotiation）

  由服务器端进行内协商，以请求的首部字段作为参考，在服务器端自动处理。

• 客户端驱动协商（Agent-driven Negotiation）

  由客户端进行内容协商，用户从浏览器显示的可选项列表中手动选择，还可以利用 JavaScript 脚本在 Web 页面自动进行上述选择。

• 透明协商（Transparent Negotiation）

  服务器驱动和客户端驱动的结合体，由服务器和客户端各自进行内容协商的一种方法。