Wireshark TS | 视频 APP 无法播放问题

7ACE

已于 2024-07-20 11:11:28 修改

阅读量658

点赞数

分类专栏： NetShark 文章标签： wireshark 网络网络协议 tcpdump tcp/ip

于 2022-06-21 08:15:19 首次发布

本文链接：https://blog.csdn.net/weixin_47627078/article/details/125383948

版权

NetShark 专栏收录该内容

94 篇文章 19 订阅

订阅专栏

问题背景

该问题案例来自于朋友分享，问题用户反应一款网络视频 APP 通过移动 WIFI 和流量均无法观看，但电信流量就一切正常。初步感觉像是视频服务被移动运营商屏蔽的原因，但根据实际数据包跟踪文件分析下来，实际原因并非如此。

😂 好吧，这次错怪你了，移动~ 简单记录一下故障排查过程。

问题信息

电信

正常数据包跟踪文件（TV-01.pcapng）基本信息如下，跟踪文件在 Windows 上通过 Wireshark 所捕获，数据包数量 1633，平均速率 776 kbps 。

$ capinfos TV-01.pcapng
File name:           TV-01.pcapng
File type:           Wireshark/... - pcapng
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: (not set)
Number of packets:   1633
File size:           1556 kB
Data size:           1502 kB
Capture duration:    15.493249 seconds
First packet time:   2022-04-18 18:16:51.016785
Last packet time:    2022-04-18 18:17:06.510034
Data byte rate:      97 kBps
Data bit rate:       776 kbps
Average packet size: 920.37 bytes
Average packet rate: 105 packets/s
SHA256:              1b7e316c0c85084fcd5260bf514f4f68835f4c9d585499a4f815c2db00b9b0a0
RIPEMD160:           c439e8e92cbb016269267561734bd55dcda9b5cd
SHA1:                2299414bd2642647d0fb1ad2701a7370e648b1f0
Strict time order:   True
Capture hardware:           Intel(R) Core(TM) i3-3110M CPU @ 2.40GHz (with SSE4.2)
Capture oper-sys:    64-bit Windows 7 Service Pack 1, build 7601
Capture application: Dumpcap (Wireshark) 3.2.18 (v3.2.18-0-gddf8072b7671)
Number of interfaces in file: 1
Interface #0 info:
                     Name = \Device\NPF_{7861B556-A3C3-4557-AD97-65E9E8B3A8DC}
                     Description = 无线网络连接
                     Encapsulation = Ethernet (1 - ether)
                     Capture length = 262144
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Time resolution = 0x06
                     Operating system = 64-bit Windows 7 Service Pack 1, build 7601
                     Number of stat entries = 1
                     Number of packets = 1633

移动

异常数据包跟踪文件（TV-02.pcapng）基本信息如下，跟踪文件在 Windows 上同样通过 Wireshark 所捕获，数据包数量 803，平均速率只有 97 kbps ，对比电信确实不正常，和视频 APP 播放所显示的 0.0kb/s 问题现象基本匹配。

$ capinfos TV-02.pcapng
File name:           TV-02.pcapng
File type:           Wireshark/... - pcapng
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: (not set)
Number of packets:   803
File size:           489 kB
Data size:           461 kB
Capture duration:    37.704609 seconds
First packet time:   2022-04-18 17:53:51.743014
Last packet time:    2022-04-18 17:54:29.447623
Data byte rate:      12 kBps
Data bit rate:       97 kbps
Average packet size: 574.81 bytes
Average packet rate: 21 packets/s
SHA256:              5abadf00874c27d191feb9f84772867ed1b94a7a71e8295727fc4e5ee201bd02
RIPEMD160:           35a619df088164fadc413d4d223df30f9899e6f3
SHA1:                a41044db201276a7b1a2cb6dfd9545bc7848d9a4
Strict time order:   True
Capture hardware:           Intel(R) Core(TM) i3-3110M CPU @ 2.40GHz (with SSE4.2)
Capture oper-sys:    64-bit Windows 7 Service Pack 1, build 7601
Capture application: Dumpcap (Wireshark) 3.2.18 (v3.2.18-0-gddf8072b7671)
Number of interfaces in file: 1
Interface #0 info:
                     Name = \Device\NPF_{7861B556-A3C3-4557-AD97-65E9E8B3A8DC}
                     Description = 无线网络连接
                     Encapsulation = Ethernet (1 - ether)
                     Capture length = 262144
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Time resolution = 0x06
                     Operating system = 64-bit Windows 7 Service Pack 1, build 7601
                     Number of stat entries = 1
                     Number of packets = 803

APP-01

结合专家信息的简单浏览，存在些乱序、重传和快速重传的现象。

APP-02

问题分析

电信

进入数据包实际分析，首先从正常电信开始，其中的 TCP Stream 4 显示基本正常，包括 TCP 三次握手、客户端 GET 请求、服务器端 HTTP 206 响应以及视频数据传输等过程。

APP-03

APP-04

移动

移动异常数据包中，部分 TCP Stream 有明显的疑似重传现象，以下以 Stream 1 为例说明

APP-05

基本面分析如下：

捕获是在客户端上进行，因为数据包 length 只有 54 字节，进入网卡传输之前并未填充至以太网帧最小标准 60 字节长度；
TCP 三次握手，其中 MSS 1400、SACK 支持等；
TCP 疑似重传，长度为 1106 字节的数据包不断重复疑似重传和 DUP ACK 问题现象；
IRTT 时间约 24ms 左右。

什么是 TCP Spurious Retransmission ? 其实这是 Wireshark 对于上下文数据包的一个关联分析，简单来说就是在前面我看到了一个 TCP 分段，也看到了对这个分段的确认，一来一回已经完成一次交互了，但是在之后我又看到了同样一个 TCP 分段，对我来说它就属于疑似重传，自然会触发一个 DUP ACK 生成。

当 Nagle 遇上延迟 ACK

实际上这个问题是一个很经典的 当 Nagle 遇上延迟 ACK 问题，以下不就 Nagle 算法和延迟 ACK 做具体展开，引用下网上部分资料：

Nagle 算法

if there is new data to send
  if the window size >= MSS and available data is >= MSS
    send complete MSS segment now
  else
    if there is unconfirmed data still in the pipe
      enqueue data in the buffer until an acknowledge is received
    else
      send data immediately
    end if
  end if
end if

具体的做法：

如果发送内容大于等于 1 个 MSS，立即发送；
如果之前没有包未被 ACK，立即发送；
如果之前有包未被 ACK，缓存发送内容；
如果收到 ACK，立即发送缓存的内容。

延迟 ACK
TCP Delayed ACK（延迟确认）为了努力改善网络性能，它将几个 ACK 响应组合合在一起成为单个响应，或者将 ACK 响应与响应数据一起发送给对方，从而减少协议开销。

具体的做法：

当有响应数据要发送时，ACK 会随响应数据立即发送给对方；
如果没有响应数据，ACK 将会延迟发送，以等待看是否有响应数据可以一起发送；
如果在等待发送 ACK 期间，对方的第二个数据包又到达了，这时要立即发送 ACK。但是如果对方的三个数据包相继到达，第三个数据段到达时是否立即发送 ACK，则取决于以上两条。

Nagle 算法和延迟 ACK

回到移动的实际问题

APP-06

Client 和 YdServer 进行数据传输 : YdServer 运行 Nagle 算法，Client 运行 Delayed ACK 算法。
如果 YdServer 向 Client 发送一个数据包 No.398 ，Client 由于 Delayed ACK 不会立即响应。而 YdServer 使用 Nagle 算法，YdServer 就会一直等 Client 的 ACK，ACK 不来一直不发送第二个数据包，那这个请求就会被耽误了 200ms，之后 Client 才发送了 No.400 ACK ，而 YdServer 由于收不到确认，进行了 No.401 超时重传，所以在客户端本地抓包判断为疑似重传，Client 触发产生了 No.402 DUP ACK。
之后以 No.398、No.400-No.402 这样的4个包为类似规律，一直重复。

重复到 No.602 和 No.612 之后突然没有这规律了，为什么？因为 RTO ，动态的调整而增大，所以 No.612 ACK 返回到 YdServer 后，YdServer 还没有来得及超时重传。但是整个交互因为这种异常问题，造成数据传输缓慢，使得 APP 无法正常使用，页面显示 0.0kb/s 现象。

APP-07