《某公司QQ掉线分析案例》之我见
作者：易隐者 发布于：2013-4-14 17:52 Sunday 分类：案例讨论
大致看了分析过程之后，觉得其中存在一些疑问，特地找时间针对这个案例做一个大致的分析，以便大家讨论参考。原本准备做相关交互图示的，由于个人时间问题，这次就免了，还望各位见谅。
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似乎使用的是TCP443端口进行交互的，但其实绝大部分情况下，QQ都是基于UDP协议进行交互的。因此在此案例中，按照我个人较为严谨的分析习惯，测试机的选择非常值得做进一步的商榷。
2），就算这个客户网络中所有使用的QQ都是基于TCP协议的，如果真是如腾讯所说，是由于QQ服务器发现用户IP出现了变化，才向客户端发送RST报文的，那么：
该RST报文ACK位是置一的，因此这个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同时掉线的现象。
5，在NAT POOL情况下，NAT设备会根据不同的算法（基于源IP的、基于连接的等）实现NAT POOL的地址复用，大部分算法应该都是基于源IP等计算的，如果是基于数据包、连接等进行计算，则很可能会导致各种问题的产生，我以前有一个非常经典的案例——《移动无线VPN客户端隧道建立故障分析》，下次我发布到我的博客，大家可去参考。
简单总结：
标签: TCP RST 五元组 重传机制 防火墙 BUG NAT QQ掉线
网页打开慢但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报文
某单位经过CA认证的业务应用访问缓慢故障分析案例
作者：易隐者 发布于：2012-9-3 9:47 Monday 分类：网络分析
【写在之前】：
1，此案例为业务应用系统客户端程序BUG问题导致的故障；
2，此案例可作为业务系统分析评估的应用场景，为业务系统正式上线前测试阶段通过网络分析技术手段发现业务系统稳定性问题的案例；
3，此案例中涉及到的知识点，请大家参考本博的《TCP重传》一文；
【我的案例】：
故障环境
故障网络结构如下图所示：
该单位的网络划分有办公区域和服务器区域，办公区域的机器经过防火墙的地址转换，访问服务器区域的相关服务器。
业务应用访问的流程
业务应用是基于B/S架构的，客户端通过IE浏览器对服务器进行访问；进行访问时，在IE浏览器中输入认证服务器的地址，经过CA认证服务器认证成功后，在通过CA认证服务器的代理，访问业务应用服务器。
故障现象
1，客户端在访问应用服务器时，有时页面打开的速度非常的慢，要等好几分钟才能完全打开页面，打开页面后进行站内访问时，速度也很慢；
2，直接将客户端接在服务器区，访问正常；
3，其他的业务应用全部正常；
4，业务系统开发商与网络集成商均否认是自己维护的系统导致故障了出现。
故障分析
1 分析思路
通过故障现象，我们可以明确这是单一的业务应用故障，问题应该跟该业务的数据交互有关，因此，我们应该将分析的重点放在该业务交互的详细过程。
另外，由于这个故障并不是一直出现，因此，我们需要在故障出现时，捕获其数据报文的详细交互过程，从而发现故障原因所在。
2 分析过程
1， 在测试主机上开启网络分析工具，并在故障现象出现时，捕获其交互的数据报文。
2，分析故障时数据报文详细的交互过程，如下图所示：
通过上图交互过程的分析，我们发现，第一个数据报文是客户端向服务器发送的SYN请求报文，第二个报文是服务器对客户端SYN报文的响应，其SYN标志和ACK标志位都置1了，下面5个报文都是第二个报文的重传。在这里我们没有看到正常的TCP三次握手建立连接的过程，客户端并没有响应来自服务器的SYN报文，服务器因此不断地重传SYN报文，正是这个原因导致了客户端与服务器业务交互异常缓慢。
3，由于该报文是在客户端直接捕获的，因此我们可以确定是客户端未响应服务器的SYN报文，而不是中间设备丢弃了客户端对服务器SYN报文的响应报文。那么为什么客户端不响应服务器的SYN报文呢？
4，将上述分析情况与业务系统开发商沟通之后，开发商才确认是自己的业务客户端出现了问题。
3 分析结论
通过上面的分析，可以得出该故障是由客户端本身不响应服务器的SYN报文导致的。
故障解决
通过我们的分析定位，找到故障的源头是客户端，通过与CA认证程序提供厂商沟通后，发现程序中有一段代码编写存在一些问题，当客户端与服务端的IP地址不在同一网段时，有时会出现客户端不响应服务器SYN报文的情况，在业务开发商优化客户端的程序代码后，该故障得到解决。
-
QQ邮箱订阅
-
搜索
日历
最新日志
链接
分类
最新碎语
- 如果一个人想要做一件真正忠于自己内心的事情，那么往往只能一个人独自去做"——理查德·耶茨
2019-06-25 21:34
- 日后我们知道，真正的人生道路是由内心决定的。不论我们的道路看上去如此曲折、如此荒谬地背离我们的愿望，它终归还是把我们引到我们看不见的目的地。（茨威格《昨日世界》）
2019-03-16 21:27
- 如果你渴望得到某样东西，你得让它自由，如果它回到你身边，它就是属于你的，如果它不会回来，你就从未拥有过它。——大仲马《基督山伯爵》
2018-10-09 22:07
- 人生有两大悲剧：一个是没有得到你心爱的东西；另一个是得到了你心爱的东西。人生有两大快乐：一个是没有得到你心爱的东西，于是可以寻求和创造；另一个是得到了你心爱的东西，于是可以去品味和体验。——弗洛伊德
2018-09-25 18:06
- 一个人越有思想，发现有个性的人就越多。普通人是看不出人与人之间的差别的——布莱兹·帕斯卡尔
2018-08-30 18:44
存档
- 2020年11月(2)
- 2018年1月(1)
- 2017年12月(1)
- 2017年11月(6)
- 2017年6月(1)
- 2017年5月(1)
- 2017年4月(1)
- 2017年3月(1)
- 2016年11月(1)
- 2016年4月(1)
- 2015年7月(2)
- 2015年6月(1)
- 2015年5月(5)
- 2014年12月(1)
- 2014年11月(1)
- 2014年10月(1)
- 2014年8月(1)
- 2014年7月(1)
- 2014年6月(1)
- 2014年5月(1)
- 2014年4月(3)
- 2014年2月(2)
- 2014年1月(2)
- 2013年12月(1)
- 2013年11月(1)
- 2013年10月(2)
- 2013年9月(1)
- 2013年8月(1)
- 2013年7月(3)
- 2013年6月(2)
- 2013年5月(1)
- 2013年4月(3)
- 2013年3月(1)
- 2013年2月(2)
- 2013年1月(2)
- 2012年12月(11)
- 2012年11月(12)
- 2012年10月(12)
- 2012年9月(26)
- 2012年8月(29)
- 2012年7月(18)
- 2012年6月(2)
- 2012年5月(25)
- 2012年4月(16)
- 2012年3月(13)
- 2012年2月(6)
标签
blogger
