某业务系统由于连接数限制导致间歇性访问慢故障分析案例

最新推荐文章于 2023-08-15 09:53:42 发布

ixidof

最新推荐文章于 2023-08-15 09:53:42 发布

阅读量2k

点赞数

分类专栏：网络协议文章标签：服务器 tcp 防火墙通讯 web服务工作

网络协议专栏收录该内容

12 篇文章

订阅专栏

本文详细分析了一个由服务器连接数限制引发的应用间歇性缓慢故障案例，从网络拓扑、故障现象、分析过程到最终解决方法，全面展示了如何通过数据包捕获和故障定位技巧，深入理解并解决此类问题。故障表现为部分内部办公主机在访问特定业务系统时出现打开主页慢、登录慢或页面不显示的情况，间歇性出现且多次刷新后可恢复正常。通过分析发现，服务器对特定源端口的TCP连接请求进行了管理性禁止，导致连接建立尝试时间延长，引起访问缓慢。文章最终通过修改服务器设置解决了这一问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

文章出处：http://www.vants.org/?post=125

【说在之前】：

1，该案例为端系统设置连接数限制导致的应用间歇性缓慢故障，在实际工作环境下，我们更容易遇到的是中间系统对连接数限制导致的一些访问异常，令人头疼的是，并不是所有开启连接数限制功能的中间系统在丢包后都会向源主机发送ICMP差错报文，这会给大家分析定位带来难度，大家在实际工作中需要留意；

2，该案例涉及到的知识点主要为“ICMP主机管理性禁止差错报文”和“连接数限制”，关于ICMP主机管理性禁止差错报文，大家可参考本博客《ICMP通讯管理性过滤禁止差错报文（type 3，code 13）》一文，虽然“type 3，code 10”与“type3，code 13”有些差异，但是差别不大，可以借鉴；关于连接数相关知识点，大家可参考本博客《连接数相关知识》一文；

【我的案例】：

1 故障环境

网络拓扑：

说明：
1，内部办公机器都是192.168.1.0/24段的，内部办公主机通过防火墙做NAT，转换为X.X.X.138访问互联网；
2，内部办公服务器的地址为192.168.1.191，其通过防火墙映射为公网地址X.X.X.139对外提供6888端口的web服务。
业务访问流程：
内部办公机器都是通过NAT后的公网地址X.X.X.138访问办公服务器的公网地址X.X.X.139。其流程如下图所示：

2 故障现象

故障现象主要表现为：
1，部分内网办公主机经常出现打开主页慢、登录慢或者某些页面不显示的情况，如下图所示：

打开主页时的长时间等待页面截图

登录时长时间等待页面截图

2，这些故障现象间歇性出现，有时多刷新几次页面后，打开的速度会恢复正常。
3，外网用户访问业务系统一直正常，该故障已经持续数月。

3 故障分析

通过故障现象，我们可以看出，这是比较典型的部分系统出现问题的案例，由于其不具备全体的故障特征，又是间歇性的发生，因此，此类故障按照常规的分析方法很难找到真正的故障原因，我们还是先在客户端抓取一下故障时交互的数据包，站在数据包的角度来分析一下可能的原因。

1，找一台出现故障的主机192.168.1.167，捕获其打开主页面缓慢时的数据包。

2，查看缓慢时的数据交互情况，如下图所示：

我们通过delta tima值可以看到，这个交互的过程存在较大的延时，并且我们发现，在交互的过程中存在数个“ICMP主机通讯管理性禁止”的差错报文，这些报文都是X.X.X.139发给故障主机192.168.1.167的。

3，我们双击其中一个ICMP主机通讯管理性禁止报文，查看其封装的被过滤的原报文相关信息，如下图所示：

我们发现，被X.X.X.139管理性过滤掉的报文是192.168.1.167以源端口4075发往X.X.X.139的6888端口的TCP SYN请求报文。

4，我们再结合上下数据包交互的情况，我们可以发现，这个ICMP主机通讯管理性禁止报文的前一个报文正是192.168.1.167以源端口4075发往X.X.X.139的6888端口的TCP SYN请求报文，如下图所示：

这充分说明当故障主机192.168.1.167的4075端口向服务器的6888端口尝试TCP连接请求时，被服务器管理性过滤禁止了。

5，那么服务器为什么会管理性禁止故障主机192.168.1.167的4075端口向服务器的6888端口尝试TCP连接请求报文呢？难道服务器上设有针对源端口为4075的禁止访问策略吗？服务器显然没有做这种针对源端口过滤的必要，另外，我们还发现除了故障主机以源端口4075访问服务器的SYN报文被管理性禁止外，还有其他源端口的SYN请求报文被服务器管理性禁止，如下图所示：

这里被服务器禁止的报文的源端口有4078、4083、4086等。
另外，通过上图中的“delta time”值，我们也可以发现正是这些报文导致了故障主机在建立新的TCP连接之前花费了数秒的连接建立尝试时间（SYN重传时间，大家可参考本博客《TCP重传》一文），从而导致了页面打开缓慢的现象出现。

6，这个现象具有明显的针对TCP的随机性的过滤特性，因此，我们很容易就可以联想到是否是服务器在TCP传输层存在某些检测过滤机制？而在传输层最为常见的就是TCP连接数限制了。
一般而言，在服务器上实现针对单IP访问服务器的TCP连接数进行限制是一件简单的事情，一个独立的IP只允许与服务器建立少量的TCP连接，这对于那些对外提供服务的服务器来说是一种较为常见的防护措施，在正常情况下，单个客户端与服务器的正常交互所需要的TCP连接数并不是很多，而限制的数值一般都会高于正常的需求，但是在有些情况（如经过NAT或代理后对业务的访问）下，这将导致问题的产生。

7，上述推理非常合理，我们通过检查服务器的相关设置，验证了我们的分析和推论结果。

8，分析结论：
这个故障是由于业务服务器端设置了针对单IP访问连接数限制功能，而内部办公网主机都是通过防火墙NAT地址转换后对业务服务器进行访问，这直接导致在业务访问高峰时，出口NAT IP地址访问业务服务器的连接数超出限制，业务服务器对后续的TCP连接建立请求发出ICMP差错报文，等一些TCP连接释放后，才允许新建TCP连接，这导致访问业务系统非常缓慢。并且这种特性决定了故障现象表现为间歇性发生。

4 故障解决

通过修改服务器Apach对单一IP地址的连接数的限制后，故障得到解决。