欢迎关注: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) 浏览(14788)

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