“当前已有100+用户参与分享，共计发放奖励50000+“
案例总结： 一般出现0窗口数据包的情况，是由客户端或者服务器性能不足引起的，但这次的案例引发的0窗口情况，是由应用系统层面导致的，需要通过优化应用层面的资源调用来处理。
一．问题情况描述 1.通过业务性能分析系统）对“eps.haxxx.com.cn”进行业务性能监控，发现UPM上每隔5至10分钟，就会有警报显示“eps.haxxx.com.cn”出现主机性能不足的情况； 2.通过进行一步数据挖掘，发现是IP为“10.16.20.2”有发送TCP 0窗口报文的情况； 3.需要对“10.16.20.2”进行解包分析，确认是否出现性能不足的问题，分析情况如下：
二．TCP发送0窗口的问题分析 2.1 服务器发送TCP 0窗口的报文说明 根据TCP滑动窗口机制：某些情况下，可能是由于服务器内存不足，处理能力不够，或应用窗口限制的原因，服务器端无法继续处理从客户端接收的数据。为避免造成数据被丢弃以及传输中断，服务器端会发送窗口为0的报文。当客户端接收到此报文时，它会暂停所有数据传输，客户端会传输探测(keep-alive)报文的方式，保持与服务器的连接。探测报文在客户端与服务器之间发送，以检测服务器端窗口状态。一旦服务器端能够再次处理数据，将会返回非零值窗口到客户端，恢复数据传输。
2.2 数据包解包分析 1. 通过对其中一个触发警报的数据包进行解包，确认数据包报文里面有TCP 0窗口报文，排除系统误报，解包情况见下图：
2. 服务器发送TCP 0窗口时，在下一个数据包就会进行窗口释放（发送非0窗口报文），释放报文发送时间短（相隔0.000007秒），并且客户端没有出现发送传输探测(keep-alive)报文的情况，表示服务器方面并无出现明显的卡顿情况，相关情况见下图： (服务器发送0窗口数据包报文)
（服务器释放窗口报文）
3. 与服务器管理人员确认，在服务器发送TCP 0窗口报文的时段，在服务器资源监控系统上并未发现有服务器性能不足的警报，下一步需要对窗口报文进行深挖掘，确认是否存在应用系统方面的问题。
4. 对比10.16.20.2分别与10.150.97.201（有TCP 0窗口警报）、10.16.21.1（无TCP 0 窗口警报）、10.16.20.1（无TCP 0 窗口警报）的数据包交付情况，发现服务器接收10.150.97.201发送数据的载荷长度，远大于接收10.16.21.1和 10.16.20.1发送的数据包载荷长度，并且服务器并无出现CPU和内存占用率高的情况，判断是应用系统限制了相关的数据包处理能力，或者是客户端发送的数据载荷长度过大，导致出现TCP 0窗口警报的情况，详情见下图：
（有TCP 0窗口）
（有TCP 0窗口）
（无TCP 0窗口）
（无TCP 0窗口）
1. 从服务器性能监控情况看，发送TCP 0 窗口的情况与服务器性能不足无关； 2. 从接收数据包的对比情况看，判断是应用程序限制了相关的数据包处理能力； 3. 从现时TCP 窗口的释放情况看，窗口释放的时间很短（小于0.001秒），客户端不会感知到有访问卡顿的情况。但是，当访问量变得越来越大，出现TCP 0窗口的警报只会越加频繁，卡顿的情况可能会越发明显。
3.2 问题处理建议 1. 通过优化数据包传输，缩短客户端发送数据包的载荷长度，使应用有足够的时间和性能来处理项相关的数据； 2. 因为服务器并未出现CPU或内存资源不足的情况，可以通过增大应用系统的TCP窗口，调用更多的计算资源来处理相关的数据。
| 
楼主
发表于 2020-8-29 22:55
发表于 2020-8-31 11:38
工程师2级 
