一次奇怪的网络故障

■ 浙江 盛建平

编者按： 笔者遇到某单位进行网络改造后，由于网络变动触发应用的隐性Bug，最后由开发部门与网络部门合作解决，该故障在日常非常罕见，因此进行了总结。

某单位外联网络为二层架构，外部用户访问内部通迅机，使用防火墙进行端口级保护。但二层架构安全性不高，内部通迅机直接暴露给外部用户，若通迅机被攻破，则可能直接进入内网，对该单位信息系统安全构成威胁。

为有效保障网络安全，该单位对外联网络进行改造，新增DMZ区，将通迅机前移到原防火墙外部的DMZ区，并在通迅机与外部用户之间新增其他厂商的防火墙实现异构。改造前后拓扑如图1所示。

故障现象

外联网络从二层架构切换到三层架构后，外部用户访问DMZ区通迅机办理业务，发现约有30%的交易不成功，有时重新办理又会成功，极大的影响了用户体验。回退到二层架构，业务又都正常。

图1 改造前后的拓扑图

故障分析

因通迅机虽改变了部署位置，但通迅程序未做任何变动，而本次又是新增了不同厂商的防火墙，因此排查重点定位在新增防火墙上。

检查外层防火墙配置，未发现异常。使用抓包工具对外层防火墙内、外口进行抓包分析，看是否存在异常的数据包。经分析，发现防火墙内、外口数据完全一致，并未发现丢包等异常现象。对业务出现异常时的数据包进行分析，发现数据收发均正常，见图2第610-613号数据包，客户端A.100.27发送了两个数据包（第 610和 612号），服务端B.231.2回复了两个ACK进行 确 认（第 611和613号）。但奇怪的是，服务端突然发送RST报文中断了TCP连接，如图2所示。

在网络人员进行故障分析的同时，应用开发人员对应用日志进行了分析。对通迅机上提取到的日志分析后发现，当某笔业务不成功时，服务程序仅接收到1460字节的数据，而非第610和612号数据包发送的1584字节（注：第610号数据包长度为1514，减去以太网头部14字节，IP头部20字节，TCP头部20字节，实际有效数据载荷为1460字节，同样第612号数据包有效数据载荷为124字节，两个数据包共发送1584字节）。开发人员认为，服务程序从网络上接收数据不完整，导致程序处理异常，应用连接中断，从而引起交易失败。

问题陷入僵局，从网络层面分析，客户端交易数据均已正确发往服务端，并收到服务端的确认；从应用日志分析，服务端数据接收不完整，从而引起交易中断。就像一起网络订单，前后共发两个快递，快递公司均已送达并经门卫签收（ACK报文），但最终用户从收发室（缓冲区）只收到第一个快递（1460字节）。最奇怪的是那个RST报文，明明数据完整送达了，服务方却中止了TCP连接。

重新回顾RST报文产生原因，主要有如下几种情况：

一是端口未打开。如A机向B机发送一个SYN请求，表示想连接B机的3000端口，但B机上并没有打开3000端口，于是向A机发送了一个RST。

二是请求超时。如A机的程序建立了Socket之后，用setsockopt的SO_RCVTIMEO选项设置了recv的超时时间为100ms，若此时A机发送SYN后到从B机接收到SYN的时间超过100ms，则A机上的程序认为接收超时，会发送RST拒绝进一步发送数据。

图2 服务端突然发送RST报文并中断了TCP连接

三是提前关闭。若客户端向服务端发送了2000字节，而服务端程序仅接收前1800字节就关闭了连接，此时TCP层发现“Close Socket时Recv Buff不为空”，TCP认为数据没有正确提交到应用，使用RST关闭连接。表现在抓包信息上就是客户机向服务器发送了2000个字节的数据，然后服务器端发送ACK进行确认，紧接着服务器向客户机发送了一个RST断开连接，该现象和本案的故障非常相像。

最后一种是在一个已关闭的Socket上收到数据。如客户端在服务端已经关闭掉Socket之后，仍然在发送数据，这时服务端会产生RST。

多种解决方案

根据RST报文产生的第三个原因，我们提出第一个解决方案，即服务端在收到1460字节后，对报文接收完整性进行校验，若未全部接收，则继续接收剩余的数据。据此开发人员修改程序后，业务回归正常。（该解决方案由胡瑛提出并实现，在此表示感谢）

根据网络订单二个快递的说法，我们猜想若最终用户稍等片刻再取快递，是否就能一次性取到完整的二个快递呢？据此开发人员修改程序，从缓冲区接收数据前，先等待2毫秒，之后业务也回归正常。

结语

本次故障是网络变动触发应用的隐性Bug，实属罕见。该问题的解决得益于网络与开发相互配合，通力合作。建议在使用Socket接口接收变长报文体时，采用尾标识法（通过寻找接收的通迅报文中的尾标识字符串，确认报文是否完整）或负载长度法（通过通迅报文头添加报文长度字段，确定有效报文的长度）等来提高报文接收的可靠性和完整性。