HTTP 报文内的 HTTP 信息
1. HTTP 报文
用于 HTTP 协议交互的信息被称为 HTTP 报文。
请求端（客户端）的 HTTP 报文叫请求报文
响应端 （服务器端）的 HTTP 报文叫响应报文
HTTP 报文本身是由多行数据构成的字符串文本
HTTP 报文大致可分为报文首部和报文主体两块。
2. 请求报文及响应报文的结构
-
请求报文结构
请求报文结果.png -
响应报文结构
响应报文结构.png -
请求报文实例
请求报文实例.png -
响应报文实例
响应报文实例.png
请求报文和响应报文的首部内容由以下数据组成
-
请求行
包含用于请求的方法，请求 URI 和 HTTP 版本。
-
状态行
包含表明响应结果的状态码，原因短语和 HTTP 版本。
-
首部字段
包含表示请求和响应的各种条件和属性的各类首部，一般有四种首部。
通用首部
请求首部
响应首部
实体首部
-
其他
可能包含 HTTP 的 RFC 里未定义的首部（Cookie 等）
3. 编码提升速率
HTTP 在传输数据时可以按照数据原貌直接传输，也可以在传输过程中通过编码提升传输速率。
通过在传输时编码，能有效处理大量的访问请求。
编码的操作需要计算机来完成，因此会消耗更多的 CPU 资源。
3.1 报文实体和实体主体的差异
-
报文（message）
是 HTTP 通信中的基本单位，由 8位组 字节流组成，通过 HTTP 通信传输。
-
实体（entity）
作为请求和响应的有效载荷数据被传输，其内容由实体首部和实体主体组成。
HTTP 报文的主体用于传输请求或响应的实体主体
通常报文主体等于实体主体，只有当传输中进行编码时，实体主体的内容发生变化，才导致它和报文主体的差异。
3.2 压缩传输的内容编码
内容编码指明应用在实体内容上的编码格式，并保持实体原样压缩。内容编码后的实体由客户端接受并负责解码。
常见的内容编码由以下几种：
gzip（GNU zip）
compress（UNIX 系统的标准压缩）
deflate（zlib）
identity（不进行编码）
3.3 分割发送的分块传输码
把实体主体分块的功能称为分块传输码（Chunked Transfer Coding）。
分块传输码会将实体主体分成多个部分（块），每一块都会用十六进制来标识块的大小，而实体主体的最后一块会使用 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 字节内的资源。
指定范围请求，会用到首部字段 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）。
内容协商是指客户端和服务器端就响应的资源内容进行交涉，然后提供给客户端最合适的资源。内容协商会以响应资源的语言、字符集、编码方式等作为判断的基准。
包含在请求报文中的某些首部字段就是判断的基准，如：
Accept
Accept-Charset
Accept-Encoding
Accept-Language
Content-Language
内容协商类型如下：
-
服务器驱动协商（Server-driven Negotiation）
由服务器端进行内协商，以请求的首部字段作为参考，在服务器端自动处理。
-
客户端驱动协商（Agent-driven Negotiation）
由客户端进行内容协商，用户从浏览器显示的可选项列表中手动选择，还可以利用 JavaScript 脚本在 Web 页面自动进行上述选择。
-
透明协商（Transparent Negotiation）
服务器驱动和客户端驱动的结合体，由服务器和客户端各自进行内容协商的一种方法。
