转载：HTTP 报文格式简介 - huansky - 博客园 (cnblogs.com)
前端开发人员需要对http有更详细的了解，于是写个文章记录下
HTTP（HyperTextTransferProtocol）是超文本传输协议的缩写，它用于传送 WWW 方式的数据，关于 HTTP 协议的详细内容请参考 RFC2616。HTTP 协议采用了请求/响应模型。客户端向服务器发送一个请求，请求头包含请求的方法、URI、协议版本、以及包含请求修饰符、客户信息和内容的类似于 MIME 的消息结构。服务器以一个状态行作为响应，相应的内容包括消息协议的版本，成功或者错误编码加上包含服务器信息、实体元信息以及可能的实体内容。
HTTP 协议也是与 TCP/UDP 类似，同样也需要在实际传输的数据前附加一些头数据，不过与 TCP/UDP 不同的是，它是一个“纯文本”的协议，所以头数据都是 ASCII 码的文本，可以很容易地用肉眼阅读，不用借助程序解析也能够看懂。
HTTP 协议的请求报文和响应报文的结构基本相同，由三大部分组成：
-
起始行（start line）：描述请求或响应的基本信息；
-
头部字段集合（header）：使用 key-value 形式更详细地说明报文；
-
消息正文（entity）：实际传输的数据，它不一定是纯文本，可以是图片、视频等二进制数据。
这其中前两部分起始行和头部字段经常又合称为“请求头”或“响应头”，消息正文又称为“实体”，但与“header”对应，很多时候就直接称为“body”。
HTTP 协议规定报文必须有 header，但可以没有 body，而且在 header 之后必须要有一个“空行”，也就是“CRLF”，十六进制的“0D0A”。
所以，一个完整的 HTTP 报文就像是下图的这个样子，注意在 header 和 body 之间有一个“空行”。
请求行
了解了 HTTP 报文的基本结构后，我们来看看请求报文里的起始行也就是请求行（request line），它简要地描述了客户端想要如何操作服务器端的资源。
请求行由三部分构成：
- 请求方法：是一个动词，如 GET/POST，表示对资源的操作；
- 请求目标：通常是一个 URI，标记了请求方法要操作的资源；
- 版本号：表示报文使用的 HTTP 协议版本。
这三个部分通常使用空格（space）来分隔，最后要用 CRLF 换行表示结束。
举例：
GET / HTTP/1.1在这个请求行里，“GET”是请求方法，“/”是请求目标，“HTTP/1.1”是版本号，把这三部分连起来，意思就是“服务器你好，我想获取网站根目录下的默认文件，我用的协议版本号是 1.1，请不要用 1.0 或者 2.0 回复我。”
别看请求行就一行，貌似很简单，其实这里面的“讲究”是非常多的，尤其是前面的请求方法和请求目标，组合起来变化多端，后面我还会详细介绍。
状态行
看完了请求行，我们再看响应报文里的起始行，在这里它不叫“响应行”，而是叫“状态行”（status line），意思是服务器响应的状态。
比起请求行来说，状态行要简单一些，同样也是由三部分构成：
- 版本号：表示报文使用的 HTTP 协议版本；
- 状态码：一个三位数，用代码的形式表示处理的结果，比如 200 是成功，500 是服务器错误；
- 原因：作为数字状态码补充，是更详细的解释文字，帮助人理解原因。
看一下例子的响应报文，状态行是：
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 协议带来了无限的扩展可能。
不过使用头字段需要注意下面几点：
-
字段名不区分大小写，例如“Host”也可以写成“host”，但首字母大写的可读性更好；
-
字段名里不允许出现空格，可以使用连字符“-”，但不能使用下划线“_”。例如，“test-name”是合法的字段名，而“test name”“test_name”是不正确的字段名；
-
字段名后面必须紧接着“:”，不能有空格，而“:”后的字段值前可以有多个空格；
-
字段的顺序是没有意义的，可以任意排列不影响语义；
-
字段原则上不能重复，除非这个字段本身的语义允许，例如 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 协议规定了非常多的头部字段，实现各种各样的功能，但基本上可以分为四大类：
-
通用字段：在请求头和响应头里都可以出现；
-
请求字段：仅能出现在请求头里，进一步说明请求信息或者额外的附加条件；
-
响应字段：仅能出现在响应头里，补充说明响应报文的信息；
-
实体字段：它实际上属于通用字段，但专门描述 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
|
固定 |
| 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
|
固定 |
| 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 | 如果某个实体临时不可用，那么此协议头用于告知客户端稍后重试。其值可以是一个特定的时间段(以秒为单位)或一个超文本传输协议日期。 |
|
固定 |
| 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）会在之后的文章进行介绍。
小结
下面做一个简单小结。
-
HTTP 报文结构由“起始行 + 头部 + 空行 + 实体”组成，简单地说就是“header+body”；
-
HTTP 报文可以没有 body，但必须要有 header，而且 header 后也必须要有空行，形象地说就是“大头”必须要带着“脖子”；
-
请求头由“请求行 + 头部字段”构成，响应头由“状态行 + 头部字段”构成；
-
请求行有三部分：请求方法，请求目标和版本号；
-
状态行也有三部分：版本号，状态码和原因字符串；
-
头部字段是 key-value 的形式，用“:”分隔，不区分大小写，顺序任意，除了规定的标准头，也可以任意添加自定义字段，实现功能扩展；
-
HTTP/1.1 里唯一要求必须提供的头字段是 Host，它必须出现在请求头里，标记虚拟主机名。
关于 HTTP 系列文章：
-
HTTP 概述
-
TCP 三次握手和四次挥手图解（有限状态机）
-
从你输入网址，到看到网页——详解中间发生的过程
-
深入浅出 HTTPS (详解版)
-
漫谈 HTTP 连接
-
漫谈 HTTP 性能优化
-
HTTP 报文格式简介
-
深入浅出：HTTP/2