「图解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）

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