会话超时导致的故障

故障现象

最近，笔者在日常网络维护中，有用户反映业务软件在执行某操作时，经常出现“发送请求失败”的提示。按常规，首先在客户端使用Ping命令简单测试网络状况，通过长时间Ping测试，没有发现有丢包情况，而且时延也基本稳定在3ms左右，说明网络状况良好。但是，用户反映故障问题一直存在，影响日常工作。

故障排查

根据用户反映的故障现象，故障可能来源于业务软件本身或者网络问题。由于先前Ping测试没有发现网络异常，应该是业务软件本身的问题。在业务软件上执行其他操作，并没有发现异常问题。联系业务软件厂家，也证实软件方面不存在问题。经过仔细分析，用户执行操作后，业务软件会发出数据库操作请求，主要是大量数据插入操作。执行完毕后，返回结果到客户端。是数据库执行存在问题还是数据返回时有问题呢？为了找到问题所在，我通过远程操作，在服务器端的软件上执行相同操作，发现执行后，虽然执行返回结果的时间比其他操作的时间慢了点，但是数据都能正常返回，没有出现错误提示。通过以上测试，可以断定问题出在网络传输上。

在找准故障来源后，为了更深入查找网络问题，使用Wireshark抓包软件对网络数据流仔细分析。当用户执行操作后，首先通过TCP的三次握手建立连接，然后客户端发出数据库查询请求，服务器传来一个响应包，接下来，看到大量的超时重发请求。可以看出，由于执行超时太长，客户端没有收到返回数据，业务软件提示报错。远程到数据库服务器，发现数据库操作已经执行完毕，更加断定故障问题是由于超时传输导致的。

通过咨询软件厂家和网上查询，发现可以通过修改注册表来修改客户端的会话等待时间，具体操作是这样的。新建一个记事本文件，在里面编辑：

编辑好后，把文件名改成ReceiveTimeout.reg，并双击执行。注册表修改好后，继续操作业务软件，发现故障依旧存在，用抓包软件来看还是存在大量的超时重传请求。这让笔者感到很诧异，难道还有其他问题存在？

分析了当前的网络结构。客户端首先通过华为S2326接入，然后上联华为SRG1200网关设备。问题会不会出在SRG1200网关上？有可能当用户端发出请求后，由于远程数据库执行需要较长一段时间，数据返回时间较长，SRG1200会将数据丢弃，客户端没有能收到返回的数据，导致故障。为了验证想法，带上笔记本，模拟客户端的网络配置，直接接入SRG1200设备。发现问题依然存在，更加证实了原来的推想。

由于以前没有遇到这方面的故障问题，于是咨询了华为设备厂商。在描述故障现象和当前网络结构后，按照华为工程师的分析，这种故障可能由于SRG1200上面针对不同的网络传输协议都有相应的会话存活时间，当用户数据通过SRG1200时，会在该设备的会话表上添加用户的会话条目，如果会话存活时间到期，会话条目会被自动删除。结合当前故障，用户发出请求后，由于数据库操作执行需要较长一段时间，而当数据库执行完毕后返回数据时，原来用户的会话条目早已因为超时而被删除。此时，从服务器端返回的结果数据到达SRG1200时，因为没有发现对应的会话条目而被直接丢弃。这就是问题的所在。

故障解决

找到问题症结后，故障就可以迎刃而解。在SRG1200上，使用dis firewall session aging-time查询当前设备支持协议的会话时间，我们可以看到该设备支持57种不同协议的会话。Timeout时间以秒为单位。可以发现各种协议会话存活时间长短不一，比如ICMP协议的默认会话存活时间为20s，Telnet协议的默认会话存活时间为600s。

根据用户执行的操作，我们调整HTTP协议和TCP协议的会话时间应该就可以，根据实际数据库执行所需时间，我设置这两种协议的会话存活时间为1200s（即20分钟）。具体这样设置，在全局配置模式下，使用“firewall session aging-time service-set http 1200”，“firewall session aging-time service-set tcp 1200”。执行完后保存配置。

最后，在客户端测试，故障问题解决。

经验总结

通过这次故障问题，有了新的心得体会。有时候，网络故障问题其实隐藏得比较深，很难发现。比如，这次故障问题，如果只是使用简单的Ping命令来排查故障，是很难发现的。只有深入到网络传输底层，对传输数据进行抓包分析，才能及早发现故障症结。

另外，我们在设置会话存活时间方面，也不适宜将会话时间设置太长，因为会话表的总条目是有最大限制数的，如果某协议会话存活时间太长，在大量用户并发时，可能影响其他协议会话，造成设备系统资源紧张。