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/1.1 404 Not Found

翻译成人话就是：“抱歉啊浏览器，刚才你的请求收到了，但我没找到你要的资源，错误代码是 404，接下来的事情你就看着办吧。”

 

头部字段

请求行或状态行再加上头部字段集合就构成了 HTTP 报文里完整的请求头或响应头，我画了两个示意图，你可以看一下。

请求头和响应头的结构是基本一样的，唯一的区别是起始行，所以我把请求头和响应头里的字段放在一起介绍。

头部字段是 key-value 的形式，key 和 value 之间用“:”分隔，最后用 CRLF 换行表示字段结束。比如在“Host: 127.0.0.1”这一行里 key 就是“Host”，value 就是“127.0.0.1”。

HTTP 头字段非常灵活，不仅可以使用标准里的 Host、Connection 等已有头，也可以任意添加自定义头，这就给 HTTP 协议带来了无限的扩展可能。

不过使用头字段需要注意下面几点：

1. 字段名不区分大小写，例如“Host”也可以写成“host”，但首字母大写的可读性更好；

2. 字段名里不允许出现空格，可以使用连字符“-”，但不能使用下划线“_”。例如，“test-name”是合法的字段名，而“test name”“test_name”是不正确的字段名；

3. 字段名后面必须紧接着“:”，不能有空格，而“:”后的字段值前可以有多个空格；

4. 字段的顺序是没有意义的，可以任意排列不影响语义；

5. 字段原则上不能重复，除非这个字段本身的语义允许，例如 Set-Cookie。

下面是两个最简单的 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: user@itbilu.com	固定
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 (详解版)

参考文章

HTTP Header消息头详解

透视HTTP协议

------------恢复内容结束------------