介绍
这次抓包实践的目的是搞清楚腾讯视频Windows客户端在点播视频的时分，视频数据是怎么传输来到客户端的。
终究剖析得出结论，腾讯视频Windows客户端（具体版本见正文）点播视频时，运用了资源重定向、智能DNS等协助客户端挑选稳定的服务器；视频流采取了“两级分段”进行传输。
视频点播抓包进程
准备阶段
检查网络衔接状况，保证网络相对稳定；关闭除腾讯视频以外的其它联网软件和不相关的后台联网程序，减少搅扰方便筛查。
试验软硬件设备与环境状况：
| 称号 | 值 |
|---|---|
| 操作系统 | Windows 11 家庭中文版22H2 64位 |
| 内存 | 16GB |
| CPU | Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz 2.20 GHz |
| 抓包软件 | Wireshark Version 3.6.3 |
| 被测渠道 | 腾讯视频64位Windows客户端 2022 11.44 （11.44.7076.0） |
正式抓取
- 打开腾讯视频并登录，然后打开Wireshark，挑选上网卡，点击录制；接着在腾讯视频精选栏目->今日热点内点开一个短视频进行播映，视频清晰度默认为720P且不会再改变。
- 等待视频缓冲和播映完结后，在Wireshark停止录制活动。下图为抓取完结后的Wireshark界面截图。
成果开端计算、整理与剖析
基本计算
协议分级计算
首要在Wireshark的计算菜单中检查协议分级计算，能够看到在物理层和数据链路层，全部都是以太网数据帧，这毋庸置疑。
而在网络层，按照分组百分比，99.9%的包是依据IPv4的，，只要0.1%的包是依据IPv6的。这说明在抓取期间的只要极少的IPv6通讯。
在会话层，首要是依据IP的UDP、TCP、ICMP协议，其间依据IPv4的TCP协议的数据包在分组百分比和字节百分比占上均非常杰出，这说明IPv4的TCP包不仅数量多，而且总的数据载荷（以字节数衡量）也多。而咱们在抓取期间首要进行的活动（点播短视频），自然地认为应当有很多视频数据传入本机。结合计算数据，咱们开端剖析认为，视频数据经过很多的TCP包从网络传输到本机，这也意味着一个完好的视频被拆分开来进行传输。
在依据IPv的TCP协议下，能够看到分组百分比和字节数百分比占比较大的是HTTP协议，其次是TLS协议。而在HTTP协议下，值得令人注意的是，咱们看到了ISO/IEC 13818-1规范，该规范是一种描绘多个视频，音频和数据基本码流组成传输码流和节目码流的办法，隶属于MPEG-2规范。结合数据占比，几乎能够说明本次腾讯视频的短视频点播，便是在ISO/IEC 13818-1规范的根底上对音视频进行编码传输的。
会话计算
在Wireshark的计算菜单中检查会话计算，能够看到本机与网络主机之间的会话状况。首要检查IPv4下的计算状况，按照传入本机的传输字节总巨细，从大到小进行排序，能够看到本机与之进行通讯网络主机。
其间，传输数据量最大的网络主机（120.240.53.147，记为A）和次大的网络主机(120.239.31.119，记为B），其Rel Start（会话开端时刻）数字的背面制作了并表明了其会话的开端和持续时刻，也便是会话时刻段，能够看到A与B的会话时刻段是交错开的，本机一开端先与B进行很多数据传输，短暂时刻后再转而与A进行很多数据传输直到完毕。这很有或许是由于传输进程中恳求的视频数据来历中途被切换到了不同的网络主机，具体是不是下面再仔细剖析。其它主机与本机的会话则没有这种现象。
接着再在TCP层面检查会话计算，依旧是按照传入本机的传输字节总巨细，从大到小进行排序。再次看到熟悉的主机A（120.240.53.147）和主机B（120.239.31.119）。但咱们注意到，两台主机均运用49155端口，但传入本机时，本机运用了多个不同的端口进行接收。
数据过滤挑选剖析
头部根底剖析
依据协议分级计算，咱们知道了视频的传输与HTTP协议和MEPG-2规范相关。下面输入条件mpeg进行挑选，得到四个承载MEPG协议的包。后三个Source咋一看主机名竟然是localhost！这或许是Wireshark的解析bug，由于数据包里没有写主机名是localhost。
TCP传输根底剖析
对榜首个包检查时发现，其TCP载荷是由多个帧的载荷片段组成的数据，共1513个TCP片段的载荷，每个数据载荷地点的帧现已由Wireshark列举出来（红框中蓝色字），点击能够跳转检查对应帧。 这能够说明，序号为10235的榜首个TCP包承载的内容较大，所以被拆开来了再进行传送，最终在本机拼装成为完好的一个回复。查阅材料能够知道，这种办法叫做TCP数据分段传输。当TCP帧的承载数据巨细超过了MSS（Max Segment Size），为了防止IP帧分片（超过MTU），就得将承载数据拆分并封装到多个TCP帧中进行传输。
TCP分段、IP分片和MSS、MTU www.jianshu.com/p/01cde9f9b…
TCP数据传输和MSS超出分段 zhuanlan.zhihu.com/p/228800988
TCP流剖析
依据上小节的TCP传输剖析，咱们得知了TCP数据分段传输的办法。下面咱们测验追寻这一进程。右键榜首个MPEG包，挑选追寻TCP流。
将数据区字节省导出后作为视频播映，发现少了3段缓冲，一共应当有至少7段缓冲视频，而经过mpeg挑选出的只要4段。所以下面转而挑选http协议。
HTTP 302 Found状况码 developer.mozilla.org/zh-CN/docs/…
相同对恳求进行追寻，找到了第四段视频。相同没有HTTP头，只要载荷（视频字节省）。
树立衔接和恳求视频数据
树立完衔接，本机立刻向方针发送HTTP GET恳求，恳求视频数据。完好恳求URI如下： omts.tc.qq.com/AjDP1wzypfh… URI中能够看到途径被加密了，但文件名和恳求参数依旧是明文。文件名经过后缀能够知道是一个ts视频文件；参数首要为恳求视频的参数和恳求的合法性校验等。具体解析放在下一节解析进行，本小节首要描绘TCP流。
传送视频数据 在本机发送完恳求后，方针主机收到恳求，回来一个Ack=1（赤色框）表明收到接着就开端用TCP分段传输（蓝色框及下面的内容）的办法回来HTTP Response。其间服务器发给本机的榜首个分段TCP数据包的TCP头部中，ACK和PUSH标志位一起为1，表明该帧为开端。后边的分段TCP帧头部则只要ACK标志位为1。
能够看到传输进程中，不是服务器发一个TCP，本机就进行一次应对表明收到，那样功率太低。而是本机收到多个TCP包后才进行一次应对表明收到并等待下一个帧。【这种办法课上有讲过，能够弥补进去】
传输完毕并拼装TCP载荷
TCP分段地将HTTP Response传输完毕，本机发送完最终一个应对后，服务器收到应对，回来一个空载荷的TCP帧（Wireshark中序号为10235，上图红框标示），但该帧的TCP头的标志位中，PUSH和ACK再次一起为1，标志着本次TCP数据分段传输的完毕。本机主动将之前分段接收到的TCP帧的数据载荷进行拼装，作为10235号TCP帧的载荷。【这块有或许是重点内容，请查阅材料弥补：客户端怎么知道要拼装哪些帧？有没有其他值得注意的细节？】然后Wireshark就解分出来这个载荷是一个HTTP的载荷，该HTTP载荷作为本机一开端发送的HTTP恳求的Response。 拼装出来的HTTP Response相同也有载荷，被Wireshark识别为MPEG TS。关于HTTP Response的数据载荷的具体剖析依然放入下一节进行。
断开衔接
本来应该是四次挥手断开TCP衔接，这次的抓取比较特别，少了从本机发往服务器的FIN=1。【弥补一下为什么少了，为什么能够少】
具体成果剖析
点播全流程剖析
在成果的开端剖析中，咱们经过挑选MEPEG协议成功找到了四段缓冲视频，也经过TCP流追寻追查到这四段视频的传输进程。但剖析这四个视频的HTTP恳求发现，其视频index（下标从0开端）分别为2、4、5和6，一起转存HTTP载荷为视频并播映后验证，四个视频确实分别为缓冲视频的第3,5,6,和7段，其间第7段为最终一段。这意味着经过mpeg挑选的成果少了index为0、1和3的三段视频。由于抓包时确实播映完结了，所以这三段视频肯定是接收到了的，只是呈现了其他问题。所以下面转而挑选HTTP协议。
相同对恳求进行追寻，找到了第四段视频。相同没有HTTP头，只要载荷（视频字节省）。
表x 本机恳求视频缓冲片段在应用层的http会话状况
| 视频缓冲片段index | 恳求服务器 | 终究视频来历服务器 | 补白 |
|---|---|---|---|
| 0 | 183.240.185.49（C） | 183.240.185.49（C） | 成功传输，但较为拥塞 |
| 1 | 183.240.185.49（C） | 120.239.31.119（B） | 302 Found重定向，自C至B |
| 2 | 183.240.185.49（C） | 120.239.31.119（B） | 302 Found重定向，自C至B |
| 3 | 183.240.185.49（C） | 120.240.53.147（A） | 302 Found重定向，自C至A |
| 4 | 183.240.185.49（C） | 120.240.53.147（A） | 302 Found重定向，自C至A |
| 5 | 183.240.185.49（C） | 120.240.53.147（A） | 302 Found重定向，自C至A |
| 6 | 183.240.185.49（C） | 120.240.53.147（A） | 302 Found重定向，自C至A |
点播恳求头
恳求地址： omts.tc.qq.com/AjDP1wzypfh… **办法：**HTTP GET
注意，其间： 蓝色部分是加密过的途径，在恳求同一个视频的多段时是不会改变的。 紫色部分是点播m3u8结构的一个地址，可是加上了token、cost和客户端网络方位信息等选项 绿色部分和客户端网络方位信息等相关，很有或许用于智能DNS，经过归纳客户端的IP、地点省份和互联网服务提供商等信息，为客户端解析合适的服务器IP以提供优质的视频点播服务。
表x GET恳求的参数信息表
| 参数 | 释义 | 功用、效果 |
|---|---|---|
| index | 视频片段索引 | 操控传输内容 |
| start | 视频开始时刻（ms） | 操控传输内容 |
| end | 视频完毕时刻（ms） | 操控传输内容 |
| brs | 视频开始帧数 | 操控传输内容 |
| pre | 视频完毕帧数 | 操控传输内容 |
| token | 用户令牌 | 恳求合法性校验 |
| cost | 传输开支 | 操控传输内容 |
| cip | Client IP，客户端IP | 智能DNS |
| cpro | CLient Province，客户端地点省份 | 智能DNS |
| cisp | Client Information Service Provider，客户端的ISP | 智能DNS |
点播型m3u8，能够往这方面多看看 blog.csdn.net/hejjunlin/a…
start和end是恳求的视频片段的时刻起止，单位为毫秒（ms），能够直接修改end为大于视频长度的时刻，回来的为完好的视频。 brs和pre是恳求的视频片段的帧数起止，相同能够直接修改pre为大于视频帧长度的数量，回来的为完好的视频。
智能DNS cip(Client IP):客户端的IP cpro(CLient Province):客户端地点的省份 cisp(Client Information Service Provider):客户端网络的ISP
为了检验该GET恳求是否能够脱离腾讯视频客户端成功恳求和得到回来视频，下面用Postman软件来进行测验。将上面点播视频的恳求地址放到Postman里，其主动解分出GET恳求参数，点击send后，回来200 OK，回来的Body显现是乱码，但其实是视频的字节省，点击Save Response后能够正常播映。
token存活时刻长度检测试验
经过客户端播映视频抓包获取一个token，记录下获取时刻和token值，以及GET恳求地址。然后用postman软件运用该token发送GET恳求，若成功回来的视频则token标记为可用状况，若提示403 Forbiden则认为token失效。
试验1
token获取时刻：May 11, 2022 23:27:24.882626000 我国规范时刻 token值：d1cff9e262acfef8fe0e5ac94a136c41
| 测验序号 | 时刻 | token状况 |
|---|---|---|
| 1 | Wed, 11 May 2022 15:53:55 GMT | 可用 |
| 2 | Thu, 12 May 2022 00:18:37 GMT | 失效 |
试验2
token获取时刻：May 12, 2022 08:21:41.813782000 我国规范时刻 token值：49fec6af5a10daf74f5174e70f6baca2
| 测验序号 | 时刻 | token状况 |
|---|---|---|
| 1 | Thu, 12 May 2022 00:24:07 GMT | 可用 |
| 2 | Thu, 12 May 2022 01:59:21 GMT | 可用 |
| 3 | Thu, 12 May 2022 06:32:12 GMT | 失效 |
可见token存活时刻不超过6小时。
点播恳求回复
前一节的抓包进程解释了点播恳求的HTTP Response是怎么传输到本机的。如下图，
将HTTP Response中的HTTP数据载荷（File Data）导出为字节省后，是一个TS视频文件，能够正常播映。
该视频只要10秒，能够很简单想到这是由于腾讯视频点播视频时，每次只会缓冲视频的一段。如下图，红框内的赤色圆圈为当时视频帧所处方位，而浅灰色段表明现已缓冲的视频段，浅灰色段后边则还未缓冲。
文章首发：ranlychan.top/archives/48…
