HTTP 协议与报文

HTTP协议

HTTP 协议与 TCP/IP 协议一样，用于客户端和服务端之间的通信。

HTTP协议规定，请求从客户端发出，最后服务器端响应该请求并返回。

• 请求报文

  

  请求报文是由请求方法、请求URI、协议版本、可选的请求首部字段和内容实体构成。

  如果不是访问特点资源而是对服务器本身发起请求，可以用一个 * 来代替请求URI。

• 响应报文

  

  响应报文基本上由协议版本、状态码（表示请求成功或失败的数字代码）、用以解释状态码的原因短语、可选的相应首部字段以及实体主体构成。

HTTP协议是一种不保存状态，即无状态协议。HTTP自身不对请求和响应之间的通信状态进行保存。是为了更快地处理大量事务，确保协议的可伸缩性。
但是为了实现保持状态的功能，于是引进了 Cookie 技术。

告知服务器意图的HTTP方法

GET：获取资源

GET方法用来请求访问已被 URI 识别的资源。指定的资源经服务器端解析后返回响应内容。也就是说，如果请求的资源是文本，那就保持原样返回；如果是像 CGI （通用网关接口）那样的程序，则返回经过执行后的输出结果。

POST：传输实体主体

虽然用 GET 方法也能传输实体主体，但一般不这样用。虽说 POST 的功能与 GET很相似，但 POST 的主要目的并不是获取响应的主体内容。

HEAD：获得报文首部

HEAD 方法与 GET 方法一样，只是不返回报文主体部分。用于确认 URI 的有效性及资源更新的日期时间等。

OPTIONS：询问支持的方法

用来查询针对请求 URI 指定的资源支持的方法。

CONNECT：要求用隧道协议连接代理

CONNECT 方法要求在与代理服务器通信时建立隧道，实现用隧道协议进行 TCP 通信。主要使用 SSL （Secure Sockets Layer，安全套接层）和 TLS （Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。

格式： CONNECT 代理服务器名：端口号 HTTP版本

持久连接节省通信量

HTTP协议初始版本中，每进行一次通信就要断开一次 TCP 连接。因此，每次请求就会造成无谓的 TCP 连接建立和断开，增加通信量的开销。
为了解决上述 TPC 连接问题，HTTP/1.1想出了持久连接的方法。持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。

管线化

持久连接使得多数请求以管线化（pipelining）方式发送成为可能。从前发送请求后需要等待并收到响应，才能发送下一个请求。管线化技术出现后，不用等待响应亦可直接发送下一个请求。

使用 Cookie 的状态管理

HTTP 是无状态协议，它不对之前发生过的请求和响应的状态进行管理。无法根据之前的状态进行本次的请求处理。
于是引入了 Cookie 技术。Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。

Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。
服务器端发现客户端发送过来的 Cookie 后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。

HTTP 报文内的 HTTP 信息

用于 HTTP 协议交互的信息被称为 HTTP报文。请求端（客户端）的 HTTP 报文叫做请求报文，响应端（服务器端）的叫做响应报文。HTTP 报文本身是由多行（用 CR+LF 作换行符）数据构成的字符串文本。

请求报文与响应报文的结构

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

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

• 首部字段
  包含表示请求和响应的各种条件和属性的各类首部。
  一般有4种首部，分别是：

  • 通用首部
  • 请求首部
  • 响应首部
  • 实体首部

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

编码提升速率

HTTP 在传输数据时可以按照数据原貌直接传输，也可以进行编码提高效率。但是也同时会消耗更多的 CPU 资源。

• 报文（message）
  是 HTTP 通信中的基本单位，由 8 位组字节流组成，通过 HTTP 通信传输。

• 实体（entity）
  作为请求或响应的有效载荷数据（补充项）被传输，其内容由实体首部和实体主体组成。

HTTP 报文的主体用于传输请求或响应的实体主体。
通常，报文主体等于实体主体。只当传输中进行编码操作时，实体主体的内容发生变化，才导致它和报文主体产生差异。

内容编码可以将实体信息原样压缩，内容编码后的实体由客户端接收并负责解码。常见的有 gzip（GNU zip）。

分块传输编码会将实体主体分成多个部分（块）。每一块都会用十六进制来标记块的大小，而实体主体的最后一块会使用 “0（CR+LF）” 来标记。
使用分块传输编码的实体主体会由接收的客户端负责解码，恢复到编码前的实体主体。

多部分对象集合

在 MIME （多用途因特网邮件扩展）机制中，会使用一种称为多部分对象集合（Multipart）的方法，来容纳多份不同类型的数据。
HTTP 协议中也采纳了多部分对象集合，发送一份报文主体内可含有多类型实体。通常是在图片或文本文件等上传时使用。

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

• multipart/form-data
  在 Web 表单文件上传时使用。

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

在 HTTP 报文中使用多部分对象集合时，需要在首部字段里加上 Content-type 。
使用 boundary 字符串来划分多部分对象集合指明的各类实体。在 boundary 字符串指定的各个实体的起始行之前插入 “–” 标记，而在多部分对象集合对应的字符串的最后插入 “–” 作为结束。

获取部分内容的范围请求

如果传输数据时中断，为了避免重新加载所有数据，需要能从中断处恢复下载。
要实现该功能需要指定下载的实体范围。这种指定范围发送的请求叫做范围请求（Range Request）。

执行范围请求时，会用到首部字段 Range 来指定资源的 byte 范围。
例如：

• 5001 ~ 10000 字节
  Range: bytes=5001-10000
• 从 5001 字节之后全部的
  Range: bytes=5001-
• 从开始到 3000 字节和 5000~7000 字节的多重范围
  Range: bytes=-3000, 5000-7000

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

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

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

内容协商机制是指客户端和服务端就响应的资源内容进行交涉，然后提供给客户端最为合适的资源。内容协商会以响应资源的语言、字符集、编码方式等作为判断的基准。
包含在请求报文中的某些首部字段就是判断的基准。例如 Accept、Accept-Charset、Accept-Encoding、Accept-Language、Content-Language。

内容协商技术有以下3种类型。

1. 服务器驱动协商（Server-driven Negotaition）
   由服务器端进行内容协商。以请求的首部字段为参考，在服务器端自动处理。但对用户来说，以浏览器发送的信息作为判定的依据，并不一定能筛选出最优的内容。

2. 客户端驱动协商（Agent-driven Negotiation）
   由客户端进行内容协商的方式。用户从浏览器显示的可选项列表中手动选择。还可以利用 JavaScript 在 Web 页面上自动进行上述选择。比如按 OS 的类型或浏览器类型，自动切换成 PC 或移动端页面。

3. 透明协商（Transparent Negotiation）
   是服务器驱动和客户端驱动的结合体，是由服务器端和客户端各自进行内容协商的一种方法。