0.引言
写这篇文章目的是为了能够在通过HTTP协议拉取ts流，能够看懂各类型数据包。这里也会有Wireshark使用，关于Wireshark使用和HLS分析，也可以看看前面文章。
详细分析HLS框架
手把手配置HLS流媒体服务器
HLS实战之Wireshark抓包分析
详解HTTP协议与RESTFUL
HTTP协议参考文档：https://www.kancloud.cn/spirit-ling/http-study/636182
参考文档界面：
书籍：<<图解HTTP>>
这本书使用很清晰的图片展示HTTP协议，易懂。
如果想要这本<<图解HTTP>> pdf版本，可以关注，然后私信，我发给各位朋友。如果大家有什么好书推荐的，也可以私信我，互相学习，一起进步，谢谢。
<<图解HTTP>>封面如下：
<<图解HTTP>>目录如下：
这篇文章也讲解了关于http协议的内容，可以参考，详解HTTP协议与RESTFUL
1.TCP报⽂结构
这里讲解TCP报文，是为了能够更容易了解HTTP，毕竟HTTP是以TCP为基础。如果做过开发的朋友，应该知道，对TCP/UDP报文的格式应该都有所了解。如TCP报文，在实际要传输的数据之前附加了⼀个20 字节的头部数据，其包含了TCP 协议必须的额外信息，发送⽅的端⼝号、接收⽅的端⼝号、包序号、标志位等等。通过TCP头，数据包才能够正确传输，到了⽬的地后把头部去掉，就可以拿到真正的数据。TCP基本的数据字段如下图：
类似，HTTP 协议也是与 TCP/UDP 类似，也有头部数据，与 TCP/UDP不同的是，它是⼀个“纯⽂本”的协议，所以头数据都是 ASCII 码的⽂本，可以很容易地⽤⾁眼阅读，不⽤借助程序解析也能够看懂。
HTTP 协议的请求报⽂和响应报⽂的结构基本相同，由三⼤部分组成：
(1)起始⾏（start line）：描述请求或响应的基本信息。
(2)头部字段集合（header）：使⽤ key-value 形式更详细地说明报⽂。
(3)消息正⽂（entity）：实际传输的数据，它不⼀定是纯⽂本，可以是图⽚、视频等⼆进制数据。
一般把起始⾏和头部字段经常⼜合称为“请求头”或“响应头”，消息正⽂⼜称为“实体”或响应正文，与“header”对应，很多时候就直接称为“body”。
注意:HTTP 协议规定报⽂必须有 header，但可以没有 body，⽽且在 header 之后必须要有⼀个“空⾏”，也就是“CRLF”，⼗六进制的“0D0A”。在 header 和 body 之间有⼀个“空⾏”，这个空行是用作分包使用。
关于HTTP，数据分层结构，如下图：
使用Wireshark抓包，看看是否与上面讲解的模式一样。如下图：
在这个报文里，第⼀⾏“GET / HTTP/1.1”就是请求⾏，⽽后⾯的“Host”，“Connection”等等都属于 header，报⽂的最后是⼀个空⽩⾏结束，没有body。
1.1 请求⾏
使用WireShark抓包分析
了解了 HTTP 报⽂的基本结构后，我们来看看请求报⽂⾥的起始⾏也就是请求⾏（request line），它简要地描述了客户端想要如何操作服务器端的资源。
请求⾏(或起始行)由三部分构成：
(1)请求方法：如 GET/POST，表示对资源的操作。
(2)请求⽬标：通常是⼀个 URI，标记了请求⽅法要操作的资源。
(3)版本号：报⽂使⽤的 HTTP 协议版本。
这三个部分通常使⽤空格（space）来分隔，最后要⽤ CRLF 换⾏表示结束。SP表示空格。请求行格式如下图所示：
⽤ Wireshark 抓包的数据来举例，如下图所示：
在这个请求⾏⾥，“GET”是请求⽅法，“/”是请求⽬标，“HTTP/1.1”是版本号，把这三部分连起来，客户端意思就是“服务器你好，我想获取⽹站根⽬录下的默认⽂件，我⽤的协议版本号是 1.1，请不要⽤ 1.0 或者 2.0回复我。”
别看请求⾏就⼀⾏，貌似很简单，其实这⾥⾯的“讲究”是⾮常多的，尤其是前⾯的请求⽅法和请求⽬标，组合起来变化多端，后⾯还会详细介绍。
1.2 状态⾏
使用WireShark抓包分析
看完了请求⾏，我们再看响应报⽂⾥的起始⾏，在这⾥它不叫“响应⾏”，⽽是叫“状态⾏”（status line），意思是服务器响应的状态。⽐起请求⾏来说，状态⾏要简单⼀些，同样也是由三部分构成：
(1)版本号：表示报⽂使⽤的 HTTP 协议版本。
(2)状态码：⼀个三位数，⽤代码的形式表示处理的结果，⽐如 200 是成功，500 是服务器错误。
(3)原因：作为数字状态码补充，是更详细的解释⽂字，帮助⼈理解原因。这个原因是可以合理的自定义。
注意：当301、302、303响应状态码返回时，几乎所有的游览器都会把POST改为GET，并删除请求报文内的主体，之后请求会自动再次发送
301、302标准是禁止将POST改为GET方法，但实际使用时都会改变
304的请求附加条件是指采用GET方法的请求报文中包含If-Match、If-Modified-Since、IF-None-Match、IF-Range、If-Unmodified-Since中的任一首部
4XX 的响应结果表明客户端是发生错误的原因所在
作为前端进行ajax请求时，出现5xx错误，那最大的可能是服务端出现问题。
数据存储如下图所示：
使用Wireshark抓包，其响应报⽂，状态⾏是：
HTTP/1.1 200 OK\r\n，关于描述这块是可以自定义。可以参考文档，进行合理编辑。
HTTP/1.1表示版本号。
200 OK表示状态码。
这里没有描述原因。
\r\n是换行。
HTTP/1.1 200 OK\r\n
服务端告诉客户端，意思就是：“浏览器你好，我已经处理完了你的请求，这个报⽂使⽤的协议版本号是 1.1，状态码是 200，⼀切 OK。”
如果是出错了，如下：
HTTP/1.1 404 Not Found
服务端告诉客户端，意思就是：“抱歉啊浏览器，刚才你的请求收到了，但我没找到你要的资源，错误代码是 404，接下来的事情你就看着办吧。”
1.3 头部字段
请求⾏或状态⾏再加上头部字段集合就构成了 HTTP 报⽂⾥真正完整的请求头或响应头，可以看下。
(1)请求头部字段相关，如下图所示：
(2)响应头字段相关，如下图所示：
看到这里，你会发现请求头和响应头的结构是基本⼀样的，唯⼀的区别是起始⾏。
请求头和响应头的头部字段都是 key-value 的形式，key 和 value 之间⽤“:”分隔，最后⽤ CRLF 换⾏表示字段结束。如在“Host: 192.168.111.1”这⼀⾏⾥ key 就是“Host”，value 就是“192.168.111.1”。
注意：HTTP 头字段⾮常灵活，不仅可以使⽤标准⾥的 Host、Connection 等已有头，也可以任意添加⾃定义头，这就给 HTTP 协议带来了⽆限的扩展可能。
不过使⽤头字段需要注意下⾯⼏点：
(1)字段名不区分⼤⼩写，例如“Host”也可以写成“host”，但⾸字⺟⼤写的可读性更好。
(2)字段名⾥不允许出现空格，可以使⽤连字符“-”，但不能使⽤下划线“_”。例如，“test-name”是合法的字段名，⽽“test name”，“test_name”是不正确的字段名；
(3)字段名后⾯必须紧接着“:”，不能有空格，⽽“:”后的字段值前可以有多个空格
(4)字段的顺序是没有意义的，可以任意排列不影响语义。
(5)字段原则上不能重复，除⾮这个字段本身的语义允许，例如 Set-Cookie。
1.4 常用头字段
HTTP 协议规定了⾮常多的头部字段，实现各种各样的功能，但基本上可以分为四⼤类：
(1)通⽤字段：在请求头和响应头⾥都可以出现。
(2)请求字段：仅能出现在请求头⾥，进⼀步说明请求信息或者额外的附加条件。
(3)响应字段：仅能出现在响应头⾥，补充说明响应报⽂的信息。
(4)实体字段：它实际上属于通⽤字段，但专⻔描述 body 的额外信息。
对 HTTP 报⽂的解析和处理实际上主要就是对头字段的处理，理解了头字段也就理解了 HTTP 报⽂。主要讲⼏个最基本的头，看完了它们你就应该能够读懂⼤多数 HTTP 报⽂了。
(5)User-Agent
User-Agent是请求字段，只出现在请求头⾥。它使⽤⼀个字符串来描述发起 HTTP 请求的客户端，服务器可以依据它来返回最合适此浏览器显示的⻚⾯。
但由于历史的原因，User-Agent ⾮常混乱，每个浏览器都⾃称是“Mozilla”“Chrome”“Safari”，企图使⽤这个字段来互相“伪装”，导致 User-Agent 变得越来越⻓，最终变得毫⽆意义。不过有的⽐较“诚实”的爬⾍会在 User-Agent ⾥⽤“spider”标明⾃⼰是爬⾍，所以可以利⽤这个字段实现简单的反爬⾍策略。
(6)Accept
Accept是请求字段，代表客户端希望接受的数据类型。⽐如Accept：text/xml（application/json）。代表客户端希望接受的数据类型是xml（json ）类型。⽐如Accept: */*则说明客户端接收所有类型的数据。
(7)Host
⾸先要说的是Host字段，它属于请求字段，只能出现在请求头⾥，它同时也是唯⼀⼀个 HTTP/1.1 规范⾥要求必须出现的字段，也就是说，如果请求头⾥没有 Host，那这就是⼀个错误的报⽂。
Host 字段告诉服务器这个请求应该由哪个主机来处理，当⼀台计算机上托管了多个虚拟主机的时候，服务器端就需要⽤ Host 字段来选择，有点像是⼀个简单的“路由重定向”。
如在 127.0.0.1 上有三个虚拟主机：“www.chrono.com”“www.metroid.net”和“origin.io”。那么当使⽤域名的⽅式访问时，就必须要⽤Host 字段来区分这三个 IP 相同但域名不同的⽹站，否则服务器就会找不到合适的虚拟主机，⽆法处理。
(8)Range
Range是请求字段。如Range: bytes=5001-10000 对于只需获资源的范围请求，包含⾸部字段 Range 即可告知服务器资源的指定范围。上⾯的示例表示请求获取从第 5001 字节到第 10000 字节的资源。
如Range: bytes=0，则是请求所有的数据。接收到附带 Range ⾸部字段请求的服务器，会在处理请求之后返回状态码为 206 Partial Content 的响应。⽆法处理该范围请求时，则会返回状态码 200 OK 的响应及全部资源。
(9)Connection
管理持久连接。
close 断开连接。
Connection: close
HTTP/1.1版本的默认连接都是持久连接。为此，客户端会在持久连接上连续发送请求。当服务器端想明确断开连接时，则指定 Connection ⾸部字段的值为 close 。
Keep-Alive 保持连接
keep-alive：从HTTP/1.1起，浏览器默认都开启了Keep-Alive，保持连接特性，客户端和服务器都能选择随时关闭连接，则请求头中为connection:close。简单地说，当⼀个⽹⻚打开完成后，客户端和服务器之间⽤于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的⽹⻚，会继续使⽤这⼀条已经建⽴的TCP连接。但是Keep-Alive不会永久保持连接，它有⼀个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。
Connection: keep-alive
HTTP/1.1 之前的版本的默认连接都是⾮持久连接。为此，如果想在旧版本的HTTP协议上维持持续连接，则需要指定 Connection ⾸部字段的值为 keep-alive 。客户端发送请求给服务器时，携带此参数和值，服务器也会加上字段和值进⾏返回响应。
http是⼀个⽆状态的⾯向连接的协议。
⽆状态协议是指http协议本身对于事务处理没有记忆功能，服务器不知道浏览器的状态。通俗的即使你登录了，去访问同⼀个⽹站的不同⽹⻚，服务器都不会知道你是谁，如果需要记录登录⽤户的信息，⽤户操作，⽤户⾏为等数据需要使⽤cookie或session来存储。
注意：理解无状态协议(更多理解是一种无记忆)，⽆状态不代表HTTP不能保持TCP连接，更不能代表HTTP使⽤的是UDP协议（⽆连接）。即使http在⽆状态下，只要客户端和服务器的头部信息connection:keep-alive，则在有效期内他们使⽤同⼀条TCP连接。
(10)Date，Date字段是一个通⽤字段，但通常出现在响应头⾥，表示 HTTP 报⽂创建的时间，客户端可以使⽤这个Data时间再搭配其他字段决定缓存策略。
(11) Server
Server字段是响应字段，只能出现在响应头⾥。它告诉客户端当前正在提供 Web 服务的软件名称和版本号， Server 字段也不是必须要出现的，因为这会把服务器的⼀部分信息暴露给外界，如果这个版本恰好存在 bug，那么⿊客就有可能利⽤ bug 攻陷服务器。所以，有的⽹站响应头⾥要么没有这个字段，要么就给出⼀个完全⽆关的描述信息。
⽐如 GitHub，它的 Server 字段⾥就看不出是使⽤了 Apache 还是 Nginx，只是显示为“GitHub.com”。如下图：
再⽐如srs流媒体服务器的响应，如下图：
(12)Content-Type
Content-Type是实体字段，表发送端（客户端|服务器）发送的实体数据的数据类型。⽐如：Content-Type：text/html（application/json） ; 代表发送端发送的数据格式是html（json）。
(13)Content-Length
实体字段⾥要说的⼀个是Content-Length，它表示报⽂⾥ body 的⻓度，也就是请求头或响应头空⾏后⾯数据的⻓度。服务器看到这个字段，就知道了后续有多少数据，可以直接接收。如果没有这个字段，那么 body 就是不定⻓的，需要使⽤ chunked ⽅式分段传输。文本类型的PMT数据，就会返回指定长度，如果是video或Audio数据是没有固定大小。
本篇文章就分析到这里，欢迎大家关注欢迎关注，点赞，转发，收藏，分享，评论区讨论。
后面关于项目知识，后期会更新。欢迎关注微信公众号"记录世界 from antonio"。
,
