故障现象描述
基本环境描述
用户基本网络拓扑如下：
用户的基本网络拓扑如上图所示，整个网络环境主要是通过核心交换机连一个流控设备，然后流控设备再连到防火墙，通过防火墙上网。
招待所的网络通过连接一台Tplink路由器做了地址转换，将所有招待所出去的主机地址都映射为一个地址：192.168.30.253。
故障现象描述
整个学院的网络主要分为办公网和家用网两大块，故障时出现在招待所网络，而办公网没出现故障。
招待所内的主机要上网，打开网页的速度非常的慢，特别是像sina这样的图片很多的网站，甚至是访问本学院对外的web服务器也很慢。但是一旦把招待所网络全部断掉，用一台机器直接接在招待所路由上访问，打开速度非常正常。而且在出现故障时我们通过Ping测试发现Ping网站的延时只有几十毫秒，也没有严重的丢包现象。
分析方案设计
分析目标
确认Internet访问慢是由于网络原因引起的还是其他原因引起的，我们实地捕获招待所计算机对互联网访问的数据流进行分析，通过访问的整个过程分析来判断访问慢的原因是由于网络时延、丢包、还是其他原因引起的。
分析设备部署
我们在招待所交换机上、学院核心交换机上部署分析设备，镜像网络流量，对访问互联网的流量进行捕获?⒔蟹治觥?br /> 
分析情况
在招待所捕获的对外访问的数据分析
首先我们在招待所捕获一个我们对学员对外web服务器访问的数据流，然后对该数据流进行详细解码分析。
招待所捕获的数据流解码
TCP会话分析中，我们得到该数据流的如下信息：
数据流持续时间：1分17秒，也就是这个访问整个持续的时间。
总字节数：57Kbytes
从上面的数据上我们可以看到，整个的访问总字节数只有57KB，但整个时间用了1分多钟，确实是非常慢的。
解码分析详细的会话过程
三次握手时间
再通过解码分析详细的访问过程，我们发现这个数据流的三次握手时间很短，只有不到1毫秒，说明网络的时延很短。
服务器响应
通过分析服务器响应的数据包，服务器对get请求的响应为145毫秒，响应速度正常。
数据传输时间
数据传输的时间为1分17秒，传输的时间过长。
从上面的分析我们可以非常容易的发现，整个会话的时间过长基本上全部都是由于数据传输造成的。
通过对传输过程数据包的进一步分析，我们发现在传输过程中没有出现重传、丢包的现象，但是发现服务器发送数据时有停顿现象，在整个过程中出现了9次停顿，每次停顿的时间从4秒——10秒不等，整个停顿的时间非常长，导致了传输的过程很长。
如上图所示，传输过程中还出现重复的确认和乱序的现象，说明在网络中传输出现异常。
在服务器端进行流量分析分析
为确认服务器发送数据的停顿是服务器造成的还是由于网络传输造成的，我们在服务器端捕获网络访问流量，同时在核心交换机上同时捕获流量，进行比对分析，来确认造成数据传输停顿的原因。
Server端数据分析
通过对Server端数据的分析，我们发现Server端发送数据时有大量的重传现象出现，每次数据重传都是在传输数据后没有得到客户端确认后的重传，每次重传都造成传输的停顿。
在Server端和客户端的数据分析结果有明显的不同，客户端分析中并没有收到数据没有确认的现象，只有服务器停顿的现象，而在服务器端分析确是发出了数据包没有得到确认，所以停顿后重传，这说明网络中可能存在丢包，导致数据传输出现问题。
查找丢包的点
利用分析设备分段捕获，来查找造成网络丢包的点，从而定位问题点。我们在流量控制设备前和流量控制设备后的访问数据进行对比分析，对比结果如下：
对比分析
上图是经过流控设备前和之后的数据流时序图的对比分析，从上图可以看到，在经过流控设备时，有丢包现象，通过观察如图中黑线框所示产生延时的数据包是线框中的第一个数据包的重传。而且从上面的分析图中可以看到，在流控设备前的被重传的数据包并没有传到流控设备后，所以数据包被丢失是发生在流控设备上。
分析结论
流控设备的丢包造成招待所对Internet访问缓慢，当招待所上网主机少时，流控设备没有丢包，访问正常，但当上网主机多时，流控设备丢包明显，导致访问极其缓慢。
而同样经过流控设备的办公网络，则没有这种现象。
推断是由于招待所采用了一台路由设备进行NAT，对流控设备来讲是一个IP的访问，可能是流控设备的控制策略设定控制单个IP的访问流量或会话导致招待所访问出现异常。
在将招待所的NAT设置去除后，发现访问网页速度明显变快，从而排除了故障。