参考博客：https://cloud.tencent.com/developer/article/2183902

一、HTTP协议概述

HTTP（HyperText Transfer Protocol）即超文本传输协议，它是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP 是万维网（www）的数据通信的基础。

HTTP 作为一个应用层协议，它由请求和响应两部分构成，是一个标准的个客户端和服务器模型，它的主要特点：支持客户端/服务器模型、简单快速、灵活、无连接、无状态

1、简单快速

客户端向服务器发送服务请求时，只需传路径和请求方法。请求方法包括有 GET、POST、HEAD 等。每种方法规定了客户端与服务器联系的不同类型。由于 HTTP 协议简单，使得 HTTP 服务器的程序规模小，因而通信速度很快

2、灵活

HTTP 允许传输任意类型的数据对象，正在传输的类型由 Content-Type 加以标记，最常见的 4 种 Content-Type 的取值如下:

application/x-www-form-urlencoded（常见的 form 提交）：最常见 POST 提交数据的方式。浏览器的原生 form 表单，如果不设置 enctype 属性，那么最终就会以此钟方式提交数据
multipart/form-data（文件提交）：另一种非常常见的 POST 数据提交的方式。我们在使用表单上传文件时，必须让 form 的 enctyped 等于这个值
application/json（提交 json 格式的数据）：现在越来越多的人把它作为请求头，用来告诉服务端消息主体是序列化后的 JSON 字符串。由于 JSON 规范的流行，除了低版本 IE 之外的各大浏览器都原生支持 JSON.stringify，服务端语言也都有处理 JSON 的函数，使用 JSON 不会遇上什么麻烦
text/xml（提交 xml 格式的数据）：XML-RPC（XML Remote Procedure Call）。它是一种使用 HTTP 作为传输协议，XML 作为编码方式的远程调用规范

3、无连接

无连接的含义是限制每次连接只处理一个请求，服务器处理完客户端的请求，然后响应，并收到应答之后，就断开连接，这种方式可以节省传输时间。

4、无状态

HTTP 协议是无状态协议，无状态是指协议对于事务处理没有记忆能力，这种方式的一个坏处就是，如果后续的处理需要用到之前的信息，则必须要重传，这样就导致了每次连接传输的数据量增大。好处就是，如果后续的连接不需要之前提供的信息，响应就会比较快。而为了解决 HTTP 的无状态特性，出现了 Cookie 和 Session 技术.

在这里插入图片描述

二、HTTP报文结构

你也许对 TCP/UDP 的报⽂格式有所了解，拿 TCP 报⽂来举例，它在实际要传输的数据之前附加了⼀个20 字节的头部数据，存储 TCP 协议必须的额外信息，例如发送⽅的端⼝号、接收⽅的端⼝号、包序号、标志位等等。
有了这个附加的 TCP 头，数据包才能够正确传输，到了⽬的地后把头部去掉，就可以拿到真正的数据。

在这里插入图片描述

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请求报文：

在这个浏览器发出的请求报⽂⾥，第⼀⾏“GET / HTTP/1.1”就是请求⾏，⽽后⾯的“Host”“Connection”等等都属于 header，报⽂的最后是⼀个空⽩⾏结束，没有 body。
在很多时候，特别是浏览器发送 GET 请求的时候都是这样，HTTP 报⽂经常是只有 header ⽽没 body。

在这里插入图片描述

2.1 请求⾏

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

请求⾏由三部分构成：

请求⽅法：是⼀个动词，如 GET/POST，表示对资源的操作；
请求⽬标：通常是⼀个 URI，标记了请求⽅法要操作的资源；
版本号：表示报⽂使⽤的 HTTP 协议版本。

这三个部分通常使⽤空格（space）来分隔，最后要⽤ CRLF 换⾏表示结束。（图示SP代表空格）

在这里插入图片描述

下面具体说明GET的请求行

GET / HTTP/1.1\r\n
GET /live/livestream.m3u8 HTTP/1.1\r\n

在这个请求⾏⾥，“GET”是请求⽅法，“/”是请求⽬标，“HTTP/1.1”是版本号，把这三部分连起来，意思就是“服务器你好，我想获取⽹站根⽬录下的默认⽂件，我⽤的协议版本号是 1.1，请不要⽤ 1.0 或者 2.0回复我。
别看请求⾏就⼀⾏，貌似很简单，其实这⾥⾯的“讲究”是⾮常多的，尤其是前⾯的请求⽅法和请求⽬标，组合起来变化多端，后⾯我还会详细介绍。

2.2 状态⾏

看完了请求⾏，我们再看响应报⽂⾥的起始⾏，在这⾥它不叫“响应⾏”，⽽是叫“状态⾏”（statusline），意思是服务器响应的状态。

⽐起请求⾏来说，状态⾏要简单⼀些，同样也是由三部分构成：

版本号：表示报⽂使⽤的 HTTP 协议版本；
状态码：⼀个三位数，⽤代码的形式表示处理的结果，⽐如 200 是成功，500 是服务器错误；
原因：作为数字状态码补充，是更详细的解释⽂字，帮助⼈理解原因。

在这里插入图片描述

下面是一个HTTP响应报文

HTTP/1.1 200 OK\r\n

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

⽽另⼀个“GET /favicon.ico HTTP/1.1”的响应报⽂状态⾏是：

HTTP/1.1 404 Not Found

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

2.3 头部字段

请求⾏或状态⾏再加上头部字段集合就构成了 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。

⽤wireshark抓包的分析

请求报文
在这里插入图片描述

响应报文

在这里插入图片描述

2.4 常⽤头字段

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

通⽤字段：在请求头和响应头⾥都可以出现；
请求字段：仅能出现在请求头⾥，进⼀步说明请求信息或者额外的附加条件；
响应字段：仅能出现在响应头⾥，补充说明响应报⽂的信息；
实体字段：它实际上属于通⽤字段，但专⻔描述 body 的额外信息。

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

2.4.1 User-Agent

User-Agent是请求字段，只出现在请求头⾥。它使⽤⼀个字符串来描述发起 HTTP 请求的客户端，服务器可以依据它来返回最合适此浏览器显示的⻚⾯。
但由于历史的原因，User-Agent ⾮常混乱，每个浏览器都⾃称是“Mozilla”“Chrome”“Safari”，企图使⽤这个字段来互相“伪装”，导致 User-Agent 变得越来越⻓，最终变得毫⽆意义。
不过有的⽐较“诚实”的爬⾍会在 User-Agent ⾥⽤“spider”标明⾃⼰是爬⾍，所以可以利⽤这个字段实现简单的反爬⾍策略。

2.4.2 Accept

Accept是请求字段，代表客户端希望接受的数据类型。
⽐如Accept:text/xml（application/json）;代表客户端希望接受的数据类型是xml（json ）类型；
⽐如Accept: */*则说明客户端接收所有类型的数据。

2.4.3 Host

⾸先要说的是Host字段，它属于请求字段，只能出现在请求头⾥，它同时也是唯⼀⼀个 HTTP/1.1 规范⾥要求必须出现的字段，也就是说，如果请求头⾥没有 Host，那这就是⼀个错误的报⽂。
Host 字段告诉服务器这个请求应该由哪个主机来处理，当⼀台计算机上托管了多个虚拟主机的时候，服务器端就需要⽤ Host 字段来选择，有点像是⼀个简单的“路由重定向”。
例如我们的试验环境，在 127.0.0.1 上有三个虚拟主机：“www.chrono.com”“www.metroid.net”和“origin.io”。那么当使⽤域名的⽅式访问时，就必须要⽤Host 字段来区分这三个 IP 相同但域名不同的⽹站，否则服务器就会找不到合适的虚拟主机，⽆法处理。

2.4.4 Range

Range是请求字段。
⽐如Range: bytes=5001-10000 对于只需获资源的范围请求，包含⾸部字段 Range 即可告知服务器资源的指定范围。上⾯的示例表示请求获取从第 5001 字节到第 10000 字节的资源。
⽐如Range: bytes=0- 则是请求所有的数据。
接收到附带 Range ⾸部字段请求的服务器，会在处理请求之后返回状态码为 206 Partial Content 的响应。⽆法处理该范围请求时，则会返回状态码 200 OK 的响应及全部资源。

2.4.5 Connection

管理持久连接

close 断开连接

HTTP/1.1版本的默认连接都是持久连接。为此，客户端会在持久连接上连续发送请求。当服务器端想明确断开连接时，则指定 Connection ⾸部字段的值为 close 。

Connection: close

Keep-Alive 保持连接

HTTP/1.1 之前的版本的默认连接都是⾮持久连接。为此，如果想在旧版本的HTTP协议上维持持续连接，则需要指定 Connection ⾸部字段的值为 keep-alive 。
在客户单发送请求给服务器时，携带此参数和值，服务器也会加上字段和值进⾏返回响应。

Connection: keep-alive

http是⼀个⽆状态的⾯向连接的协议。

http⽆状态：⽆状态协议是指http协议本身对于事务处理没有记忆功能，服务器不知道浏览器的状态。通俗的即使你登录了，去访问同⼀个⽹站的不同⽹⻚，服务器都不会知道你是谁，如果需要记录登录⽤户的信息，⽤户操作，⽤户⾏为等数据需要使⽤cookie或session来存储。
keep-alive：从HTTP/1.1起，浏览器默认都开启了Keep-Alive，保持连接特性，客户端和服务器都能选择随时关闭连接，则请求头中为connection:close。简单地说，当⼀个⽹⻚打开完成后，客户端和服务器之间⽤于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的⽹⻚，会继续使⽤这⼀条已经建⽴的TCP连接。但是Keep-Alive不会永久保持连接，它有⼀个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。
误解：⽆状态不代表HTTP不能保持TCP连接，更不能代表HTTP使⽤的是UDP协议（⽆连接）。即使http在⽆状态下，只要客户端和服务器的头部信息connection:keep-alive，则在有效期内他们使⽤同⼀条TCP连接。

2.4.6 Date

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

2.4.7 Server

Server字段是响应字段，只能出现在响应头⾥。它告诉客户端当前正在提供 Web 服务的软件名称和版本号， Server 字段也不是必须要出现的，因为这会把服务器的⼀部分信息暴露给外界，如果这个版本恰好存在 bug，那么⿊客就有可能利⽤ bug 攻陷服务器。所以，有的⽹站响应头⾥要么没有这个字段，要么就给出⼀个完全⽆关的描述信息。
⽐如 GitHub，它的 Server 字段⾥就看不出是使⽤了 Apache 还是 Nginx，只是显示为“GitHub.com”。

在这里插入图片描述