蚂蚁网-多维人生，三实而立！

某单位经过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报文的情况，在业务开发商优化客户端的程序代码后，该故障得到解决。

阅读全文>>

标签: 疑难故障 TCP TCP重传 SYN 重传 SYN重传 CA BUG

评论(5) 引用(0) 浏览(11494)

FTP登陆故障分析

作者：易隐者 发布于：2012-9-1 17:47 Saturday 分类：网络分析

【说在之前】：

1，此案例涉及到的分析方法，请大家参考本博客文章《疑难网络故障的分析方法和原理之对比分析法》；

2，此案例涉及到的知识点，请大家参考本博客的文章《应用层检测/深度包检测（DPI）》；

3，此案例中谈到的利用防火墙自带的抓包功能tcpdump的使用，请大家参考本博文章《天融信防火墙自带的tcpdump使用》一文，我曾将各种常见系统和网关设备自带的抓包功能的使用整理成《常见系统和网关设备自带抓包功能介绍及操作指南》一文，其他网关型设备自带的抓包功能的使用我会陆续择机发布到本博；

4，设备本身的BUG问题一般都属于疑难杂症级别，在做分析定位时，站在原始数据报文交互的角度抓包分析是比较靠谱的做法；

5，本故障还有另外一种解决的方法，给大家一点提示：ICMP重定向报文，感兴趣的兄弟自行思考，如需协助，可给我留言。

【我的案例】：

故障描述

1 故障拓扑 

2 环境说明：

1、客户端的默认网关是主路由器；
2、主路由上设置了相应的策略，凡是FTP/HTTP的应用均交由备路由处理；
3、备路由上会将访问国家局的网段指向国家局路由；
4、核心与路由间均部署防火墙，防火墙工作在透明模式下；
5、客户端访问服务器的数据流走向比较复杂。

故障现象

1、省局到国家局的FTP服务很慢，一般需要40多秒才可以登陆上去，有时根本登陆不上去；
2、在故障机器上Ping国家局服务器，延时很小；
3、省局到国家局的HTTP应用正常。

故障分析

1 前期简单分析

1、Ping延时很小，说明网络层的延时很正常；
2、网络环境复杂，数据流走向复杂，数据包来回路径不一致，中间经过2台防火墙，可能存在状态检测的问题；
3、HTTP的数据流走向跟FTP的数据流走向应该是一样的，HTTP正常，FTP不正常，说明这个跟TCP的状态检测无关，应该是FTP应用层的问题。
       暂时没什么头绪，只能先从客户端下手，进行抓包分析，看看大体的情况。

2 数据包分析

 登陆不上时的数据包分析
       我们在客户端登录不上FTP服务器时，抓取其跟服务器交互的数据包，查看客户端与服务器的详细交互过程，如下图所示：

        通过上图中针对每个交互数据包的详细分析和描述，我们基本上可以知道，在客户端登录不上FTP服务器时，是由于客户端与服务器交互用户名和密码时产生了问题，导致FTP登录时间过长，超出最大会话时间，从而被FTP服务器主动关闭。

 FTP登陆慢时的数据包分析

       我们在客户端登录FTP服务器非常想缓慢时，抓取其跟服务器交互的数据包，查看客户端与服务器的详细交互过程，并针对每个交互的数据包做详细的说明和描述，如下图所示： 

通过上图详细的分析，我们可以知道，产生较大延时的原因也是在用户名、密码交互的过程。
我们把上述两种场景下，客户端与服务器间用户名和密码交互的过程做一个示意图展现如下： 

       通过这个示意图，我们可以更加清楚的发现，之所以在客户端与服务器端交互用户名和密码时产生了很大的延时，是由于用户名和密码数据包在交互的过程中被中间设备丢弃导致的。
      那么到底是哪个中间设备丢弃了FTP用户名和密码的数据包呢？接下来我们就要找出丢弃用户名和密码数据包的中间设备。

 定位丢包的中间设备

       在这个过程中，主要针对我们可以控制操作的中间设备进行排查，首先我们选择可能丢包的关键点。在这个网络环境下，我们首先考虑的就是2台防火墙设备。
       我们利用防火墙设备自带的tcpdump抓包功能，专门抓取FTP客户端与服务器交互的数据包（该抓包过程由于现场原因未作记录，在此无法做详细数据包展示），分析其过程，我们可以发现的确是防火墙丢弃了FTP用户名和密码数据包。
       那么防火墙为什么会丢弃FTP用户名和密码的数据包呢？
       抓包分析我们可以发现被丢弃的包都是FTP传输用户名和密码的包，这个肯定属于FTP应用层的包，防火墙丢弃FTP应用层的数据包，那么问题应该就出在防火墙的FTP应用层检测上。我们登陆上防火墙，查看防火墙针对FTP应用做了哪些应用检测的策略，结果我们发现，其针对FTP应用启用了应用层检测，如下图所示： 

        至此，我们基本上可以断定是防火墙的FTP应用层检测BUG导致了这个故障的产生。

故障解决

       在防火墙上取消FTP应用绑定，让防火墙不要对FTP的数据包进行深度的过滤和检测，再次登陆FTP服务器，一切正常，至此该疑难故障解决。

阅读全文>>

标签: 疑难故障 tcpdump 应用层检测 报文深度检测 DPI FTP ICMP重定向

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

TCP 的PUSH标志位

作者：易隐者 发布于：2012-8-31 15:32 Friday 分类：网络分析

       发送方使用该标志通知接收方将所收到的数据全部提交给接收进程。这里的数据包括接收方已经接收放在接收缓存的数据和刚刚收到的PUSH位置一的TCP报文中封装的应用数据。
还是看一个简单明了的图示吧：

关于PUSH位的一些讨论和分析

       Long_323（龙的传人）兄弟曾跟我讨论：在无法解码应用层报文时，能否根据TCP  PUSH位来分析应用响应时间？

       我的回答是：不可以，我个人不会这么做，因为不够科学。

       所谓应用响应时间，是指客户端有发出请求，服务器端会针对该请求作出相应的响应，我们才可以分析计算其响应时间。如果我们无法解码应用层，那么我们就无法确定其到底是不是一个请求报文，如果不是请求报文（例如，我的《TCP交互交互式应用》一文中提到的互动游戏的报文、TCP keepalive保活的报文等）但是其TCP PUSH位是置一的，那么我们怎么能根据这一点就计算出应用的响应时间呢？

       也许有经常关注我的兄弟会问：你说不可以，那怎么在你写的文章《关于“client push”应用响应时间测量方法的讨论》中，建议说“从客户端带有PUSH标志位的数据包开始计算，至服务器端响应应用层数据停止计算”呢？如果真有这么问的兄弟，我会非常欣慰，因为能问出这个问题的人，说明他有认真仔细的研读过我的文章，那么他肯定会从中获得一些帮助和成长，我会为此而心生满足。言归正传，在我的《关于“client push”应用响应时间测量方法的讨论》一文里，全文的基础和基调都已经定在为“client push”的应用场景了，看标题你就会明白，不需要我多说了吧。

       言已至此，我想大家也会明白，我说的不可以并不是绝对不可以，而只是站在我个人的角度而说的，仅代表我的个人主观选择。

       在有些情况下，可以作为一个参考分析思路。那么到底在哪些情况下能这么做呢？我个人认为主要有以下几点：
1， 可以明确我们要分析的应用类型为请求-响应类的应用
2， 虽不能解码，但是我们在做分析时，需要将具体的请求操作和数据报文结合起来分析，以提高分析的科学性和准确性
3， 对分析的结果要求不是非常高、非常严谨的

       还有兄弟认为如果所有带有应用字段的TCP报文PUSH位都置一的话，会对服务器造成较为严重的性能影响。这个所谓的影响如果真的存在的话，我想应该是在服务器的内存、CPU等资源严重不足或应用程序本身处理存在严重性能问题时才会出现，是因为本来就有问题了，导致PUSH位都置一的报文加重了这种影响，而不是因为PUSH位置一的报文导致了服务器的性能问题的出现。

关于PUSH位的应用

        PUSH位就是用来通告接收方立即将收到的报文连同TCP接收缓存里的数据递交应用进程处理。一般会出现在发送方封装最后一个应用字段的TCP报文中，针对TCP交互式应用，则只要封装有应用字段的TCP报文，均会将PUSH位置一，当然，应用程序的开发者，可以根据需要，在某个应用功能模块或某个应用操作时，将所有封装应用字段的TCP报文PUSH位置一，以提高交互双方的处理效率，这在理论上应该也是可行的。

  

阅读全文>>

标签: TCP 应用字段 响应时间 应用响应时间 ART 保活 push 交互式应用 client push 接收缓存 keepalive

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

TCP交互式应用

作者：易隐者 发布于：2012-8-30 21:29 Thursday 分类：网络分析

       TCP交互式应用由于其交互的特性，一般对时延的要求较高，因此一旦有应用数据时便立即向对端发送并要求对端能够及时处理，其交互的报文基本上都是小包（小于MSS），常见的TCP交互式应用主要有telnet、rlogin、互动游戏等，我们先来看一个TCP交互应用的报文分析：

其具有以下三个明显特点:

1，客户端与服务器端的数据传输是交互式进行的；

2，应用字段长度均较小；

3，带有应用字段的TCP报文PUSH位均置一。

TCP交互式应用的场景（以游戏为例）：

       对于实时网络游戏这种交互应用，如果TCP接收方不立即将应用数据提交应用程序处理的话，很可能会导致游戏应用出现卡、客户端与服务器端不同步等故障，严重影响游戏应用的正常运行。你想啊，你在玩CS，扮演警察，突然一个悍匪跟你正面冲突，悍匪那边快速操作已经移动位置了，但是悍匪移位这个应用信息却被你的TCP放在接收缓存里，你机器显示器上看到的悍匪还在原来的位置，然后你自然向悍匪原来的位置开枪，结果呢，肯定没伤到悍匪，却被早就移位的悍匪爆头击毙，这时候你会爽吗？肯定骂死这个游戏应用了，呵呵。
        那么交互式应用如何保证应用字段能够被立即处理呢？答案就是将带有应用字段的TCP报文（不论应用字段大小）的PUSH位全部置一，虽是小包，但TCP一旦接收到便立即将其交付应用程序处理。

       我在08年做内部《TCPIP详解卷一》培训在讲到第19章《TCP的交互数据流》时，曾今专门捕获了WAR 3的局域网游戏的交互报文，用于讲解TCP交互式应用的特性，现在把这个报文一并放在此供各位参考。

WAR 3的局域网游戏的报文：

        交互式应用并不是非常常见，因此经常被大家忽略，导致有时在遇到交互应用场景的分析时，将其当作HTTP等常见应用的特性来进行分析，可想而知，如此将走向错误的分析方向，望各位兄弟姐妹引以为鉴。

        这里提到了TCP报文的一个非常重要的标志位——PUSH，我下一篇文章将会针对PUSH位做一个详尽的讨论和分析，望大家关注。

阅读全文>>

标签: 同步 TCP 应用字段 故障 push 交互式应用 交互

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

基于UDP的应用如何保证应用数据的可靠性

作者：易隐者 发布于：2012-8-28 22:58 Tuesday 分类：网络分析

       UDP的传输效率比TCP更高一些，其在网络中交互时具有更小的延时，因为其一，发送方只要把应用字段全部交给网络层处理就行了，接收方不需要确认发送方发送的数据，发送方也没有等待接收方确认报文这些过程；其二，TCP报头一般20个字节，UDP报头只有8字节，因此UDP跟TCP相比，在同长度的IP报文中能够承载更多的有效应用数据。

       很多应用设计者和开发者正是看中了UDP的这种特性，将他们的应用程序利用UDP来实现端对端的数据交互，但是UDP不可靠，它没有TCP的确认、重传、窗口、保活等机制，那么基于UDP的应用如何保证其应用数据在交互过程的可靠性呢？答案是由基于UDP的应用程序来完成。

    为此我花费了点时间找了一些基于UDP 的应用报文解码，我们一起逐一来看看吧。 

TFTP（应用层确认）：  

某UDP应用（应用层保活）：

RTP(应用层排序)： 

DHCP：（应用层标识） 

       上次有个网友问我QQ传大文件的时候，为什么没抓到分片包文？我的回答是：应用层做了分片。虽然我并不清楚QQ文件传输协议的具体工作机制，但是其实跟我上面分析讨论的一样，QQ利用UDP传输文件，抓包的时候也看到的确是UDP的连接，但是没看到分片报文，那么原因只能是QQ应用程序为了保障传输文件的可靠性，避免在网络层被分片，应用程序在将大的应用字段交付给UDP之前，针对大的应用字段做了分片处理，这个过程跟TCP的MSS协商后做分段处理有点类似。

       现实工作环境下常见的UDP应用主要有P2P下载、视频会议、在线视频、VOIP语音、在线游戏等，有兴趣的兄弟姐妹，可以找一些工作环境中的这些应用的报文，来验证或完善一下我上述所言，如果找到的话，记得给我留言，顺便把报文给我一份。

阅读全文>>

标签: UDP 基于UDP的应用 可靠性 DHCP RTP TFTP 保活

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