网络慢分析实例.pptVIP

案例5-业务访问慢 访问过程的简单流程 说明： 高新建投集团办公系统服务器地址为91，通过防火墙转换为39，提供访问的端口为6888。 高新建投集团办公局域网中的用户如要访问办公系统要通过防火墙进行地址转换为39来访问办公系统。 首先我们通过IP端点视图定位39（办公系统服务器）。如图 定位异常地址 对定位数据包分析时发现专家诊断视图有ICMP目的不可达的提示。 数据包分析 再通过数据包视图来看看他是对那些数据包进行了差错报告。如图 数据包分析 数据交互流程流程 通过上面的分析可知可能是防火墙或办公系统服务器有故障。那么只要看ICMP目的不可达类型为3代码为10的数据包是那台机器发送的（可以通过数据包的TTL来判断），那就能知道是防火墙还是办公系统服务器有故障了。 查找故障位置 谢谢 * 看第6个数据包，发现有TCP重传标记，但是传的字节长度变成了348B，而不是53B。这是因为第6个数据在重传第5个数据包时，把自己的要传输的数据一起加了进去。 对于第4个数据包通知了窗口大小是348B，即表示只能接受大小为348B的数据。 * 高新建投集团办公主机在登录集团办公自动化系统时偶尔会出现登录慢或有些模块加载不成功。 * 从上图可知ICMP目的主机被强制禁止差错报告包是对IP标识为0x0C9F的数据包进行的差错报告。 * 根据以上的分析步骤对其他的ICMP目的不可达差错报告数据包进行分析得知ICMP目的不可达差错报告包都是对客户端的TCP三次握手中第一个数据包同步数据包进行差错报告。 * 通过上面的分析可知可能是防火墙或办公系统服务器有故障。那么只要看ICMP目的不可达类型为3代码为10的数据包是那台机器发送的（可以通过数据包的TTL来判断），那就能知道是防火墙还是办公系统服务器有故障了。 上图所示的TTL值是63，经过了一跳，所以是服务器的故障。 从39发往67数据包TTL为63，因为数据包每经过一路由设配TTL值都会减去1，可知是办公系统服务器的数据穿越了防火墙发往客户端的，从而可确定故障为办公系统服务器。 网络慢故障分析实例 科来安徽办事处 目录 零窗口导致应用间歇性停滞 打印慢故障 防火墙应用层检测导致FTP慢 网上申报故障 业务访问慢 案例1-TCP窗口问题导致应用慢 故障现象： 应用在交互的过程中，经常出现数秒的停滞，然后恢复正常，过段时间后，又再次出现停滞现象，如此反复 数据交互过程分析 C发送133B的数据 C发送512B的数据 S通告窗口大小为348B C发送53B的数据 C发送348B的数据 S通告窗口大小为0 C对S的窗口探测报文 S窗口仍未更新，大小为0 C对S的窗口探测报文 S窗口仍未更新，大小为0 S窗口更新为8192B 窗口问题导致应用产生了3秒的延时 零窗口一般都是应用程序处理性能较差，来不及处理缓存中的数据或者应用服务器本身性能不足导致的 分析结论 分析结论: 应用出现停滞现象主要是由于服务器端出现窗口为０导致的，肯定跟网络无关，可以从服务器本身性能或者服务器端应用程序入手进行相应的检查 案例2-某应用打印慢故障 故障现象： 用户某个业务应用在执行打印操作时，打印速度很慢，一般需要等20多秒才可以正常打印。 故障分析： 打印行为似乎跟网络无关，但是我们还是先抓包看看，我们发现，每次打印的时候，客户端均需要连接数据库服务器，如下图： 这说明，这个打印操作是需要连接网络中的数据库，从数据库中调用相关的打印数据，也就是说，这个网络调用的过程，很可能就是产生打印时延的原因 分析过程1-定位异常TCP会话 在科来的“会话”视图中，我们查看TCP会话，我们可以发现有三个会话跟数据库有关 我们可以根据TCP的会话持续时间，来定位产生延时的TCP会话 分析过程2-定位延时产生的位置 原理： 我们通过时间差来定位延时产生的位置。 我们可以发现在时间差视图中，存在一个22.9秒的延时，这个数据包是客户端向服务器发送的数据包，那么这个延时应该就是客户端产生的 分析过程3-查看数据包内容 是客户端向数据库服务器进行查询的行为； 客户端在等待了近23秒才向服务器发出这个查询操作！ 分析结论与故障解决 分析结论： 1，客户端在执行打印操作时，需要向网络中的数据库服务器调用相应的打印数据 2，客户端在与数据库服务器交互的过程中，本身在执行一个查询操作前，等待了22.98秒的时间，从而导致了打印的延时 故障解决： 卸载这个应用软件，重新安装，再次测试打印速度，已经恢复正常，至此，故障解决 小结： 其实，我们还可以通过对比分析法（对比分析正常打印的数据包与打印慢的数据包）来定位这个故障的原因。 案例3-防火墙应用层检测BUG导致FTP慢 故障现象 故障环境 故障分析思路 故障分析过程 故障解决 故障环境 说明：