HTTP 报文是在 HTTP 应用程序之间发送的数据块。这些数据块以一些文本形式的元信息开头，这些信息描述了报文的内容及含义。

报文流

报文在客户端、服务器和代理之间的流动称为报文流。 HTTP 使用术语流入和流出来描述事务处理的方向。报文像水一样都是从上游流向下游，不会从下游流向上游。假定客户端和服务器之间有两个代理服务器，客户端发送一个请求，服务器进行响应，期间报文流向为：客户端 -> 代理1 ->代理2 -> 服务器 -> 代理2 -> 代理1 -> 客户端。

报文流向.png

报文的组成部分

每条报文都包含一条来自客户端的请求，或者来自服务器的响应。它们由三部分组成：对报文进行描述的起始行，包含属性的首部块，以及可选的、包含数据的主体部分。

起始行和首部是由行分隔的 ASCII 文本，每行的行终止符都由一个回车符和一个换行符组成，可书写成 CRLF。主体可以包含文本数据或二进制数据，也可以为空。

延伸：Unix 系统里，每行结尾只有“<换行>”，即“\n”；Windows系统里面，每行结尾是“ <回车><换 行>”，即“\r\n”；Mac系统里，每行结尾是“<回车>”。一个直接后果是，Unix/Mac系统下的文件在Windows里打 开的话，所有文字会变成一行；而Windows里的文件在Unix/Mac下打开的话，在每行的结尾可能会多出一个^M符号。

所有的 HTTP 报文都可以分为两类：请求报文和响应报文，两者的基本报文结构相同，具体内容有些许差别。

HTTP报文基本结构.png

请求报文的格式如下：

<method> <request-URL> <version>    // 起始行
<headers>                           // 首部

<entity-body>                       //  主体      

响应报文格式如下，

<version> <status> <reason-phrase>    // 起始行
<headers>                             // 首部

<entity-body>                         //  主体    

下面对报文格式中的每一项进行概述性解释，

方法(method)

请求的起始行以方法作为开始，用来告诉服务器要做什么。比如 GET /test/index.text HTTP/1.1 ， 方法是 GET，请求从服务器拿到 /test/idnex.text 文件内容。常用的 HTTP 方法有，

以上方法并不是所有浏览器都支持，也不是所有服务器都支持。安全方法指不会在服务器上执行任何内容变更并产生任何结果的方法。
虽然方法有这么多，但目前浏览器上的请求几乎被 GET 和 POST 包揽，这是为什么呢？下面有个非官方的网友回答，觉得解释得通不错，于是摘录，

按照定义，假设有资源组A，内部包含该1、2、3这些资源，则

获取资源A1：Get Url A1
新增资源A4：Post Url A + RAWDATA 4
修改资源A4：Put Url A + RAWDATA 4
删除资源A2：Delete Url A2

然而实际上多数人都这么做

获取资源A1：Get Url A1
新增资源A4：Post Url A + RAWDATA 4
修改资源A4：Post Url A4 + RAWDATA 4
删除资源A2：Get Url delete A1

即使是新浪的微博都 POST Url+access_token + RAWDATA empty 的方式使用。更多的人都在用 Get + delete 参数的方式来实现，不知道他们的理由是不知道、不理解、还是不愿意。

再者，网络环境恶劣，其实很多情况下我们网络的80端口是被劫持的么，而二级运营商则几乎100%都是被劫持的。某些设备劫持之后会代理你进行http访问，而这些设备是不认识其他请求方式的。代理不认识，就无法进行正常的识别和转发，这就导致其它协议无法正常使用。

某些二级运营商的劫持设备，Get、Post、Connection，如果遇到其他请求方式，就会返回你403错误或者500或者502。像现在有大量的跨域请求需要Option，遇到这种网络就完全报废了。本身这里就很不正常了，然而它返回的状态码也是错的，错误的请求方式，一般都是400、405等，但指责一个本身就不正常的设备有小毛病，是没有意义的。
（以上回答摘自：https://segmentfault.com/q/1010000007736404）

版本(version)

报文所使用的 HTTP 版本格式为 HTTP/<major>.<minor>，其中主要版本号(majoi) 和 次要版本号(minor)都是整数。版本号的说明是指应用程序支持的最高 HTTP 版本，而非明确的某一版本。与 HTTP 1.1 的应用程序进行通信的 HTTP 1.2 应用程序应该知道它不能支持任何 HTTP 1.2 的新特性，最多只能支持到 HTTP 1.1 的特性。

状态码(status)和原因短语(reason-phrase)

状态码和原因短语是服务器用来告诉客户端发生了什么的描述。原因短语 是 状态码 的可读版本，对人类阅读解释状态码有重要意义。比如：服务器返回状态码 304 Not Modified ，其中原因短语 Not Modified 就是对 状态码 304 的解释，可读性和可记忆性更强。
状态码位于响应报文的起始行中，通过三个数字代码对不同状态码进行分类，如下表，

缓存
200 ok / 200 from cache/ 200 from disk cache/ 304 not modified

首部(Headers)

通用首部
有些首部提供了与报文相关的最基本的信息，被称为通用首部。这些首部既可以用于请求报文，也可以用于响应报文。

请求首部
请求首部是只在请求报文中有意义的首部。用于说明是谁或说明在发送请求、请求来自何处，或者客户端的喜好及能力。

请求首部字段 Referer
一般Referer主要用于统计，像百度统计可以通过 Referer 统计访问流量的来源和搜索的关键词。Referer 是由浏览器自动加上的，刷新页面也不会消失，但某些情况不会发送 Referer 头部，如下：
● 直接输入网址或通过浏览器书签访问
● 来源页面采用的协议为表示本地文件的 "file" 或者 "data" URI
● 当前请求页面采用的是非安全协议，而来源页面采用的是安全协议 HTTPS（摘自 https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Referer， 对此持有怀疑态度，验证未通过，验证结果详情参见下文）

通过 Google 搜索 “风铃” ，然后访问 zhan.qq.com ，可以看到请求头中包含 referer 头部，显示 https://www.google.com.hk/（风铃的域名是 zhan.qq.com）, 如下图，

Google搜索风铃.png

直接在浏览器中输入网址： zhan.qq.com 可以看到，请求头中并没有出现 referer 头部，如下图，

直接输入网址访问.png

通过 file 协议地址跳转至目标网站 zhan.qq.com ，可以看到，请求头中依旧没有出现 referer 头部，如下图，

file 协议地址.png

file 协议跳转至风铃.png

Google 安全协议 HTTPS 跳转至 智慧校园 非安全协议 HTTP 依旧有 referer 出现 ，与 https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Referer 中描述的 “当前请求页面采用的是非安全协议，而来源页面采用的是安全协议 HTTPS ” 该情况不会产生 referer不一致，

https协议跳转至http协议.png

响应首部
响应报文有自己的首部集，首部集为客户端提供一些额外的信息，比如 谁在发送响应、响应者的功能，甚至与响应相关的一些特殊指令。

实体的主体部分

实体首部提供了有关实体机器内容的大量信息，从有关对象类型的信息，到能够对资源使用的各种有效的请求方法。

Cache-Control与Expires的作用一致，Last-Modified与ETag的作用也相近。Cache-Control 与 ETag 出现于较新的 HTTP/1.1 版本，优先级高于 Expires 和 Lat-Modified 。一般情况使用两对中的一对即可。Cache-Control 和 ETag 决定了 服务器是否返回 304 状态码， 详情请参考 http://mp.weixin.qq.com/s/k-ZtFUG674V0WAdQs3li8Q

如果想知道 请求结果 200 from cache， 304 的区别，具体可以参看： http://mp.weixin.qq.com/s/O6Ko7Sl3zsyzqGz9K_ORRw， 而两者最大的区别是 200 from cache 不会向服务器发送请求，而 304 会向服务器发送请求，只是不会下载资源文件。

下图是京东(www.jd.com)首页请求部分截图，出现了 200 from disk cache 和 200 from memory cache ， 两者由之前的 from cache 演变而来，如果想知道二者的区别，请参看 https://www.quora.com/What-is-the-difference-between-memory-cache-and-disk-cache-in-Chrome, 大意是 内存 比 硬盘读取速度快很多，但内存会随着进程的关闭（浏览器的关闭）而清除，但硬盘上的则不会，所以浏览器会根据实际情况选择两种缓存方式，先从内存中读取资源，没有，再从硬盘读取，再没有，发送请求，此时服务器可能返回 304，也可能返回 200 OK，不会返回 200 from disk cache 或 200 from memory cache。

disk cache & memory cache.jpg

【参考内容】
1.《HTTP 权威指南》David Gourley 等编. 陈涓 赵振平译. 人民邮电出版社

2. https://bindog.github.io/blog/2014/11/18/http-referer-security-and-anti-anti-hotlink/

只有足够努力，才能看起来好不费力。—— 妖艳货