某移动公司BOSS系统故障分析解决案例

某移动公司 BOSS系统故障分析解决案例CSNA网络分析认证培训

© 2001-2014科来版权所有

http://doc.guandang.net

一、故障描述

1、故障描述

1)

Boss系统向服务器提交订单，每天会有600个左右不成功的订单，不成功的订单需手工录入，极大的影响

工作效率；该现像已持续2-3个月； 2) 3) 4) 5)

持续ping服务器和boss，未出现任何的丢包现像； 应用部门和应用厂商检查应用程序和规则说一切正常；

网管人员检查网络设备的性能，设置（MTU、MSS等）一切正常；

管理人员说在boss系统上抓取的同步数据包大于在PIX之前抓取的数据包，怀疑有丢包，但其它应用和

ping都正常，网络丢包没有说服力。

2、网络拓扑

二、分析过程

1

、捕获数据包

订单提交不成功则有两种情况，一种是服务端未收到boss的请求，另一种则是服务端收到请求后未响应，由于

2、分析数据包

分别提取回溯系统和便携式上的数据包，进行对比分析。首先来看在6503上抓取的数据，如下图：

在6503上捕获到10.238.230.50和10.238.103.86的会话中，存在多个syn包无响应的会话，从而证实确实存在订单提成不成功的问题，而在PIX的入口并没有捕获到该会话，也就是说服务端并未收到boss的应用请求，所以该现像与服务器端无关。

再来看在PIX前抓取的数据，如下图

服务端没有收到包boss系统的请求包，是不是由于包被丢弃了呢？从拓扑上看，数据经过的都是路由、交换设备，该包连防火墙都没到，而且该链路上的其它应用一切正常，如前所说，网络丢包没有说服力，继续看数据包，看能不能找到其它线索。

查看“概要”，发现网络中存在大量的FIN数据包，4452个数据包就有2498个包带FIN标记：

过滤FIN数据包，发现绝大部份FIN数据包都是由boss服务器发出来的：

再定位到

TCP

会话，通过时序图查看，查看会话中

FIN

包的情况

通过时序图可以看到在一个会话中存在多个FIN位置1的数据包，而且没收到对端的确认，这表示该会话没有正常关闭。

网络中存在大量的在一个会话中发送大量FIN+ACK置1且window为0的数据包的情况（我们知道，在数据传输过程窗口为0表示不能接受任何数据，至于关闭连接的window为0是否表示不能接收任何数据包有待验证，但可以肯定是不正常的），且这些会话都与10.238.230.50有关，这就表示在10.238.230.50上有很多未关闭的TCP会话，这是不正常的，需要进一步分析原因。先插入一些TCP连接建立和关闭的介绍（详细内容请参考《TCP/IP卷1》第18章）

（TCP正常建立和关闭对应的状态和状态变迁）

简单的说，在通讯过程中，客户端和服务端的TCP状态迁移如下： 客户端TCP状态迁移：

CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2-> TIME_WAIT->CLOSED

服务器TCP状态迁移：CLOSED->LISTEN->SYN

收到

->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED登录10.238.230.50后台，通过

netstat查看主机的会话状态：

如上图， 10.238.230.50上存在近5000个状态为colse_wait的连接，会话处于Colse_wait表示该连接还没有发FIN+ACK数据包。通常情况下， 一个colse_wait会维持至少2个小时的时间，这样，随着时间的增加就会导致不能释放的会话越来越多，直到系统没有资源处理新的连接请求。

三、结论及建议

1、分析结论

10.238.230.50上存在大量未释放的TCP连接，我们知道，TCP是有队列限制的，当队列已满时，TCP将不会处理传入的SYN，也不会发RST应答，因为通常队列已满是由应用程序和操作系统忙造成的（详见TCP/IP卷1第18章），这也能够解释为什么服务端没有收到boss的SYN包了，实际上这些数据包是boss系统收到的营业厅的SYN包，但由于boss系统队列已满或繁忙，则对其不做处理。10.238.230.50在与server关闭连接的过程中，window为0，可能是系统忙于处理colse_wait会话所致，从而导致boss与server的通讯异常。订单提交不成功的原因是boss系统队列已满或繁忙，没有资源对连接请求进行处理，问题出在boss系统。

2、建议

检查10.238.230.50与10.254.126.227

和10.238.159.90的应用通讯和应用程序（因为colse_wait的会话大都

科来官网 http://doc.guandang.net

数与这两个 IP有关，而 10.238.230.50与 server的连接状态是正常的);修改 tcp_keepalive_*的相关参数