02.HTTP协议简介及状态码

第二章 简单的HTTP协议

持久连接节省通信量

• 持久化
  持久连接的特点是，只要任意一端没有明确提出断开连接，则保持TCP连接状态。持久连接的好处在于减少了TCP连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。另外，减少开销的那部分时间，使HTTP请求和响应能够更早地结束，这样Web页面的显示速度也就相应提高了。
• 管线化
  持久连接使得多数请求以管线化（pipelining）方式发送成为可能。从前发送请求后需等待并收到响应，才能发送下一个请求。管线化技术出现后，不用等待响应亦可直接发送下一个请求。

使用Cookie的状态管理

HTTP是无状态协议，它不对之前发生过的请求和响应的状态进行管理。也就是说，无法根据之前的状态进行本次的请求处理。

保留无状态协议这个特征的同时又要解决类似的矛盾问题，于是引入了Cookie技术。Cookie技术通过在请求和响应报文中写入Cookie信息来控制客户端的状态。

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

第三章 HTTP报文内的HTTP信息

HTTP报文

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

HTTP 报文大致可分为报文首部和报文主体两块。两者由最初出现的空行（CR+LF）来划分。通常，并不一定要有报文主体。

报文结构

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

• 请求行。包含用于请求的方法，请求URI和 HTTP 版本。
• 状态行。包含表明响应结果的状态码，原因短语和HTTP版本。
• 首部字段。包含表示请求和响应的各种条件和属性的各类首部。一般有4种首部：通用首部、请求首部、响应首部和实体首部。
• 其他。可能包含HTTP的RFC里未定义的首部（Cookie 等）。

编码提升传输速率

HTTP在传输数据时可以按照数据原貌直接传输，但也可以在传输过程中通过编码提升传输速率。通过在传输时编码，能有效地处理大量的访问请求。但是，编码的操作需要计算机来完成，因此会消耗更多的CPU等资源。

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

  • 报文是 HTTP 通信中的基本单位，由8位组字节流组成，通过HTTP通信传输。
  • 实体作为请求或响应的有效载荷数据（补充项）被传输，其内容由实体首部和实体主体组成。

• 压缩传输的内容编码
  向待发送邮件内增加附件时，为了使邮件容量变小，我们会先用ZIP压缩文件之后再添加附件发送。HTTP协议中有一种被称为内容编
  码的功能也能进行类似的操作。
  内容编码指明应用在实体内容上的编码格式，并保持实体信息原样压缩。内容编码后的实体由客户端接收并负责解码。常用的内容编码有以下几种。

  • gzip（GNU zip）
  • compress（UNIX 系统的标准压缩）
  • deflate（zlib）
  • identity（不进行编码）

• 分割发送的分块传输编码
  在 HTTP 通信过程中，请求的编码实体资源尚未全部传输完成之前，浏览器无法显示请求页面。在传输大容量数据时，通过把数据分割成多块，能够让浏览器逐步显示页面。这种把实体主体分块的功能称为分块传输编码（Chunked Transfer Coding）。
  分块传输编码会将实体主体分成多个部分（块）。每一块都会用十六进制来标记块的大小，而实体主体的最后一块会使用“0(CR+LF)”
  来标记。
  使用分块传输编码的实体主体会由接收的客户端负责解码，恢复到编码前的实体主体。
  HTTP/1.1 中存在一种称为传输编码（Transfer Coding）的机制，它可以在通信时按某种编码方式传输，但只定义作用于分块传输编码中。

• 发送多种数据的多部分对象集合
  发送邮件时，我们可以在邮件里写入文字并添加多份附件。这是因为采用了MIME（Multipurpose Internet Mail Extensions，多用途因特网邮件扩展）机制，它允许邮件处理文本、图片、视频等多个不同类型的数据。而在MIME扩展中会使用一种称为多部分对象集合（Multipart）的方法，来容纳多份不同类型的数据。HTTP协议中也采纳了多部分对象集合，发送的一份报文主体内可含有多类型实体。通常是在图片或文本文件等上传时使用。

  • multipart/form-data：在 Web 表单文件上传时使用。
  • multipart/byteranges：状态码206（Partial Content，部分内容）响应报文包含了多个范围的内容时使用。

• 获取部分内容的范围请求
  执行范围请求时，会用到首部字段 Range 来指定资源的 byte 范围。byte 范围的指定形式如下：Range: bytes=5001-10000
  针对范围请求，响应会返回状态码为 206 Partial Content 的响应报文。另外，对于多重范围的范围请求，响应会在首部字段 Content-Type标明multipart/byteranges后返回响应报文。

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

第四章 返回结果的HTTP状态码

状态码告知从服务器端返回的请求结果

状态码的职责是当客户端向服务器端发送请求时，描述返回的请求结果。借助状态码，用户可以知道服务器端是正常处理了请求，还是出现了错误。

• 1XX Informational（信息性状态码） 接收的请求正在处理
• 2XX Success（成功状态码） 请求正常处理完毕
• 3XX Redirection（重定向状态码） 需要进行附加操作以完成请求
• 4XX Client Error（客户端错误状态码） 服务器无法处理请求
• 5XX Server Error（服务器错误状态码） 服务器处理请求出错

2XX 成功

• 200 OK
  表示从客户端发来的请求在服务器端被正常处理了。
• 204 No Content
  该状态码代表服务器接收的请求已成功处理，但在返回的响应报文中不含实体的主体部分。另外，也不允许返回任何实体的主体。一般在只需要从客户端往服务器发送信息，而对客户端不需要发送新信息内容的情况下使用。
• 206 Partial Content
  该状态码表示客户端进行了范围请求，而服务器成功执行了这部分的GET请求。响应报文中包含由Content-Range指定范围的实体内容。

3XX 重定向

• 301 Moved Permanently
  永久性重定向。该状态码表示请求的资源已被分配了新的URI，以后应使用资源现在所指的URI。也就是说，如果已经把资源对应的 URI保存为书签了，这时应该按Location首部字段提示的URI重新保存。
• 302 Found
  临时性重定向。该状态码表示请求的资源已被分配了新的URI，希望用户（本次）能使用新的URI访问。
• 303 See Other
  该状态码表示由于请求对应的资源存在着另一个 URI，应使用 GET方法定向获取请求的资源。
• 304 Not Modified
  该状态码表示客户端发送附带条件的请求A时，服务器端允许请求访问资源，但未满足条件的情况。304 虽然被划分在3XX类别中，但是和重定向没有关系。

4XX 客户端错误

• 400 Bad Request
  该状态码表示请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。
• 401 Unauthorized
  该状态码表示发送的请求需要有通过 HTTP 认证（BASIC 认证、DIGEST 认证）的认证信息。另外若之前已进行过1次请求，则表示用户认证失败。
• 403 Forbidden
  该状态码表明对请求资源的访问被服务器拒绝了。未获得文件系统的访问授权，访问权限出现某些问题（从未授权的发送源IP地址试图访问）等列举的情况都可能是发生403的原因。
• 404 Not Found
  该状态码表明服务器上无法找到请求的资源。除此之外，也可以在服务器端拒绝请求且不想说明理由时使用。

5XX 服务器错误

• 500 Internal Server Error
  该状态码表明服务器端在执行请求时发生了错误。也有可能是Web应用存在的bug或某些临时的故障。
• 503 Service Unavailable
  该状态码表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。如果事先得知解除以上状况需要的时间，最好写入 Retry-After首部字段再返回给客户端。