【IT168 资讯】某运营商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 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_*的相关参数。