疑难网络故障分析解决方案..docx

疑难网络故障分析借助网络分析工具排查门户网站访问失败原因故障现象描述故障现象描述某运营商为3G用户提供访问的web portal系统，在每天业务高峰（22:30至23:30）时段都会接到大量的用户投诉：网站访问不了！在故障时间段， web服务器和各网络设备的进程、资源开销与平时相比并无异常；事后查看各设备的日志，也找不到故障的原因。基本环境描述用户基本网络拓扑如下图所示，3G手机用户经过无线网络后，通过3G核心网访问web portal系统，web portal系统内部由多台服务器上联到一台交换机，通过Redware做负载均衡，再通过出口路由器和防火墙上联到3G核心网：系统管理员一直尝试通过监控服务器和网络设备本身的状态、进程和日志的手段来解决问题，但这种传统的网管方式存在以下几个难点：系统结构复杂：系统管理员没有3G核心网的管理权限，而web portal系统内部需要监控的设备很多，工作量大，无法迅速定位是web portal系统内部还是3G核心网端的问题；无法关联分析：不同设备的监控数据无法进行有效的关联分析，无法拿出一个整体解决方案；缺乏故障回溯数据：各设备的日志系统内容有限，无法对故障进行回溯；监控网络设备时无法获取应用信息，监控应用服务器时无法获取网络信息。分析方案设计分析目标借助网络协议分析工具，能够从网络的角度分析到应用信息，实现web portal系统端到端的性能监控，分析web portal系统在故障时间段与平时相比有何异常，最终定位到有问题的设备节点。分析设备部署在web portal的出口路由器上抓包分析，能够迅速的定位到时web portal内部问题还是3G核心网端的问题。分析情况基本流量分析流量负载分析：由下图可见，web portal系统的平均流量为8.060Mbps，与平时相比并无异常，也没有发现异常爆发的广播和组播流量；平均包长为718.507字节，并无异常。流量突发分析：由下图可见，在故障时间段，并未发现明显的流量突发。包尺寸分析：未发现异常小结：通过流量的负载和突发分析，没有发现异常现象，可以排除网络异常流量原因，可进一步分析网络层以上的信息TCP连接分析如下图所示，通过TCP统计信息我们发现：在故障时间段，总共有135个用户访问了该web服务器，建立的TCP连接数为5235个，而可疑的是这5235个连接，有2213次是通过TCP复位发送（RST）来结束连接，而不是通过正常的4次握手来结束连接。通过三次握手分析网络时延技巧业界通过三次握手分析网络时延的技巧如下图所示：我们可以利用网络时延分析的技巧，为正常的TCP连接建立模型，以便在对异常连接分析时能够提供对比。成功连接的分析模型某对成功连接的TCP连接时序图如下所示：由上图可见，该客户端通过三次握手与服务器建立连接，再进行数据传输：其中，第二个数据包“SYN，ACK”与第一个数据包“SYN”的时间差T1=0.032毫秒，可视为web portal系统内部网络时延，第三个数据包“ACK”与第二个数据包“SYN，ACK”的时间差T2=102.036毫秒，可视为手机用户到web portal系统的网络时延，包括了出口路由器、3G核心网端的网络时延。通过以上分析分析，我们可以得出这样的结论：正常情况下，web portal系统内部网络时延大致在1毫秒以内，而3G核心网端（包含出口路由器）的时延为100毫秒左右。失败连接快速发现失败的连接一般数据量较少，因此我们根据“字节”进行排序，能够快速的定位到那些响应失败的连接：失败原因分析下图为某对失败连接的TCP连接时序图，从图中可以看出，该客户端向服务器发起了三次建立连接的请求，三次都以失败告终。右上图可见，服务器回应客户端同步请求的“SYN，ACK”数据包都是在1毫秒内完成的，由此可见，web portal系统能够快速的响应客户端的连接请求，并非连接失败的原因。而在服务器同步确认后，客户端反而发送“RST（TCP复位发送）”数据包中断了连接，从而导致在10秒钟内三次连接都没有成功，从手机用户的角度来看就是“网页打不开”，之前的TCP统计中我们发现5235个连接中，有2213次这种连接失败，于是便有大量的用户投诉。由于RST数据包来至客户端方向，我们可以初步定为问题在于：web portal出口路由器或者3G核心网端。进一步查看上图，我们发现这三次RST的时延分别为：(0.398-0.032)毫秒= 0.366毫秒(3.279895-3.275531)秒= 0.00034秒= 0.344毫秒(9.359916-9.359537)秒=0.000379秒=0.379毫秒全部都在1毫秒以内，结合我们之前建立的分析模型，如果该RST是由3G核心网端发起的，响应时延应该在100毫秒左右，而只有在本地网络的出口路由器