Wireshark TS | 业务系统数据积压问题

7ACE

已于 2024-07-20 11:09:57 修改

阅读量201

点赞数

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

于 2022-05-25 20:47:35 首次发布

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

版权

NetShark 专栏收录该内容

96 篇文章 20 订阅

订阅专栏

问题背景

某天研发中心同事反馈跨数据中心服务器 A 向服务器 B 传输数据时有挺严重的积压，数据传不过去，说数据量高峰可能接近 100Mbps，就一直积压了。

考虑到上周末有过系统升级，也想咨询下网络是否有调整变更以及跨数据中心的网络传输流量相关变化等情况。

🤣 三板斧没错了，看来哪个层面排查故障，都会首先查看是否有变更。

问题分析

网络首先回溯了故障时点的前后变更信息，确认并没有相关变更，同时检查了跨数据中心的通道流量，也没有拥塞情况，远没达到线路带宽告警的阈值。

考虑到业务传输也就 100Mbps 的数据带宽，虽然觉得在数据中心内部以及数据中心之间这个量完全不是问题，但话不能说得太满，何况还是生产故障，实事求是的好。

又进一步咨询了端到端业务服务器 IP 以及故障时间点，正好是发生在业务高峰时点，在这个时间段细查了端到端的网络设备信息，初步确认非网络设备和线路带宽问题。

那么是否是应用或者系统性能问题呢？考虑这个问题连续出现了两天，研发中心同事在第二天故障时点提前做了准备并抓取了相关数据包，正好一探究竟。

跟踪文件基本信息如下：

$ capinfos 2-2.cap
File name:           2-2.cap
File type:           Wireshark/tcpdump/... - pcap
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: 65535 bytes
Number of packets:   5534
File size:           110 MB
Data size:           110 MB
Capture duration:    196.211461 seconds
First packet time:   2022-03-10 09:34:56.351199
Last packet time:    2022-03-10 09:38:12.562660
Data byte rate:      560 kBps
Data bit rate:       4487 kbps
Average packet size: 19887.27 bytes
Average packet rate: 28 packets/s
SHA256:              e1174e2d576c4ae86fecafe3b983482915ba361b8bec3b002b4856cada67c4bd
RIPEMD160:           e810177b320e64b63579732ad022d4b98a38386a
SHA1:                fe09b8e08dc24661008e9fee983d932f250f785b
Strict time order:   True
Number of interfaces in file: 1
Interface #0 info:
Encapsulation = Ethernet (1 - ether)
Capture length = 65535
Time precision = microseconds (6)
Time ticks per second = 1000000
Number of stat entries = 0
Number of packets = 5534

跟踪文件中大概抓取了 196s ，平均速率仅为 4.4 Mbps ，速率极低，与业务之前反馈的 100 Mbps 并不匹配，也许是统计口径不一样的原因。

首先查看统计信息中的会话，跟踪文件中过滤了所需的数据包，仅包含有一条 TCP Stream 0，便于排障分析。数据主要传输方向为 Server -> Client ，占了 110M 中的 109M 之多。

Jiya-01

专家信息显示有零窗口、乱序、重传和快速重传等部分问题。

Jiya-02

进一步分析

首先查看统计中的 I/O Graphs，如下

Jiya-03

数据传输速率波动较大，且有明显的波底，有的几乎到 0 值，以秒级间隔来说，有的时间传输完全停顿了。

按数据包 frame.time_delta_displayed 为列，并从大到小排序，可以看到有明显的大延时存在，多数在 Server -> Client 数据传输方向，最大都已经在 1s 以上。粗略统计在 20ms 以上的有 306 个数据包，占总数的 5.5%；在 100ms 以上的有 265 个数据包，占总数的 4.8%；在 500ms 以上的有 228 个数据包，占总数的 4.1 %。这个延时数据如果加在一起，简直了，数据传输速率难怪只有 4.4 Mbps 。

Jiya-04

具体是什么原因导致的呢？

首先是 Server -> Client 方向，先以排名前 3 的数据包 No.4350、No.4222、No.3622 展开分析。仔细观察，基本都是一个规律，在 Server 以一个 PSH/ACK 传输数据，经 Client ACK 确认后，Server 会在此停顿一个时间再开始下一次传输。因为此跟踪文件是在 Server 上所捕获（以 Len 大于 1514 以及 TTL 64 来判断），这样的停等时间更多的矛头指向了 Server 应用本身。

Jiya-05