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

《某公司QQ掉线分析案例》之我见

作者:易隐者 发布于:2013-4-14 17:52 Sunday 分类:案例讨论

       前段时间看到CSNA论坛上有一篇QQ掉线故障分析的案例,原文是PDF格式的,我就不转载其全文了,其链接如下 : http://www.csna.cn/network-analyst-50520-1-1.html,大家可自行通过上述链接下载查看。

       大致看了分析过程之后,觉得其中存在一些疑问,特地找时间针对这个案例做一个大致的分析,以便大家讨论参考。原本准备做相关交互图示的,由于个人时间问题,这次就免了,还望各位见谅。

1, QQ多人同时掉线,大约1秒就自动连上,浏览网页和其他应用没有问题  

       QQ属于一种终端的应用,一般情况下,局域网内某应用出现同时掉线、缓慢等问题,基本上可以排除是单个终端的问题,因为从这个现象上来看,这是一个全局问题,可能是业务应用本身、业务服务器或者承载业务的网络系统出现了问题。在此故障分析案例中,作者提到QQ同时掉线但是浏览网页和其他应用没有问题。通过这个故障现象的描述,我个人首先可能会想到整个互联网出口是否会出现网络瞬间中断的情况?这是我个人的猜想,因为如果真是互联网出口出现网络瞬间中断,那么HTTP等基于TCP的应用由于TCP的重传机制,在出口网络中断1秒左右的时间内,终端使用者不会有明显的异常感受,而基于UDP等应用,可能会出现掉线等现象,在网络出口恢复正常之后,QQ再次自动上线。这个猜想的原因至少可以很好的解释该案例作者一开始描述的故障现象。

2, QQ掉线是QQ服务器主动RST连接导致的,腾讯给出的解释是由于用户端IP地址出现了变化。

1),QQ大部分情况下应该是使用UDP协议的,少数情况下使用TCP协议。

       QQ是一个较为复杂的应用,其为了满足使用者在各种复杂的环境对QQ的正常使用,其会存在多种模式和网络交互行为,大部分情况下,QQ默认会使用UDP协议进行交互,少数情况下会使用TCP甚至TCP的80端口、443端口进行交互,特殊情况下,根据需要和设置,其还可以通过代理的方式进行交互。

       正是QQ这种特殊应用工作机制的多样性和复杂性,导致我们在遇到其故障时,给我们的分析定位带来了难度。在该案例中,由于QQ是大规模的出现掉线现象,我们在分析处理时,其实根本搞不清楚不同使用者的QQ到底是工作在何种模式之下,其网络行为特征千差万别,因此,我们很难通过某一台测试机来全面分析验证QQ故障的原因。

       在该案例中,测试机的QQ似乎使用的是TCP443端口进行交互的,但其实绝大部分情况下,QQ都是基于UDP协议进行交互的。因此在此案例中,按照我个人较为严谨的分析习惯,测试机的选择非常值得做进一步的商榷。

2),就算这个客户网络中所有使用的QQ都是基于TCP协议的,如果真是如腾讯所说,是由于QQ服务器发现用户IP出现了变化,才向客户端发送RST报文的,那么:

       其一,不同的QQ客户端与QQ服务器是单独建立连接的,暂且不论QQ服务器的多样性(不同的QQ客户端很可能会与网络中的N个不同的QQ服务器之间建立交互链接),不同的QQ客户端与QQ服务器之间建立不同的交互连接,那么即使防火墙在做NAT时出现BUG,突然改变了某些已有连接的源IP地址,也应该绝少出现同时改变N个不同QQ客户端与服务器之间已有连接的源IP,换句话说,如果原因真是如该案例作者所说,很难解释QQ同时掉线的现象。
       其二,那么我们站在QQ服务器的角度来分析一下此种情况真的发生时,QQ服务器会作何处理?QQ服务器收到源IP地址变化的QQ客户端报文后,QQ服务器会把他作为一个新的TCP连接来处理(因为五元组不一样),而QQ服务器并没有这个TCP连接信息,因此服务器会直接RST该报文,而这种RST报文,其ACK位肯定不会置一的,但是我们看到这个案例中作者的截图如下:
 点击查看原图

该RST报文ACK位是置一的,因此这个RST报文并不是如作者想象的情况下产生的。

       其三,我们再来看另外一张截图:

点击查看原图
        看此交互截图,QQ服务器已经对客户端的报文作出了确认(序号2230的包),紧接着(0.000045秒后),QQ服务器向客户端发送RST报文(序号 2232的包),这个报文可以肯定在服务器紧接着发出序号2230的包之后发出的,如果按照作者的说法,RST报文至少应该是序号为2231的客户端报文经防火墙源地址转换之后(源IP变化),到达QQ服务器,QQ服务器发现源地址变化,再向客户端发送RST报文,这样整个过程方才合理,但是上面这张截图已经充分说明:事实并非如此。

3,如果真的是防火墙的NAT出现了这种低级的错误和BUG,那么对用户影响最大的应该是HTTP等基于TCP应用。因为很多HTTP应用的动态口令、验证码等都需要通过数个不同的TCP连接与服务器进行交互,一旦出现该案例作者所说的防火墙处理BUG,将导致这些应用出现访问故障。而不会仅仅是无关紧要的QQ应用出现问题。

4,QQ掉线而其他TCP应用正常,很可能是防火墙的UDP会话保持时间过短导致的。

       因为很多人挂QQ并不一直与好友聊天。而一般情况下,防火墙等为节约设备资源,会将UDP的会话超时时间设置为一个较短的数值,如60秒,那么如果用户在这个超时时间内无任何数据交互的话,防火墙会将这个UDP会话从防火墙连接表中删除,当QQ客户端再次尝试与QQ服务器交互时,其发送的QQ状态更新报文就会被防火墙丢弃,导致QQ客户端掉线。QQ掉线后,客户端会再次发起新的连接,此时防火墙将其作为一个新建的UDP连接进行处理,QQ因此再次成功上线。当然这个很难解释QQ同时掉线的现象。

       另外一种情况是,如果防火墙的UDP连接表出现异常,防火墙突然清空其UDP连接表,也可能会导致该案例中故障现象的产生。

5,在NAT POOL情况下,NAT设备会根据不同的算法(基于源IP的、基于连接的等)实现NAT POOL的地址复用,大部分算法应该都是基于源IP等计算的,如果是基于数据包、连接等进行计算,则很可能会导致各种问题的产生,我以前有一个非常经典的案例——《移动无线VPN客户端隧道建立故障分析》,下次我发布到我的博客,大家可去参考。 

简单总结:

       防火墙在NATPOOL情况下,变化地址是正常的,关键看防火墙的NAT算法。QQ掉线应该跟这个无关,案例中分析来自于QQ服务器的RST报文跟NAT后源地址变化无关。

阅读全文>>

标签: TCP RST 五元组 重传机制 防火墙 BUG NAT QQ掉线

评论(3) 引用(0) 浏览(12232)

由TCP保活引起的业务访问故障案例

作者:易隐者 发布于:2012-12-7 15:18 Friday 分类:网络分析

1 故障环境

1.1  故障拓扑

       故障发生的网络拓扑结构如下图所示: 

点击查看原图

1.2  业务报文交互路径

1,客户端通过网闸映射地址218.X.X.151访问内部业务服务器10.X.X.209;
2,客户端经过网闸后,源地址变为网闸内口地址10.X.X.160访问真实的业务服务器。

2  故障现象

       故障现象主要表现为:
 客户端访问业务服务器出现中断现象,并且故障基本都发生是在夜间12点以后;
 第二天重启网闸后,业务访问恢复正常,但是到夜间12点左右业务连接会再次中断;
 在业务访问出现中断以后,偶尔会不定时的可以成功进行连接,但是持续时间不长就再次中断;
 仅此业务应用存在这个异常,其他的业务基本正常。

3 故障分析

3.1 分析思路

       考虑到故障都发生在夜间12点左右,因此在网闸内外网口同时部署网络分析产品,对内外网口交互的报文进行长时间的捕获存储,第二天,我们分别选取故障发生时间内的报文进行关联分析和对比分析。

3.2 分析过程

3.2.1 异常出现时,网闸外口的报文交互情况
       我们选取故障发生时,网闸外网口的交互报文进行查看,我们在“TCP会话”视图中,发现了大量交互报文少、流量小、收发报文特征明显的TCP会话,如下图所示: 

点击查看原图

       我们选取其中任意一个TCP会话,查看其详细的报文交互情况,如下图所示: 

点击查看原图

       我们可以清楚地看到,客户端与服务器映射的外网地址通过三次握手建立TCP连接之后,服务器映射地址立即向客户端发送了FIN报文,主动释放TCP连接,后续的带有应用字段的客户端报文到达后,服务器直接向客户端回应RST报文。
       我们查看了其他的TCP会话的详细报文交互情况,基本与上述情况一样。由此来看,似乎是网闸主动发送FIN报文导致了业务应用出现异常,网闸为什么会在已经建立三次握手之后立即主动发送FIN报文呢?难道是服务器主动发送的FIN报文?或者是网闸的BUG导致网闸主动发送FIN报文?我们需要在内网端做个关联对比分析才能确定。

3.2.2 在网闸内口发现保活报文
       当我们取故障时内网的报文时,发现内网在做捕包存储时出现异常,抓包工具在故障出现之前崩溃了,并未将故障发生时的网闸内口报文捕获保存下来,而由于时间紧急,我们没有机会再花费一天的时间去捕获内网的报文,这些故障现场的不确定性现象发生了,我们只能抓取当下的网闸内口报文进行辅助分析。
       我们在网闸内网口抓包发现大量的特征明显的TCP会话,如下图所示:

点击查看原图

       这些TCP会话仅有几个报文的交互,不像正常的业务数据交互报文,我们选择其中一个TCP会话查看其具体的交互报文,如下图所示: 

点击查看原图

       这是服务器发给客户端的报文,下面是客户端给服务器的报文: 

点击查看原图

       结合这两个报文,我们可以肯定,这是一个TCP保活报文。这些仅交互2个报文的TCP会话是服务器发给客户端的TCP保活行为!

3.2.3合理推测
       这些数量众多的保活行为的TCP会话,引起了我们的关注,那么是否是保活行为导致业务应用出现问题呢?保活的功能之一是维持已有TCP连接,关于TCP保活的详尽描述大家可参考我博客的文章《TCP保活(TCP keepalive)》。
       TCP保活的这个特性很自然的让我们想到可能是TCP保活功能引起网闸连接表满从而导致业务异常。但是网闸作为一个网关类设备一般都支持几十万甚至数百万的连接数,在无异常攻击报文的情况下不至于24小时连接表就全部满了,并且也只有这个业务应用出现异常,其他应用都是正常的。
       我们发现外网的客户端访问到内网时,其源地址全部转换为网闸内口地址10.X.X.160,至此我们恍然大悟:源IP、源端口、目的IP、目的端口、协议类型等五元组信息决定一个连接,而在网闸内口,源IP、目的IP、目的端口、协议类型都已经确定,只有源端口是变换的,而端口范围只能在0-65535之间,还要去除一些常用的端口,如此一来,网闸内口跟服务器之间能够建立的TCP连接数只能在65535以内!
       在这种情况下,客户端访问业务服务器的TCP连接在24小时内达到近65535个,从而导致后续的客户端与业务服务器无法正常建立连接,引起业务访问故障。
       至于故障后又能偶尔连接正常但很快再次异常的原因也很好解释,那就是网闸内口在维护如此众多的连接时,总会由于各种原因导致几个连接异常释放,如此一来则紧接着的业务访问连接会正常建立,但是一旦用完为数不多的几个连接后,后续的业务连接将再次出现异常。
       整个交互过程涉及到的客户端、网闸外口、网闸内口、服务器的状态变化如下图所示: 

点击查看原图

3.2.4验证
       我们建议用户在下班后手动清空网闸内口已有连接,观察夜间12点故障是否出现来验证我们的推测。后经用户反馈,在清空连接后夜间12点左右故障未再现,如此充分证明我们上述的推测是正确的。

3.3 分析结论

       服务器端设置了TCP保活功能,对所有的TCP连接主动实行TCP保活探测,这导致网闸内口与服务器建立的TCP连接无法得到释放,在24小时以内,TCP连接数接近65535个,而此时客户端再次发起与服务器之间的业务连接之后,网闸内口已经无法再与服务器新建TCP连接,如此导致业务连接无法建立。

4 故障解决

       在找到导致此业务故障的真正原因之后,我们就可以对症下药,通过任意选择如下几种方式之一来彻底解决这个故障:
1, 可以在服务器上关闭TCP保活功能;
2, 在网闸内口关闭源地址转换(SNAT)功能;
3, 将网闸内口TCP连接释放时间调整至小于服务器发送TCP保活的间隔时间,这样可以在服务器发送保活报文之前,让网闸内口提前释放该连接;
4, 网闸内口使用TCP连接复用功能,让大部分的外网客户端访问连接仅通过少量的内部连接实现正常的业务交互,而服务器则可以与网闸内口之间少量连接保持保活。

阅读全文>>

标签: 疑难故障 五元组 连接表 TCP保活 TCP keepalive 连接复用 网闸 SNAT

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

连接数相关知识

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

疑难网络故障的分析方法和原理之关联分析法

作者:易隐者 发布于:2012-7-4 12:51 Wednesday 分类:网络分析

      前面我们在讲解对比分析法时,大家可能会有这样的疑问:对比分析法主要是通过对进出中间设备的数据包做对比分析,从而得出相关结论的,但是,我们都知道,很多中间设备会对经过它的数据包做一些修改和处理,那么我们怎么能够将进入设备前的数据包与被中间设备修改后转发出来的数据包对应起来呢?接下来这一节就是专门讲解我们如何将这些数据包关联起来的方法―—关联分析法。

关联分析法
       数据包在经过各种中间设备时,经常会出现被中间设备(例如存储转发设备、NAT设备、负载均衡设备等)更改的情况,这对于我们分析问题非常不利,我们在做对比分析时,必须要将相应的数据流、数据包关联对应起来,否则就失去了可比性。

阅读全文>>

标签: IP标识 关联分析法 五元组 应用字段

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

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