利用科来网络分析技术诊断BOSS系统故障

ZDNet至顶网软件频道消息： 某运营商Boss系统向服务器提交订单，每天会有600个左右不成功的订单，不成功的订单需手工录入，极大的影响工作效率；该情况已持续2-3个月；持续ping服务器和boss，未出现任何的丢包现象；应用部门和应用厂商检查应用程序和规则说一切正常；网管人员检查网络设备的性能，设置（MTU、MSS等）一切正常；管理人员在boss系统上抓取的同步数据包大于在PIX之前抓取的数据包，怀疑有丢包，但其它应用和ping都正常，网络丢包没有说服力。

网络拓扑

图 1 网络拓扑图

案例分析

订单提交不成功有两种情况，一是服务端未收到boss的请求，二是服务端收到请求后未响应，由于用户反映在boss和pix上抓包不一致，遂选择在boss和pix上进行抓包（将便携式和回溯系统的时间同步）。

分别提取回溯系统和便携式上的数据包，进行对比分析。

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

如图2：

图 2 boss端TCP会话

再来看在PIX前抓取的数据：

图 3 pix端TCP会话

服务端没有收到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状态迁移：

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个小时的时间，这样，随着时间的增加就会导致不能释放的会话越来越多，直到系统没有资源处理新的连接请求。

分析结论

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系统。

分析建议

检查10.238.230.50与10.254.126.227和10.238.159.90的应用通讯和应用程序（因为colse_wait的会话大部分与这两个IP有关，而10.238.230.50 与server的连接状态是正常的）。

修改tcp_keepalive_*的相关参数。