网络慢分析实例_第1页
网络慢分析实例_第2页
网络慢分析实例_第3页
网络慢分析实例_第4页
网络慢分析实例_第5页
已阅读5页,还剩33页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

网络慢故障分析实例科来安徽办事处目录零窗口导致应用间歇性停滞打印慢故障防火墙应用层检测导致FTP慢网上申报故障业务访问慢案例1-TCP窗口问题导致应用慢故障现象:应用在交互的过程中,经常出现数秒的停滞,然后恢复正常,过段时间后,又再次出现停滞现象,如此反复数据交互过程分析C发送133B的数据C发送512B的数据S通告窗口大小为348BC发送53B的数据C发送348B的数据S通告窗口大小为0C对S的窗口探测报文S窗口仍未更新,大小为0C对S的窗口探测报文S窗口仍未更新,大小为0S窗口更新为8192B窗口问题导致应用产生了3秒的延时零窗口一般都是应用程序处理性能较差,来不及处理缓存中的数据或者应用服务器本身性能不足导致的分析结论分析结论:应用出现停滞现象主要是由于服务器端出现窗口为0导致的,肯定跟网络无关,可以从服务器本身性能或者服务器端应用程序入手进行相应的检查案例2-某应用打印慢故障故障现象:用户某个业务应用在执行打印操作时,打印速度很慢,一般需要等20多秒才可以正常打印。故障分析:打印行为似乎跟网络无关,但是我们还是先抓包看看,我们发现,每次打印的时候,客户端均需要连接数据库服务器,如下图:这说明,这个打印操作是需要连接网络中的数据库,从数据库中调用相关的打印数据,也就是说,这个网络调用的过程,很可能就是产生打印时延的原因分析过程1-定位异常TCP会话在科来的“会话”视图中,我们查看TCP会话,我们可以发现有三个会话跟数据库有关我们可以根据TCP的会话持续时间,来定位产生延时的TCP会话分析过程2-定位延时产生的位置原理:我们通过时间差来定位延时产生的位置。我们可以发现在时间差视图中,存在一个22.9秒的延时,这个数据包是客户端向服务器发送的数据包,那么这个延时应该就是客户端产生的分析过程3-查看数据包内容是客户端向数据库服务器进行查询的行为;客户端在等待了近23秒才向服务器发出这个查询操作!分析结论与故障解决分析结论:1,客户端在执行打印操作时,需要向网络中的数据库服务器调用相应的打印数据2,客户端在与数据库服务器交互的过程中,本身在执行一个查询操作前,等待了22.98秒的时间,从而导致了打印的延时故障解决:卸载这个应用软件,重新安装,再次测试打印速度,已经恢复正常,至此,故障解决小结:其实,我们还可以通过对比分析法(对比分析正常打印的数据包与打印慢的数据包)来定位这个故障的原因。案例3-防火墙应用层检测BUG导致FTP慢故障现象故障环境故障分析思路故障分析过程故障解决故障环境说明:1、客户端的默认网关是主路由器2、主路由上设置了相应的策略,凡是FTP/HTTP的应用均交由备路由处理3、备路由上会将访问国家局的网段指向国家局路由4、核心与路由间均部署防火墙,防火墙工作在透明模式下5、客户端访问服务器的数据流走向比较复杂,看演示思考:服务器回包的数据流走向是如何的?故障现象省局到国家局的FTP服务很慢,一般需要40多秒才可以登陆上去,有时根本登陆不上去Ping测试延时很小省局到国家局的HTTP应用正常前期简单分析Ping延时很小,说明网络层的延时很正常网络环境复杂,数据流走向复杂,数据包来回路径不一致,中间经过2台防火墙,可能存在状态检测的问题HTTP的数据流走向跟FTP的数据流走向应该是一样的,HTTP正常,FTP不正常,说明这个跟TCP的状态检测无关,应该是FTP应用层的问题暂时没什么头绪,只能先从客户端下手,进行抓包分析,看看大体的情况登陆不上时的数据包分析TCP三次握手建立连接S响应:winsockreadyC输入用户名C用户名第一次重传2.9S的延时S的第一次重传S的第二次重传C用户名第二次重传C用户名第三次重传S的第三次重传C用户名第四次重传S:用户名ok,需密码C输入密码S:超时关闭S“需密码”重传C重传密码5.9S的延时12S的延时23.9S的延时23.9S的延时6S的延时15.8S的延时C对”S第一次重传“的确认C对”S第二次重传“的确认C对”S第三次重传“的确认登陆成功,但是很慢的数据包分析TCP三次握手建立连接S响应:winsockreadyC输入用户名C用户名第一次重传C用户名第二次重传C对”S第一次重传“的确认C对”S第二次重传“的确认S的第一次重传S的第二次重传S:用户名ok,需密码S“需密码”第一次重传C输入密码C密码第一次重传C密码第二次重传S“需密码”第二次重传C密码第三次重传S:登陆成功29.9S的延时23.9S的延时11.9S的延时5.8S的延时2.8S的延时交互过程示意图用户名请求用户名请求用户名用户名请求用户名请求用户名用户名请求用户名请求用户名请求用户名请求用户名S:winsockreadyC输入用户名C用户名第一次重传C用户名第二次重传S的第一次重传S的第二次重传S的第三次重传结论:客户端传输用户的数据包被中间设备丢掉了!定位是什么设备丢包原理:一个目的地址不是中间设备的包进入一个中间设备,它必然会被中间设备转发到一个出口,否则,就是被中间设备丢弃了对比分析法:通过抓取中间设备进出口的数据包,结合数据包内IPID、五元组、内容等信息来判断是否属于同一会话,是否有数据包被丢弃双网卡笔记本安装科来开启两个工程,分别针对中间设备进出口抓包TAPTAP其实我们也可以利用中间设备本身自带的抓包功能进行分析和定位,具体可以参考我以前写的PPT:《疑难故障解决实例》通过此种方法,我们定位出是防火墙丢包!防火墙丢包原因分析TIPS:防火墙中的两个概念状态检测:深度检测:原因分析:1,数据包来回路径肯定是不一致的,那么对于基于状态检测的防火墙,是不会建立TCP连接的但是HTTP应用正常,抓包显示FTP三次握手的过程也很正常,说明跟TCP状态检测无关2,抓包分析我们可以发现被丢弃的包都是FTP传输用户名和密码的包,这个肯定属于FTP应用层的包,防火墙丢弃FTP应用层的数据包,那么问题应该就出在防火墙的FTP应用层检测上故障解决故障解决:1,在防火墙上取消FTP应用绑定,让防火墙不要对FTP的数据包进行深度的过滤和检测2,测试,FTP登陆正常思考:除了在防火墙上取消针对FTP应用的应用层深度检测功能外,还有其他的解决方式吗?提示:大家注意数据包中的ICMP重定向报文案例4-网上申报故障说明:1,网上申报服务器的地址是,经过网闸后转换为X.X.16.73;2,前置机的IP地址为X.X.16.56,征管服务器的IP地址为X.X.16.200。业务访问流程:1,纳税人通过互联网登陆网上申报服务器,提交相关纳税信息;2,网上申报服务器将这些纳税信息转发给前置机的同时,将相关信息写入征管服务器数据库;3,网上申报服务器与前置机的数据交互出现问题,那么网上申报服务器会将征管服务器数据库相关的信息锁死

拓扑:故障现象故障现象:1,网上申报业务系统运行时,每天总有一部分纳税人的申报表单数据无法正常上传,可以通过征管服务器的业务软件看到这些用户的申报数据处于锁状态;2,在没有网闸的情况下,网上申报服务器与前置机直接通讯,则故障现象消失,网上纳税全部正常。故障分析前期分析1,结合故障现象与业务流程,我们可以清晰的发现,问题应该就是出现在网上申报服务器经过网闸的地址转换后与前置机交互的过程。2,在网上申报服务器不通过网闸的地址转换而是直接与前置机交互的时候,业务应用一切正常,那么,是网闸在做地址转换的时候对某些数据报文做了修改或者是网闸直接丢弃了某些业务报文导致的故障吗?3,网闸是最为可疑的故障关键点,我们决定在网闸前后部署网络分析系统(在此环境下,可直接在申报服务器上和前置机上分别安装网络分析系统),对网上申报业务数据交互过程分别进行抓包,如下图所示:数据分析-发现异常TCP会话我们通过科来网络分析系统捕获前置机交互的数据包,一段时间后,我们在“TCP会话”视图中,发现有几个TCP会话持续的时间比一般的TCP会话长很多,如下图所示:这几个TCP会话持续的时间均超出其他的会话很多异常会话交互过程分析网闸地址73首先发送RESET报文网闸地址向前置机发送(重传)报文,前置机直接发送RESET报文重置连接。这个过程,导致了该TCP会话持续时间很长。第一个reset报文解码这个数据报文的源MAC地址并非网闸的MAC,真实的网闸MAC地址是00:40:63:EF:43:DF

为什么网闸的MAC发生了变化?难道网内存在会话劫持?查看整个交互过程的MAC变化网闸源MAC为00:40:63:EF:43:DF前置机发往网闸的确认数据报文,封装的目的MAC却是00:21:5E:82:AF:86MAC为00:21:5E:82:AF:86的设备以网闸的IP向前置机发送RESET报文在交互的过程中,前置机将发给网闸地址的确认报文,封装了一个非网闸的MAC地址00:21:5E:82:AF:86,为什么会突然出现了这种改变呢?前置机封装错误目的MAC的原因InternetAddressPhysicalAddressTypeX.X.16.7300-21-5E-82-AF-86dynamicTIPS:ARP表的更新实际环境中,只有同时满足以下两个条件时,设备的ARP表项才会更新:1,设备收到来自某IP的ARP请求包或免费ARP包;2,设备的现有ARP表项中已经存在该IP对应的ARP表项。其他的非ARP报文不会对设备的ARP表项产生影响。一般而言,主机是根据其ARP表项来封装要发送的数据报文的目的MAC地址,那么,这里前置机发往网闸数据报文的目的MAC地址出现改变是否是因为前置机的ARP表项内容变化了呢?我们在前置机的DOS窗口下,使用arp–a命令查看异常时的arp表项内容,发现网闸IP对应的MAC地址的确变成了00:21:5E:82:AF:86。前置机ARP表更新的原因我们在科来网络分析系统的“数据包”视图查看交互过程的所有数据报文来自MAC地址为00-21-5E-82-AF-86的ARP响应到达了前置机,前置机更新其ARP表项前置机向网络中发送ARP请求,请求网闸IP对应的MAC前置机在收到来自网闸的数据报文之后,都向00-21-5E-82-AF-86地址发送确认报文网闸、前置机以及未知设备的数据交互情况和状态变化案例5-业务访问慢访问过程的简单流程说明:高新建投集团办公系统服务器地址为91,通过防火墙转换为39,提供访问的端口为6888。高新建投集团办公局域网中的用户如要访问办公系统要通过防火墙进行地址转换为

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论