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

糟糕的业务网络行为

作者:易隐者 发布于:2012-12-11 15:40 Tuesday 分类:网络分析

       我之前在讲解业务应用分析评估时,重点分析业务应用的网络行为特征、业务基线、响应时间等内容。很多人认为:我的业务应用操作我们自己都是非常熟悉的,为什么还要这么复杂的来分析业务应用的网络行为呢?这是因为业务应用系统在开发的时候,由于各种原因,可能导致业务应用本身在交互的过程中,存在一些不合理的网络行为,进而影响业务运行的效率,造成网络资源的消耗和浪费。我们对业务应用系统进行网络交互行为的分析和评估,可以发现这些不合理的网络行为,帮助改进完善业务应用系统,提高业务应用交互的效率。

       近日正好在Laura Chappell的网站上下载了一个应用异常网络行为的数据包文件,这是一个FTP登录交互的报文,其交互过程如下: 

点击查看原图

       客户端与服务器三次握手建立TCP连接之后,服务器端应用响应:220 FTP Service ,此时客户端发出应用请求“USER  FRED”,但我们可以清晰的看到其请求过程是:先将第一个字符发送过去,在收到服务器的确认之后,客户端再传输第二个字符,如此一个字符一个字符的传输。

       在后续的客户端密码传输过程中,客户端的网络行为跟传输用户名的网络行为一样。如下图所示: 

点击查看原图

       服务器与客户端之间几十毫秒的RTT往返时间,加上客户端本身动辄数百毫秒甚至几秒的延时,造成整个FTP登录过程持续近14秒,如下图所示:

点击查看原图

        我们再来一起看一个正常的FTP登录过程: 

点击查看原图

       从这个FTP登录的过程我们可以清晰的看到,FTP客户端是将用户名、密码放在一个报文中一次性传送给服务器的。

       一个最为常见的FTP应用,一个最为普通的登录操作,正常情况下,数秒内完成,但是由于这个FTP应用不合理的网络行为,共消耗了近14秒的时间。

       什么是糟糕的应用网络行为?这个就是!为什么需要分析评估业务应用的网络行为特征,这个就是明证!

阅读全文>>

标签: FTP 行为特征 网络行为 应用分析 RTT 业务评估 往返时间

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

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) 浏览(18430)

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