网络慢故障分析实.ppt

网络慢故障分析实例 目录 零窗口导致应用间歇性停滞 打印慢故障 防火墙应用层检测导致FTP慢 专网内打开网页慢 总结 案例1-TCP窗口问题导致应用慢 数据交互过程分析 分析结论 案例2-某应用打印慢故障 分析过程1-定位异常TCP会话 分析过程2-定位延时产生的位置 分析过程3-查看数据包内容 分析结论与故障解决 案例3-防火墙应用层检测BUG导致FTP慢 故障现象 故障环境 故障分析思路 故障分析过程 故障解决 故障环境 故障现象 省局到国家局的FTP服务很慢，一般需要40多秒才可以登陆上去，有时根本登陆不上去 Ping测试延时很小 省局到国家局的HTTP应用正常 前期简单分析 Ping延时很小，说明网络层的延时很正常 网络环境复杂，数据流走向复杂，数据包来回路径不一致，中间经过2台防火墙，可能存在状态检测的问题 HTTP的数据流走向跟FTP的数据流走向应该是一样的，HTTP正常，FTP不正常，说明这个跟TCP的状态检测无关，应该是FTP应用层的问题 暂时没什么头绪，只能先从客户端下手，进行抓包分析，看看大体的情况 登陆不上时的数据包分析 登陆成功，但是很慢的数据包分析 交互过程示意图 定位是什么设备丢包 防火墙丢包原因分析 故障解决 故障解决： 1，在防火墙上取消FTP应用绑定，让防火墙不要对FTP的数据包进行深度的过滤和检测 2，测试，FTP登陆正常 案例4-网页打开慢 * * 睿博工作室 易隐者 QQ：349932999 MAIL：shujuhua@163.com 故障现象： 应用在交互的过程中，经常出现数秒的停滞，然后恢复正常，过段时间后，又再次出现停滞现象，如此反复 C发送133B的数据 C发送512B的数据 S通告窗口大小为348B C发送53B的数据 C发送348B的数据 S通告窗口大小为0 C对S的窗口探测报文 S窗口仍未更新，大小为0 C对S的窗口探测报文 S窗口仍未更新，大小为0 S窗口更新为8192B 窗口问题导致应用产生了3秒的延时 零窗口一般都是应用程序处理性能较差，来不及处理缓存中的数据或者应用服务器本身性能不足导致的 分析结论: 应用出现停滞现象主要是由于服务器端出现窗口为０导致的，肯定跟网络无关，可以从服务器本身性能或者服务器端应用程序入手进行相应的检查 TIPS： 并不是每次的故障我们都要去解决，我们网络分析最主要的目的是找到问题的原因和源头，有些事情是我们本身解决不了的，例如：应用软件的问题、互联网的问题、设备本身的问题、硬件的问题 故障现象： 用户某个业务应用在执行打印操作时，打印速度很慢，一般需要等20多秒才可以正常打印。 故障分析： 打印行为似乎跟网络无关，但是我们还是先抓包看看，我们发现，每次打印的时候，客户端均需要连接数据库服务器，如下图： 这说明，这个打印操作是需要连接网络中的数据库，从数据库中调用相关的打印数据，也就是说，这个网络调用的过程，很可能就是产生打印时延的原因 在科来的“会话”视图中，我们查看TCP会话，我们可以发现有三个会话跟数据库有关 我们可以根据TCP的会话持续时间，来定位产生延时的TCP会话 原理： 我们通过时间差来定位延时产生的位置。 我们可以发现在时间差视图中，存在一个22.9秒的延时，这个数据包是客户端向服务器发送的数据包，那么这个延时应该就是客户端产生的 是客户端向数据库服务器进行查询的行为； 客户端在等待了近23秒才向服务器发出这个查询操作！ 分析结论： 1，客户端在执行打印操作时，需要向网络中的数据库服务器调用相应的打印数据 2，客户端在与数据库服务器交互的过程中，本身在执行一个查询操作前，等待了22.98秒的时间，从而导致了打印的延时 故障解决： 卸载这个应用软件，重新安装，再次测试打印速度，已经恢复正常，至此，故障解决 小结： 其实，我们还可以通过对比分析法（对比分析正常打印的数据包与打印慢的数据包）来定位这个故障的原因。 说明： 1、客户端的默认网关是主路由器 2、主路由上设置了相应的策略，凡是FTP/HTTP的应用均交由备路由处理 3、备路由上会将访问国家局的网段指向国家局路由 4、核心与路由间均部署防火墙，防火墙工作在透明模式下 5、客户端访问服务器的数据流走向比较复杂，看演示 思考： 服务器回包的数据流走向是如何的？ TCP三次握手建立连接 S响应：winsock ready C输入用户名 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