“当前已有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窗口,调用更多的计算资源来处理相关的数据。
|