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

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

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