计算机网络（基于《图解HTTP》）学习笔记——Day02

3、HTTP 报文内的 HTTP 信息

HTTP 通信过程包括从客户端发往服务器端的请求及从服务器端返回 客户端的响应。

3.1、HTTP报文

HTTP报文：用于 HTTP 协议交互的信息。

请求端（客户端）的 HTTP 报文叫做请求报文，响应端（服务器端）的叫做响应报文。 HTTP 报文本身是由多行（用 CR+LF 作换行符）数据构成的字符串文本。

其结构如图：

 

3.2、 请求报文及响应报文的结构

请求报文和响应报文的结构如图所示：

 

请求报文和响应报文实例如图所示：

 

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

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

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

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

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

3.3、编码提升传输速率

HTTP 在传输数据时可以按照数据原貌直接传输，但也可以在传输过 程中通过编码提升传输速率。通过编码的方式，能够有效的处理大量的访问请求。

3.3.1、 报文主体和实体主体的差异

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

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

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

3.3.2、 压缩传输的内容编码

内容编码指明应用在实体内容上的编码格式，并保持实体信息原样压缩。内容编码后的实体由客户端接收并负责解码。如图所示：

 

常用的内容编码有以下几种。

• gzip（GNU zip）

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

• deflate（zlib）

• identity（不进行编码）

3.3.3 分割发送的分块传输编码

分块传输编码（Chunked Transfer Coding）：把实体主体分块的功能。如图所示：

 

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

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

MIME（Multipurpose Internet Mail Extensions，多用途因特网邮 件扩展）机制：它允许邮件处理文本、图片、视频等多个不同类型的数据。

MIME 扩展中会使用一种称为多部分对象集合（Multipart）的方法，来容纳多份不同类型的数据。

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

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

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

3.5 获取部分内容的范围请求

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

执行范围请求时，会用到首部字段 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 标明 multipart/byteranges 后返回响应报文。如果服务器端无法响应范围请求，则会返回状态码 200 OK 和完整的 实体内容。

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

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

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

内容协商技术：

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

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

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

4、 返回结果的 HTTP 状态码

HTTP 状态码负责表示客户端 HTTP 请求的返回结果、标记服务器端 的处理是否正常、通知出现的错误等工作。

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

响应状态中的第一位指定了响应类别，后两位无分类。响应类别可

分为一下五种：

 

 

下面具体分析各类别常用状态码。

2XX 表示请求被正常处理了

• 200 OK：表示从客户端发来的请求在服务器端被正常处理了。在响应报文内，随状态码一起返回的信息会因方法的不同而发生改 变。比如，使用GET方法时，对应请求资源的实体会作为响应返回；而使用HEAD方法时，对应请求资源的实体首部不随报文主体作为响应返回（即在响应中只返回首部，不会返回实体的主体部分）。

• 204 No Content：该状态码代表服务器接收的请求已成功处理，但在返回的响应报文中 不含实体的主体部分。另外，也不允许返回任何实体的主体。一般用于只需要从客户端往服务器发送消息，而对客户端不需要发送新消息内容的情况下使用。

• 206 Partial Content：表示客户端进行了范围请求，而服务器成功执行了这部分的 GET 请求。响应报文中包含由 Content-Range 指定范围的实体内容。

3XX 重定向

3XX 响应结果表明浏览器需要执行某些特殊的处理以正确处理请 求。

• 301 Moved Permanently：永久性重定向。表示请求的资源已被分配了新的 URI，以后 应使用资源现在所指的 URI。

• 302 Found：临时性重定向。表示请求的资源已被分配了新的 URI，希望 用户（本次）能使用新的 URI 访问。

• 303 See Other：表示由于请求对应的资源存在着另一个 URI，应使用 GET 方法定向获取请求的资源。

• 304 Not Modified：表示客户端发送附带条件的请求时，服务器端允许请求访问资源，但未满足条件的情况。304 状态码返回时，不包含任何响应的主体部分。304 虽然被划分在 3XX 类别中，但是和重定向没有关系。

• 307 Temporary Redirect：临时重定向。该状态码与 302 Found 有着相同的含义。尽管 302 标准禁止 POST 变换成 GET，但实际使用时大家并不遵守。 307 会遵照浏览器标准，不会从 POST 变成 GET。但是，对于处理响应时的行为，每种浏览器有可能出现不同的情况。

4XX 客户端错误

4XX 的响应结果表明客户端是发生错误的原因所在。

• 400 Bad Request：表示请求报文中存在语法错误。

• 401 Unauthorized：该状态码表示发送的请求需要有通过 HTTP 认证（BASIC 认证、 DIGEST 认证）的认证信息。另外若之前已进行过 1 次请求，则表示 用 户认证失败。

• 403 Forbidden：表明对请求资源的访问被服务器拒绝了。服务器端没有必要给出拒绝的详细理由，但如果想作说明的话，可以在实体的主体部分对原因进行描述，这样就能让用户看到了。

• 404 Not Found：表明服务器上无法找到请求的资源。除此之外，也可以在服 务器端拒绝请求且不想说明理由时使用。

5XX 服务器错误

5XX 的响应结果表明服务器本身发生错误。

• 500 Internal Server Error：表明服务器端在执行请求时发生了错误。也有可能是 Web 应用存在的 bug 或某些临时的故障。

• 503 Service Unavailable：表明服务器暂时处于超负载或正在进行停机维护，现在无法 处理请求。