欢迎关注:1,欢迎关注本博客,你可点击右手边的【QQ邮件订阅】订阅本博客!2,本博客推出江湖救急计划,主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析,如有需要,请在江湖救急计划页面给我留言!

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

作者:易隐者 发布于:2012-9-26 18:05 Wednesday 分类:网络分析

【说在之前】:

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地址的连接数的限制后,故障得到解决。

阅读全文>>

标签: 疑难故障 TCP icmp差错 SYN 连接数 NAT 地址转换 业务慢 连接数限制 ICMP主机管理性禁止差错报文 Type 3 Code 13 type 3 code 10

评论(2) 引用(0) 浏览(11296)

连接数相关知识

作者:易隐者 发布于:2012-9-19 19:58 Wednesday 分类:网络分析

       连接数是网络中非常重要的一个概念,在我们学习工作的过程中会经常遇到。下面将针对连接数相关的一些知识点做一些描述。

“连接数”是什么

       不同产品对“连接数”的理解有一些差别,但是主流认为网络中交互双方的五元组信息决定了一个连接。所谓五元组信息是指源地址、源端口、目的地址、目的端口以及协议类型。连接数就是网络连接的数目。基本上TCP/UDP应用根据五元组信息都可以很好的对应于一个连接,但是对于ICMP协议,不同的产品会有一些不同的处理,考虑到ICMP报文在实际工作环境下非常少,相对于TCP、UDP应用的连接数基本上可以忽略,因此不针对此做深入的描述。

并发连接数

       并发连接数是指同时在连接表中的连接数目。端系统和中间系统在处理这些连接时都会设置一个连接超时时间,在超时时间溢出之前,系统会为这些连接分配相应的存储资源。而我们熟知的Syn flood DOS攻击正是利用这个特性来达到攻击效果的。一般而言,并发连接数是衡量一个中间系统性能的指标之一。

每秒新建连接数

       每秒新建连接数是一般是指中间设备在单位时间内(1秒内)所能建立连接的数量,这个参数的大小直接影响中间系统在单位时间内所能建立的最大连接数量,其也是衡量中间系统性能的一个重要指标。

 连接数限制

       连接数限制主要是指端系统或中间系统基于安全(防攻击)、管理(流量控制)等方面的需要而对某些IP的网络连接数量限制在某一范围内的策略。如windows系统中的连接数限制,防火墙路由器等中间系统上的“连接数限制”功能等。
       端系统中的主机防火墙(如linux下的iptables)、操作系统本身、应用程序(Apche、IIS、数据库等)等都可能针对连接数进行限制,而现在常见的中间设备(防火墙、路由器等)基本上都支持连接数限制的功能,大家可以根据实际环境中的设备自行查阅相关手册的连接数有关功能的设置。
       我们随便找个路由器上连接数限制功能设置的截图看看: 

点击查看原图

        我们再来看看IIS连接数限制功能设置的截图:

点击查看原图


连接数限制对网络的影响

       连接数限制策略实施之后,当被限制连接数的IP超出限制的范围,其后续的网络连接将会被端系统或中间系统过滤丢弃,这将导致这些IP在进行网络交互时速度变慢、丢包等情况发生。因此,连接数限制是管理策略性导致网络交互异常的原因之一。
       另外值得注意的是,在实际环境下,虽然端系统或中间系统可能会由于连接数限制功能丢弃部分报文,但是并不是所有设备在丢弃这些报文之后会向源主机发送ICMP差错通告报文,这给我们分析定位带来了一些难度。

阅读全文>>

标签: TCP 五元组 ICMP 连接数 连接数限制 并发连接数 每秒新建连接数

评论(0) 引用(0) 浏览(13707)

Powered by 易隐者 基于emlog 皖ICP备12002343号-1