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

网页打开慢但HTTP下载快故障分析案例

作者：易隐者 发布于：2012-10-10 16:06 Wednesday 分类：网络分析

【说在之前】：

1，用到了疑难杂症网络分析过程中最基本、最核心的两个分析方法：对比分析法和关联分析法；

2，该案例涉及到的知识点主要有SYN重传、连接数限制等，大家可参考本博客中相关知识点的文章。

【我的案例】：

故障环境

       某单位大体的网络结构如下图所示： 

点击查看原图


内部办公人员通过交换机到流控设备，再通过防火墙做NAT访问互联网。

故障现象

1，在地矿局进行互联网时，打开网页的速度非常的慢，有的网页要刷新几次才可以正常显示；
2，但是使用下载工具或是基于HTTP的下载速度却很快。

故障分析

1 确认故障原因

        我们找一台主机，访问互联网的某网站，发现的确比较慢，我们抓取故障时的交互数据包，如下图所示： 

点击查看原图

       通过上图，我们可以发现，客户端在与服务器建立TCP连接时，其SYN请求报文被客户端重传了一次，这个重传导致了2.88秒的延时。TCP重传一般是中间设备丢包导致的，那么到底是在什么地方丢包的呢？我们首先需要界定一下可能丢包的故障关键点。

2 选择故障关键点

       该故障环境相对简单，在办公用户访问互联网时，数据包只通过了交换机、流控设备和防火墙，而交换机主要负责转发数据，不会对数据包进行深度的检测和过滤等操作，所以在该环境下主要的关键故障点是流控设备和防火墙，如下图所示：

点击查看原图

 

3分析流控设备是否丢包

       关键故障点确定之后，我们首先在流控设备的前后同时抓包做对比分析，以确定是否是流控设备丢包，如下图所示： 

点击查看原图


       通过我们还原故障现象时，在流控设备前后抓取数据包的对比分析，结论显示，流控设备前后数据包交互的过程是一样的（这个对比分析通过五元组关联同一会话之后，对比查看数据交互过程的差异即可，由于流控设备前后的数据交互过程完全一样，在此不做具体详细的分析说明），这说明，在打开页面较慢时，流控设备并未丢弃任何交互的数据报文。

4 分析防火墙是否丢包

       同样，我们再在防火墙的进出口同时抓包，通过比较防火墙前后数据包的交互情况来确定造成故障的原因，部署图如下所示： 

点击查看原图


1， 在访问某网站出现缓慢现象时，在防火墙前后同时抓取数据包，并保存，为下面的对比分析提供原始的数据报文。
2，我们先分析防火墙内网口抓取的数据，在科来网络分析系统的“TCP会话”视图，我们发现了一个web连接持续的时间为6秒，并且其在三次握手过程中，存在重传现象，如下图所示： 

点击查看原图


这个TCP会话的源端口是1124，目的地址为58.30.236.11，目的端口是80
3，我们通过关联分析法，在进行网页访问时，我们在防火墙前后同时进行抓包，下图就是在防火墙出口处抓取到的数据包： 

点击查看原图

       我们知道防火墙在网络运行中起到防护作用，会将未经授权的报文过滤，但是防火墙一般不会阻止正常的数据包，我们在比较上面两张图发现，在防火墙后捕获到的数据包第一次发送同步请求没有成功，然后又重传了一次同步数据包，才成功建立了连接；而在防火墙前面抓取到的数据包却没有看到重传的数据包（黑框标记的部分），这很清晰的说明，第一个SYN报文被防火墙丢弃了。

4 分析结论

       通过上面的分析，我们可以得出如下结论：

       由于防火墙在转发数据包时，随机丢弃了客户端发送的SYN报文而造成的。可能是防火墙配置不当（连接数限制）或防火墙BUG（在处理TCP新建连接时不稳定）导致的。

总结

       经过分析知道是由于防火墙不规律丢弃SYN报文导致的网页打开慢现象，但是为什么HTTP下载的速度却很快？这是因为防火墙仅随机丢弃SYN报文，而HTTP下载在刚开始建立TCP连接时，防火墙有可能会丢弃其SYN报文，但是下载行为决定其会不断发起SYN报文进行连接建立的尝试，而一旦连接建立成功，则防火墙不会丢包，给用户的感觉就是速度也非常快。

阅读全文>>

标签: TCP 对比分析法 关联分析法 丢包 SYN 防火墙 重传 BUG NAT 连接数限制 SYN报文

评论(4) 引用(0) 浏览(13407)

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

作者：易隐者 发布于：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) 浏览(12839)

连接数相关知识

作者：易隐者 发布于：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) 浏览(15281)

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