参考来源：

极客时间-透视HTTP协议(作者：罗剑锋)；
web抓包实战课-陶辉；

01-HTTP协议请求-应答过程

最简单的浏览器 HTTP 请求过程

1. 浏览器从地址栏的输入中获得服务器的 IP 地址和端口号；
2. 浏览器用 TCP 的三次握手与服务器建立连接；
3. 浏览器向服务器发送拼好的报文；
4. 服务器收到报文后处理请求，同样拼好报文再发给浏览器；
5. 浏览器解析报文，渲染输出页面。
   

02-HTTP协议的请求报文和响应报文的结构

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

1. 起始行（start line）：描述请求或响应的基本信息；
2. 头部字段集合（header）：使用 key-value 形式更详细地说明报文；
3. 消息正文（entity）：实际传输的数据，它不一定是纯文本，可以是图片、视频等二进制数据。

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

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

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

请求行由三部分构成：

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

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

状态行由三部分构成

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

03-头部字段

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

1. 字段名不区分大小写，例如“Host”也可以写
   成“host”，但首字母大写的可读性更好；
2. 字段名里不允许出现空格，可以使用连字符“-”，但不
   能使用下划线“_”。例如，“test-name”是合法的字
   段名，而“test name”“test_name”是不正确的字段
   名；
3. 字段名后面必须紧接着“:”，不能有空格，而“:”后的
   字段值前可以有多个空格；
4. 字段的顺序是没有意义的，可以任意排列不影响语义；
5. 字段原则上不能重复，除非这个字段本身的语义允许，例
   如 Set-Cookie。

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

1. 通用字段：在请求头和响应头里都可以出现；
2. 请求字段：仅能出现在请求头里，进一步说明请求信息或
   者额外的附加条件；
3. 响应字段：仅能出现在响应头里，补充说明响应报文的信
   息；
4. 实体字段：它实际上属于通用字段，但专门描述 body 的
   额外信息。

请求字段-Host字段

首先要说的是Host字段，它属于请求字段，只能出现在请
求头里，它同时也是唯一一个 HTTP/1.1 规范里要求必须出
现的字段，也就是说，如果请求头里没有 Host，那这就是
一个错误的报文。

Host 字段告诉服务器这个请求应该由哪个主机来处理，当
一台计算机上托管了多个虚拟主机的时候，服务器端就需要
用 Host 字段来选择，有点像是一个简单的“路由重定
向”。

请求字段-User-Agent

User-Agent是请求字段，只出现在请求头里。它使用一个
字符串来描述发起 HTTP 请求的客户端，服务器可以依据它
来返回最合适此浏览器显示的页面。

但由于历史的原因，User-Agent 非常混乱，每个浏览器都
自称是“Mozilla”“Chrome”“Safari”，企图使用这个
字段来互相“伪装”，导致 User-Agent 变得越来越长，最
终变得毫无意义。

通用字段-Date字段-Server字段

Date字段是一个通用字段，但通常出现在响应头里，表示
HTTP 报文创建的时间，客户端可以使用这个时间再搭配其
他字段决定缓存策略。

Server字段是响应字段，只能出现在响应头里。它告诉客户
端当前正在提供 Web 服务的软件名称和版本号，例如在我
们的实验环境里它就是“Server: openresty/1.15.8.1”，
即使用的是 OpenResty 1.15.8.1。

Server 字段也不是必须要出现的，因为这会把服务器的一
部分信息暴露给外界，如果这个版本恰好存在 bug，那么黑
客就有可能利用 bug 攻陷服务器。所以，有的网站响应头
里要么没有这个字段，要么就给出一个完全无关的描述信
息。

实体字段-Content-Length

实体字段里要说的一个是Content-Length，它表示报文里
body 的长度，也就是请求头或响应头空行后面数据的长
度。服务器看到这个字段，就知道了后续有多少数据，可以
直接接收。如果没有这个字段，那么 body 就是不定长的，
需要使用 chunked 方式分段传输。

04-请求头里的请求方法

目前 HTTP/1.1 规定了八种方法，单词都必须是大写的形式

1. GET：获取资源，可以理解为读取或者下载数据；
2. HEAD：获取资源的元信息；
3. POST：向资源提交数据，相当于写入或上传数据；
4. PUT：类似 POST；
5. DELETE：删除资源；
6. CONNECT：建立特殊的连接隧道；
7. OPTIONS：列出可对资源实行的方法；
8. TRACE：追踪请求 - 响应的传输路径。

请求头中的请求方法-01-GET/HEAD

GET方法应该是 HTTP 协议里最知名的请求方法了，也应该
是用的最多的，自 0.9 版出现并一直被保留至今，是名副其
实的“元老”。

它的含义是请求从服务器获取资源，这个资源既可以是静态
的文本、页面、图片、视频，也可以是由 PHP、Java 动态
生成的页面或者其他格式的数据。

GET 方法虽然基本动作比较简单，但搭配 URI 和其他头字
段就能实现对资源更精细的操作。

例如，在 URI 后使用“#”，就可以在获取页面后直接定位
到某个标签所在的位置；使用 If-Modified-Since 字段就变
成了“有条件的请求”，仅当资源被修改时才会执行获取动
作；使用 Range 字段就是“范围请求”，只获取资源的一
部分数据。

HEAD方法与 GET 方法类似，也是请求从服务器获取资
源，服务器的处理机制也是一样的，但服务器不会返回请求
的实体数据，只会传回响应头，也就是资源的“元信息”。
HEAD 方法可以看做是 GET 方法的一个“简化版”或
者“轻量版”。因为它的响应头与 GET 完全相同，所以可
以用在很多并不真正需要资源的场合，避免传输 body 数据
的浪费。

请求头中的请求方法-02-POST/PUT

POST 也是一个经常用到的请求方法，使用频率应该是仅次
于 GET，应用的场景也非常多，只要向服务器发送数据，用
的大多数都是 POST。

PUT 的作用与 POST 类似，也可以向服务器提交数据，但
与 POST 存在微妙的不同，通常 POST 表示的是“新
建”“create”的含义，而 PUT 则是“修
改”“update”的含义。

在实际应用中，PUT 用到的比较少。而且，因为它与 POST
的语义、功能太过近似，有的服务器甚至就直接禁止使用
PUT 方法，只用 POST 方法上传数据。

请求头中的其他方法

讲完了 GET/HEAD/POST/PUT，还剩下四个标准请求方
法，它们属于比较“冷僻”的方法，应用的不是很多。

DELETE方法指示服务器删除资源，因为这个动作危险性太
大，所以通常服务器不会执行真正的删除操作，而是对资源
做一个删除标记。当然，更多的时候服务器就直接不处理
DELETE 请求。
CONNECT是一个比较特殊的方法，要求服务器为客户端和
另一台远程服务器建立一条特殊的连接隧道，这时 Web 服
务器在中间充当了代理的角色。
OPTIONS方法要求服务器列出可对资源实行的操作方法，
在响应头的 Allow 字段里返回。它的功能很有限，用处也不
大，有的服务器（例如 Nginx）干脆就没有实现对它的支
持。

TRACE方法多用于对 HTTP 链路的测试或诊断，可以显示
出请求 - 响应的传输路径。它的本意是好的，但存在漏洞，
会泄漏网站的信息，所以 Web 服务器通常也是禁止使用。

05-服务器的几种响应方式

比如，你发起了一个 GET 请求，想获取“/orders”这个文
件，但这个文件保密级别比较高，不是谁都能看的，服务器
就可以有如下的几种响应方式：

1. 假装这个文件不存在，直接返回一个 404 Not found 报
   文；
2. 稍微友好一点，明确告诉你有这个文件，但不允许访问，
   返回一个 403 Forbidden；
3. 再宽松一些，返回 405 Method Not Allowed，然后用
   Allow 头告诉你可以用 HEAD 方法获取文件的元信息。