HTTP 报文格式简介

HTTP（HyperTextTransferProtocol）是超文本传输协议的缩写，它用于传送 WWW 方式的数据，关于 HTTP 协议的详细内容请参考 RFC2616。HTTP 协议采用了请求/响应模型。客户端向服务器发送一个请求，请求头包含请求的方法、URI、协议版本、以及包含请求修饰符、客户信息和内容的类似于 MIME 的消息结构。服务器以一个状态行作为响应，相应的内容包括消息协议的版本，成功或者错误编码加上包含服务器信息、实体元信息以及可能的实体内容。

HTTP 协议也是与 TCP/UDP 类似，同样也需要在实际传输的数据前附加一些头数据，不过与 TCP/UDP 不同的是，它是一个“纯文本”的协议，所以头数据都是 ASCII 码的文本，可以很容易地用肉眼阅读，不用借助程序解析也能够看懂。

HTTP 协议的请求报文和响应报文的结构基本相同，由三大部分组成：

1. 起始行（start line）：描述请求或响应的基本信息；

2. 头部字段集合（header）：使用 key-value 形式更详细地说明报文；

3. 消息正文（entity）：实际传输的数据，它不一定是纯文本，可以是图片、视频等二进制数据。

这其中前两部分起始行和头部字段经常又合称为“请求头”或“响应头”，消息正文又称为“实体”，但与“header”对应，很多时候就直接称为“body”。

HTTP 协议规定报文必须有 header，但可以没有 body，而且在 header 之后必须要有一个“空行”，也就是“CRLF”，十六进制的“0D0A”。

所以，一个完整的 HTTP 报文就像是下图的这个样子，注意在 header 和 body 之间有一个“空行”。

请求行

了解了 HTTP 报文的基本结构后，我们来看看请求报文里的起始行也就是请求行（request line），它简要地描述了客户端想要如何操作服务器端的资源。

请求行由三部分构成：

1. 请求方法：是一个动词，如 GET/POST，表示对资源的操作；
2. 请求目标：通常是一个 URI，标记了请求方法要操作的资源；
3. 版本号：表示报文使用的 HTTP 协议版本。

这三个部分通常使用空格（space）来分隔，最后要用 CRLF 换行表示结束。

举例：

GET / HTTP/1.1

在这个请求行里，“GET”是请求方法，“/”是请求目标，“HTTP/1.1”是版本号，把这三部分连起来，意思就是“服务器你好，我想获取网站根目录下的默认文件，我用的协议版本号是 1.1，请不要用 1.0 或者 2.0 回复我。”

别看请求行就一行，貌似很简单，其实这里面的“讲究”是非常多的，尤其是前面的请求方法和请求目标，组合起来变化多端，后面我还会详细介绍。

状态行

看完了请求行，我们再看响应报文里的起始行，在这里它不叫“响应行”，而是叫“状态行”（status line），意思是服务器响应的状态。

比起请求行来说，状态行要简单一些，同样也是由三部分构成：

1. 版本号：表示报文使用的 HTTP 协议版本；
2. 状态码：一个三位数，用代码的形式表示处理的结果，比如 200 是成功，500 是服务器错误；
3. 原因：作为数字状态码补充，是更详细的解释文字，帮助人理解原因。

看一下例子的响应报文，状态行是：

HTTP/1.1 200 OK

意思就是：“浏览器你好，我已经处理完了你的请求，这个报文使用的协议版本号是 1.1，状态码是 200，一切 OK。”

而另一个“GET /favicon.ico HTTP/1.1”的响应报文状态行是：

下面是两个最简单的 HTTP 请求，第一个在“:”后有多个空格，第二个在“:”前有空格。

GET /09-1 HTTP/1.1
Host:   www.chrono.com
 
 
GET /09-1 HTTP/1.1
Host : www.chrono.com

第一个可以正确获取服务器的响应报文，而第二个得到的会是一个“400 Bad Request”，表示请求报文格式有误，服务器无法正确处理：

HTTP/1.1 400 Bad Request
Server: openresty/1.15.8.1
Connection: close

常用头字段

HTTP 协议规定了非常多的头部字段，实现各种各样的功能，但基本上可以分为四大类：

1. 通用字段：在请求头和响应头里都可以出现；

2. 请求字段：仅能出现在请求头里，进一步说明请求信息或者额外的附加条件；

3. 响应字段：仅能出现在响应头里，补充说明响应报文的信息；

4. 实体字段：它实际上属于通用字段，但专门描述 body 的额外信息。

对 HTTP 报文的解析和处理实际上主要就是对头字段的处理，理解了头字段也就理解了 HTTP 报文。

下面是两个常用的报文表格，方便大家记忆

常用的 HTTP 请求头

协议头 说明 示例 状态 Accept 可接受的响应内容类型（ Content-Types ）。 Accept: text/plain 固定 Accept-Charset 可接受的字符集 Accept-Charset: utf-8 固定 Accept-Encoding 可接受的响应内容的编码方式。 Accept-Encoding: gzip, deflate 固定 Accept-Language 可接受的响应内容语言列表。 Accept-Language: en-US 固定 Accept-Datetime 可接受的按照时间来表示的响应内容版本 Accept-Datetime: Sat, 26 Dec 2015 17:30:00 GMT 临时 Authorization 用于表示HTTP协议中需要认证资源的认证信息 Authorization: Basic OSdjJGRpbjpvcGVuIANlc2SdDE== 固定 Cache-Control 用来指定当前的请求/回复中的，是否使用缓存机制。 Cache-Control: no-cache 固定 Connection 客户端（浏览器）想要优先使用的连接类型 Connection: keep-alive

Connection: Upgrade

固定 Cookie 由之前服务器通过 Set-Cookie （见下文）设置的一个HTTP协议Cookie Cookie: $Version=1; Skin=new; 固定：标准 Content-Length 以8进制表示的请求体的长度 Content-Length: 348 固定 Content-MD5 请求体的内容的二进制 MD5 散列值（数字签名），以 Base64 编码的结果 Content-MD5: oD8dH2sgSW50ZWdyaIEd9D== 废弃 Content-Type 请求体的MIME类型 （用于POST和PUT请求中） Content-Type: application/x-www-form-urlencoded 固定 Date 发送该消息的日期和时间（以 RFC 7231 中定义的"HTTP日期"格式来发送） Date: Dec, 26 Dec 2015 17:30:00 GMT 固定 Expect 表示客户端要求服务器做出特定的行为 Expect: 100-continue 固定 From 发起此请求的用户的邮件地址 From: [email protected] 固定 Host 表示服务器的域名以及服务器所监听的端口号。如果所请求的端口是对应的服务的标准端口（80），则端口号可以省略。 Host: www.itbilu.com:80

Host: www.itbilu.com

固定 If-Match 仅当客户端提供的实体与服务器上对应的实体相匹配时，才进行对应的操作。主要用于像 PUT 这样的方法中，仅当从用户上次更新某个资源后，该资源未被修改的情况下，才更新该资源。 If-Match: "9jd00cdj34pss9ejqiw39d82f20d0ikd" 固定 If-Modified-Since 允许在对应的资源未被修改的情况下返回304未修改 If-Modified-Since: Dec, 26 Dec 2015 17:30:00 GMT 固定 If-None-Match 允许在对应的内容未被修改的情况下返回304未修改（ 304 Not Modified ），参考 超文本传输协议 的实体标记 If-None-Match: "9jd00cdj34pss9ejqiw39d82f20d0ikd" 固定 If-Range 如果该实体未被修改过，则向返回所缺少的那一个或多个部分。否则，返回整个新的实体 If-Range: "9jd00cdj34pss9ejqiw39d82f20d0ikd" 固定 If-Unmodified-Since 仅当该实体自某个特定时间以来未被修改的情况下，才发送回应。 If-Unmodified-Since: Dec, 26 Dec 2015 17:30:00 GMT 固定 Max-Forwards 限制该消息可被代理及网关转发的次数。 Max-Forwards: 10 固定 Origin 发起一个针对 跨域资源共享 的请求（该请求要求服务器在响应中加入一个 Access-Control-Allow-Origin 的消息头，表示访问控制所允许的来源）。 Origin: http://www.itbilu.com 固定: 标准 Pragma 与具体的实现相关，这些字段可能在请求/回应链中的任何时候产生。 Pragma: no-cache 固定 Proxy-Authorization 用于向代理进行认证的认证信息。 Proxy-Authorization: Basic IOoDZRgDOi0vcGVuIHNlNidJi2== 固定 Range 表示请求某个实体的一部分，字节偏移以0开始。 Range: bytes=500-999 固定 Referer 表示浏览器所访问的前一个页面，可以认为是之前访问页面的链接将浏览器带到了当前页面。 Referer 其实是 Referrer 这个单词，但RFC制作标准时给拼错了，后来也就将错就错使用 Referer 了。 Referer: http://itbilu.com/nodejs 固定 TE 浏览器预期接受的传输时的编码方式：可使用回应协议头 Transfer-Encoding 中的值（还可以使用"trailers"表示数据传输时的分块方式）用来表示浏览器希望在最后一个大小为0的块之后还接收到一些额外的字段。 TE: trailers,deflate 固定 User-Agent 浏览器的身份标识字符串 User-Agent: Mozilla/…… 固定 Upgrade 要求服务器升级到一个高版本协议。 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 固定 Via 告诉服务器，这个请求是由哪些代理发出的。 Via: 1.0 fred, 1.1 itbilu.com.com (Apache/1.1) 固定 Warning 一个一般性的警告，表示在实体内容体中可能存在错误。 Warning: 199 Miscellaneous warning 固定

常用的 HTTP 响应头

响应头 说明 示例 状态 Access-Control-Allow-Origin 指定哪些网站可以 跨域源资源共享 Access-Control-Allow-Origin: * 临时 Accept-Patch 指定服务器所支持的文档补丁格式 Accept-Patch: text/example;charset=utf-8 固定 Accept-Ranges 服务器所支持的内容范围 Accept-Ranges: bytes 固定 Age 响应对象在代理缓存中存在的时间，以秒为单位 Age: 12 固定 Allow 对于特定资源的有效动作; Allow: GET, HEAD 固定 Cache-Control 通知从服务器到客户端内的所有缓存机制，表示它们是否可以缓存这个对象及缓存有效时间。其单位为秒 Cache-Control: max-age=3600 固定 Connection 针对该连接所预期的选项 Connection: close 固定 Content-Disposition 对已知MIME类型资源的描述，浏览器可以根据这个响应头决定是对返回资源的动作，如：将其下载或是打开。 Content-Disposition: attachment; filename="fname.ext" 固定 Content-Encoding 响应资源所使用的编码类型。 Content-Encoding: gzip 固定 Content-Language 响就内容所使用的语言 Content-Language: zh-cn 固定 Content-Length 响应消息体的长度，用8进制字节表示 Content-Length: 348 固定 Content-Location 所返回的数据的一个候选位置 Content-Location: /index.htm 固定 Content-MD5 响应内容的二进制 MD5 散列值，以 Base64 方式编码 Content-MD5: IDK0iSsgSW50ZWd0DiJUi== 已淘汰 Content-Range 如果是响应部分消息，表示属于完整消息的哪个部分 Content-Range: bytes 21010-47021/47022 固定 Content-Type 当前内容的 MIME 类型 Content-Type: text/html; charset=utf-8 固定 Date 此条消息被发送时的日期和时间(以 RFC 7231 中定义的"HTTP日期"格式来表示) Date: Tue, 15 Nov 1994 08:12:31 GMT 固定 ETag 对于某个资源的某个特定版本的一个标识符，通常是一个 消息散列 ETag: "737060cd8c284d8af7ad3082f209582d" 固定 Expires 指定一个日期/时间，超过该时间则认为此回应已经过期 Expires: Thu, 01 Dec 1994 16:00:00 GMT 固定: 标准 Last-Modified 所请求的对象的最后修改日期(按照 RFC 7231 中定义的“超文本传输协议日期”格式来表示) Last-Modified: Dec, 26 Dec 2015 17:30:00 GMT 固定 Link 用来表示与另一个资源之间的类型关系，此类型关系是在 RFC 5988 中定义 Link:  ; rel="alternate" 固定 Location 用于在进行重定向，或在创建了某个新资源时使用。 Location: http://www.itbilu.com/nodejs 固定 P3P P3P策略相关设置 P3P: CP="This is not a P3P policy! 固定 Pragma 与具体的实现相关，这些响应头可能在请求/回应链中的不同时候产生不同的效果 Pragma: no-cache 固定 Proxy-Authenticate 要求在访问代理时提供身份认证信息。 Proxy-Authenticate: Basic 固定 Public-Key-Pins 用于防止中间攻击，声明网站认证中传输层安全协议的证书散列值 Public-Key-Pins: max-age=2592000; pin-sha256="……"; 固定 Refresh 用于重定向，或者当一个新的资源被创建时。默认会在5秒后刷新重定向。 Refresh: 5; url=http://itbilu.com Retry-After 如果某个实体临时不可用，那么此协议头用于告知客户端稍后重试。其值可以是一个特定的时间段(以秒为单位)或一个超文本传输协议日期。

• 示例1:Retry-After: 120
• 示例2: Retry-After: Dec, 26 Dec 2015 17:30:00 GMT

固定

Server 服务器的名称 Server: nginx/1.6.3 固定 Set-Cookie 设置 HTTP cookie Set-Cookie: UserID=itbilu; Max-Age=3600; Version=1 固定: 标准 Status 通用网关接口的响应头字段，用来说明当前HTTP连接的响应状态。 Status: 200 OK Trailer Trailer 用户说明传输中分块编码的编码信息 Trailer: Max-Forwards 固定 Transfer-Encoding 用表示实体传输给用户的编码形式。包括： chunked 、 compress 、  deflate 、 gzip 、 identity 。 Transfer-Encoding: chunked 固定 Upgrade 要求客户端升级到另一个高版本协议。 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 固定 Vary 告知下游的代理服务器，应当如何对以后的请求协议头进行匹配，以决定是否可使用已缓存的响应内容而不是重新从原服务器请求新的内容。 Vary: * 固定 Via 告知代理服务器的客户端，当前响应是通过什么途径发送的。 Via: 1.0 fred, 1.1 itbilu.com (nginx/1.6.3) 固定 Warning 一般性警告，告知在实体内容体中可能存在错误。 Warning: 199 Miscellaneous warning 固定 WWW-Authenticate 表示在请求获取这个实体时应当使用的认证模式。 WWW-Authenticate: Basic 固定

关于具体的头字段（缓存，cookie）会在之后的文章进行介绍。

小结

下面做一个简单小结。

1. HTTP 报文结构由“起始行 + 头部 + 空行 + 实体”组成，简单地说就是“header+body”；

2. HTTP 报文可以没有 body，但必须要有 header，而且 header 后也必须要有空行，形象地说就是“大头”必须要带着“脖子”；

3. 请求头由“请求行 + 头部字段”构成，响应头由“状态行 + 头部字段”构成；

4. 请求行有三部分：请求方法，请求目标和版本号；

5. 状态行也有三部分：版本号，状态码和原因字符串；

6. 头部字段是 key-value 的形式，用“:”分隔，不区分大小写，顺序任意，除了规定的标准头，也可以任意添加自定义字段，实现功能扩展；

7. HTTP/1.1 里唯一要求必须提供的头字段是 Host，它必须出现在请求头里，标记虚拟主机名。

关于 HTTP 系列文章：

• HTTP 概述

• TCP 三次握手和四次挥手图解（有限状态机）

• 从你输入网址，到看到网页——详解中间发生的过程

• 深入浅出 HTTPS (详解版)