某用户网络问题分析报告
故障现象描述
1.故障现象描述
某公司总部业务内网IP电话系统中，一台位于办公区的IP电话管理系统主机（vSphere虚拟机）10.10.15.191需要定期与位于核心区的一台服务器（也是vSphere虚拟机）10.10.36.50通信，传递IP电话状态信息。

10.10.36.50是一台WebSphere应用服务器，在应用服务器的日志中不定期会出现10.10.15.191客户端无响应导致会话超时的错误警报。

2.环境描述
发生问题的两台主机之间的网络逻辑结构示意图如下：
发生问题的客户机与服务器的通信需要经过两道防火墙以及多台网络设备，两台防火墙均未配置内网间NAT地址翻译。

1.2.分析方案设计
1.分析目标
鉴于发生问题的两台主机间网络设备较多，初步怀疑是防火墙故障阻断了两台主机间的数据传输导致会话超时。

需要通过数据包解码分析验证是否中间设备故障导致，找出问题的根源。

2.分析方法
3.将科来回溯分析服务器部署在核心区，同时连接服务器接入交换机与办公网汇聚交换机，将服务
器接入端口与办公网上行端口的流量镜像到分析服务器。

利用科来回溯分析系统7*24小时不间断捕获防火墙两端的流量，根据服务器日志产生故障警报的时间回溯当时两台主机间的通信数据包。

通过两端流量分析对比，判断防火墙以及中间网络设备是否对两台主机的通信造成影响；如果中间设备没有对会话造成影响，则进一步分析定位造成故障的直接原因。

1.3.分析情况
1.正常会话行为分析
首先需要对未发生问题时段的正常会话进行解码分析，以建立两台主机间通信的行为模型。

下载正常时段10.10.15.191与10.10.36.50之间IP会话的数据包，在科来网络分析模块的TCP视图中可以看到两台主机间的会话使用10.10.36.50的TCP 9080服务端口，会话持续时间、通信数据包数量都不固定，如下图。

从其中一个会话的交易时序图中，可以看到在正常情况下TCP三次握手之后，客户端（10.10.15.191）会首先向服务器端（10.10.36.50）POST数据，如下图。

从图中还可以看出，位于防火墙两端的监控链路先后都捕获到了会话双方向完全相同的数据包，说明至少在正常时段防火墙并未阻断两台主机的通信。

在会话结束阶段，都是由服务器发送第一个FIN报文，客户机应答后向服务器发送FIN报文关闭会话，是标准的TCP四次握手关闭会话的过程，如下图。

整个会话关闭过程时间非常短，客户机在收到服务器的FIN报文后立刻就发送了应答和FIN报文。

结束阶段的报文我们也是捕获了两次，说明中间设备也未对会话关闭造成影响。

不过在正常时段，我们也发现有个别会话在传输一些数据后，客户端会停止发送数据，服务端在等待30s后关闭会话的情况；而这种情况下，客户机在接收的FIN报文并作出ACK应答后会等待一段时间再发送FIN报文关闭会话。

服务器发送FIN报文并接收到客户机的ACK之后，如果没有立刻接收到客户端发送的FIN报文，则服务器的会话会处在半关闭状态（FIN-WAIT2状态），如果半关闭状态时间过长超过了服务器的tcp-fin-timeout，服务器就会强行终止会话并在日志中记录会话超时（tcp-fin-timeout因操作系统而异，一般不超过180秒）。

在上图的会话中客户端2秒之后发送的FIN报文，因此会话正常关闭，服务器没有会话超时记录。

在上述停顿的时间内，两条监控链路都没有捕获客户端的数据，说明确实是客户端没有发送数据，并非中间设备阻断了客户端数据传输。

通常情况客户机如果还有数据需要发送才会暂缓发送FIN报文，但从上面的情况看客户机并未再发送任何应用数据，因此怀疑停顿是由客户端应用系统问题导致的。

2.异常时段会话行为分析
通过服务日志记录我们调取12月27日凌晨3点左右发送问题时段的数据包，从中发现了明显有问题的会话，如下图。

在三次握手建立TCP连接之后，客户机没有发送任何数据，服务器在等待124秒之后向客户机发送“Request Timeout”，并立即发送FIN报文请求关闭会话，这正是服务器日志记录会话超时的时间。

从这个会话中还能够看出客户机在接收到服务器的FIN报文后，立刻回应了ACK确认，而且两条监控链路都捕获了相关报文，说明在此时刻中间网络通路没有问题并且客户机操作系统的TCP协议进程也没有问题；但是客户机回应服务器的FIN报文后并没有立即发送FIN报文关闭会话，而是在176秒后才发送RST报文终止会话，在此期间客户机也没有再使用这个会话发送任何数据（如下图），因此可以判断客户机的应用程序对这个会话的处理出现了问题。

除了这个客户机完全没有发送应用数据的会话外，27日凌晨3点左右还有一些会话出现了客户机发送了一些数据后不再继续POST数据，导致服务器在30秒后发送FIN报文关闭会话，而客户机很长时间后才向服务器发送FIN报文导致服务器出现tcp-fin-timeout超时情况，如下图。

服务器出现tcp-fin-timeout后也会在日志中记录客户端无响应会话超时的警报。

在其他服务器日志出现警报记录的时间我们也发现了类似的情况，如下图26日14:40分左右的会话。

1.4.分析结论
通过上述数据包解码分析，我们可以得出以下结论：
首先，排除了网络传输和防火墙导致服务器产生错误警报的可能性，在两条监控链路上捕获到10.10.15.191与10.10.36.50的会话数据包完全一致，说明中间链路没有阻断两台主机的通信。

网络传输中没有出现重传，三次握手时间很短，说明网络中没有丢包，网络时延也很短，网络服务质量也没问题。

客户机操作系统在接收到服务器的报文后（包括FIN报文）很快以ACK报文应答，说明客户机操作系统的TCP进程没有问题。

客户机的应用程序会不定期的出现停止传送数据的情况，有时会在接收到服务器关闭会话的FIN报文后很长时间才发送客户端FIN报文，这是导致服务器出现会话中断警报的主要原因。

这很可能是客户机应用程序会话处理功能模块的问题导致，建议与应用系统厂家联系协调优化客户端应用程序。