计网 | 您所在的位置:网站首页 › wireshark追踪udp流 › 计网 |
介绍
这次抓包实践的目的是搞清楚腾讯视频Windows客户端在点播视频的时候,视频数据是如何传输来到客户端的。 最终分析得出结论,腾讯视频Windows客户端(具体版本见正文)点播视频时,使用了资源重定向、智能DNS等帮助客户端选择稳定的服务器;视频流采取了“两级分段”进行传输。 检查网络连接情况,确保网络相对稳定;关闭除腾讯视频以外的其它联网软件和不相关的后台联网程序,减少干扰方便筛查。 实验软硬件设备与环境情况: 名称值操作系统Windows 11 家庭中文版22H2 64位内存16GBCPUIntel(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的统计菜单中查看协议分级统计,可以看到在物理层和数据链路层,全部都是以太网数据帧,这毋庸置疑。
而在网络层,按照分组百分比,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载荷是由多个帧的载荷片段组成的数据,共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数据分段传输的方式。下面我们尝试追踪这一过程。右键第一个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请求服务器最终视频来源服务器备注0183.240.185.49(C)183.240.185.49(C)成功传输,但较为拥塞1183.240.185.49(C)120.239.31.119(B)302 Found重定向,自C至B2183.240.185.49(C)120.239.31.119(B)302 Found重定向,自C至B3183.240.185.49(C)120.240.53.147(A)302 Found重定向,自C至A4183.240.185.49(C)120.240.53.147(A)302 Found重定向,自C至A5183.240.185.49(C)120.240.53.147(A)302 Found重定向,自C至A6183.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传输开销控制传输内容cipClient IP,客户端IP智能DNScproCLient Province,客户端所在省份智能DNScispClient 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值,以及GET请求地址。然后用postman软件使用该token发送GET请求,若成功返回的视频则token标记为可用状态,若提示403 Forbiden则认为token失效。 实验1token获取时间:May 11, 2022 23:27:24.882626000 中国标准时间 token值:d1cff9e262acfef8fe0e5ac94a136c41 测试序号时间token状态1Wed, 11 May 2022 15:53:55 GMT可用2Thu, 12 May 2022 00:18:37 GMT失效 实验2token获取时间:May 12, 2022 08:21:41.813782000 中国标准时间 token值:49fec6af5a10daf74f5174e70f6baca2 测试序号时间token状态1Thu, 12 May 2022 00:24:07 GMT可用2Thu, 12 May 2022 01:59:21 GMT可用3Thu, 12 May 2022 06:32:12 GMT失效可见token存活时间不超过6小时。 点播请求回复前一节的抓包过程解释了点播请求的HTTP Response是如何传输到本机的。如下图, 将HTTP Response中的HTTP数据载荷(File Data)导出为字节流后,是一个TS视频文件,可以正常播放。 该视频只有10秒,可以很容易想到这是由于腾讯视频点播视频时,每次只会缓冲视频的一段。如下图,红框内的红色圆圈为当前视频帧所处位置,而浅灰色段表示已经缓冲的视频段,浅灰色段后面则还未缓冲。
文章首发:ranlychan.top/archives/48… |
CopyRight 2018-2019 实验室设备网 版权所有 |