欢迎关注:1,欢迎关注本博客,你可点击右手边的【QQ邮件订阅】订阅本博客!2,本博客推出江湖救急计划,主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析,如有需要,请在江湖救急计划页面给我留言!

某集团公司内网访问业务慢分析报告

作者:甜瓜 发布于:2017-7-28 10:21 Friday 分类:网络分析

 

1情况概述

1.1  网络拓扑结构

某集团公司的服务器通过代理服务器向内外网用户提供业务访问,用户每次访问都是与反向代理服务器交互数据,代理服务器是透明模式部署,每次用户进行访问代理服务器的时候代理服务器都会向真实服务器调用业务资源。

      

拓扑示意图

1.2 情况简介

用户反映办公网楼层的用户在访问业务会出现卡顿现象,时间大约都在十几秒左右,外网登录只需要5秒之内。

1.3 分析思路

前期用户在反向代理服务器同一网段的位置部署了一台测试客户端,发现登录时间正常没有出现卡顿现象,整个登录时间大概都控制在5秒之内。说明该故障是局部性的,所以我们对问题区域到业务区域的路径进行梳理,逻辑结构如下:

该区域用户在访问业务的时候产生的报文会先经过楼层交换机,经过楼层核心再经过IPS、防毒墙、Juniper防火墙等安全设备再到反向代理服务器,反向代理服务器收到客户端请求后会把请求再进行转发,转发后的请求再次经过Juniper防火墙到主核心再到真实服务器。真实服务器对请求进行响应,响应数据从源路径返回。

    

 

业务路径图


 

2分析具体流程

2.1 抓包位置选取

在问题区域选取一台PCIP地址是XX.XX.4.78进行登录测试,并且在测试PC端和反向代理服务器的两个位置同时进行抓包分析,还原整个会话过程。

     

2.2 选择分析会话

通过用户之前提供的在浏览器上显示组件分析截图可以知道, POST请求的JS库耗时最长达到了17.87秒,产生了4.31MB的数据。所以在捕获的报文中着重分析该POST请求动作。

           

在现场进行内网登录测试并且同时抓包记录了整个交互过程:整个登录时间大概有十几秒钟,在抓包结束后提取该POST 字段的TCP会话,发现在PC端与代理服务器端的数据交互时间都是14.419秒左右。

对此我们按照报文交互的时间顺序分别对PC端与代理端捕获的数据进行分析,阐述延时的原因。

2.2 第一个发现延时的交互分析

下面截图显示时间在13:55:06.909905客户端向代理发送POST请求,在13:55:06:910562的时间点,代理转发了该POST请求给真实服务。

  

我们发现在POST操作之后,代理服务器回应的第一个应用响应报文的延时上看,无论是在PC端捕获的还是在服务器端捕获的,代理服务器的响应延时都是1秒多钟,说明的确是代理产生延时。(以下截图的时间是相对时间)

   

这可能和代理调用真实服务器资源耗时有关,通过分析代理与真实服务器交互发现交互持续了1.045秒时间。

   

代理与真实服务器交互截图

说明真实服务器用了1.045秒的时间把POST请求数据传输给了代理服务器。代理服务器等待了1.045秒钟后,才对客户端进行数据响应。

         

                  交互示意图

2.3 延时1.63秒分析

2.3.1 PC端分析

PC端捕获的一段报文一共产生了1.63秒的延时,具体分析如下:

NO.442的报文的0.2秒延时是有客户端产生的,通过分析之前交互的行为,都是代理服务器发送两个载荷数据的报文后客户端立刻响应ACK报文,而NO.442只应答了一个来自代理端载荷数据的报文,并且有延时确认产生,说明用户的客户端启用了Delay ack机制。


NO.445是代理端产生的应用延时:

NO.446Delay ack报文,原因是因为代理只传输了一个报文导致的客户端的延时确认。

NO.447是代理端产生的延时应用响应:

2.3.2 代理端分析

通过关联PC捕获的N0.447ip.id == 0x631b可以在代理端找到同一个报文,在代理端是NO.226报文,在INFO信息里面显示该报文是重传报文,延时是0.82秒。