一、问题描述
某设计院的财务应用需要通过广域网访问北京的服务器，但是用户反映该应用登录以及业务日常操作时会出现访问缓慢的现象，对员工的工作效率有较大的影响。在广域网出口位置部署科来网络回溯分析系统，对日常广域网链路的流量进行监控与分析。
二、分析过程
１.对该设计院访问北京应用服务器的流量进行分析。
图1
上图为客户端AA.AA.34.61在17点29分对服务器BB.BB.1.32的访问。其中客户端访问服务器7001端口的会话为客户端登录阶段，该登录阶段每个TCP会话的持续时间都不足1秒钟，整个登录阶段的数据传输从17:29:26持续到17:29:28大约3秒钟。但是从17:29:28到17:29:58这30秒钟服务器与客户端没有任何数据通信。客户端从17:29:58开始AA.AA.34.61开始访问服务器的11034端口开始业务数据的传输。
并且我们发现数据传输空白的这30秒时间内应用界面仍然在登录过程中，使用人员不能进行任何操作。
可以判断：客户端与服务器的数据交互在3秒内已经结束，剩下的时间是客户端本地的启动时间。
２.对业务操作流量进行分析：
如下图客户端访问服务器的TCP 11034端口为业务操作数据传输，客户端与服务器之间的传输延时很低（如红框所示服务器传输时延基本保持在0.03秒左右），也不存在大量的丢包重传情况。可以判断应用缓慢不是由于网络延时或者丢包造成的。
图2
如下图所示，一个持续48秒的会话，其中绝大部分是客户端空闲时间。
图3
也有情况如下图，三次握手结束后，客户端发出请求命令，大约0.039秒后收到来自服务器的ACK回复，表示该命令服务器已收到。但过了12.05秒后服务器才开始传输客户端请求的数据，这段时间主要是服务器对该操作命令的响应时间。因此在该会话中服务器响应时间为主要的延时构成。
图4
图5
还有在使用某些功能时，如查询“模拟折旧”会造成应用卡死。如下图所示，客户端发出查询包，大约0.077秒后收到来自服务器的ACK回复，表示该查询命令服务器已收到。但过了227秒后服务器依然没有传输后续数据，客户端发出RST包终止会话。
图6
三、分析结论及建议
通过上文中的分析，我们可以看到客户端与服务器的数据交互在3秒内已经结束，剩下等待时间是客户端本地的启动时间，因此客户端登录延时是本地客户端启动缓慢造成。
客户端与服务器之间的传输延时大约0.03秒左右，也不存在大量的丢包重传情况。可以判断应用缓慢不是由于网络延时或者丢包造成的。应用的主要时延构成分别是客户端空闲时间，服务器响应时间，甚至有些查询会导致服务器无响应。 |
发表于 2015-8-25 16:41:38