TCPDUMP排查页面卡顿

前几年做项目的时候遇到的一个问题，拿出来分享一下！

1\ 背景描述

用户开发了一套应用系统，是基于orical的EBS的应用，负载均衡部署在EBS前端，为两台EBS应用服务器做负载均衡。

为了简化网络拓扑的变更，负载均衡采用旁路部署。负载均衡和EBS服务器在同一网段（10.1.29.0/24）。

 简单拓扑结构如下图：

2\问题描述：

EBS和负载均衡同时上线后，经过一段时间的测试发现用户在点击EBS应用的一些功能菜单时，页面会出现一段时间的卡顿，10秒-1分钟不等。在这个期间页面显示白屏，无任何输出。而且这种现象时偶尔发生。

针对出现的这种现象用户要求我们解决此问题。

3\问题分析及解决

3.1  确定该问题是否是由于部署负载均衡导致。

首先我们先做的就是需要确定该问题是否是由负载均衡问题产生。所以，测试办法就是建议用户绕过负载均衡，直接访问EBS应用。

在经过一段时间测试后，用户直接访问EBS服务器没有出现页面卡顿异常现象。因此，现在可以判断问题的产生是由于负载均衡导致。

PS：在这个测试过程中，由于EBS应用直接关联了域名跳转，也就是说，如果用户直接访问EBS真实服务器的IP地址，那么EBS应用会跳转到对应的域名，域名在DNS上解析的地址是负载均衡虚拟服务器的地址。因此针对这种情况最简单的办法就是修改localhost文件。

3.2  先使用最简单方式来定位问题

由于用户的EBS应用使用B/S结构，根据经验，BS应用如果页面出现卡顿，或页面打开慢的问题，一般可能由于URL中有302跳转，或者是应用端口变化导致。因此，先使用最直观的排错工具httpwach来查看问题所在。

根据httpwatch所抓的数据进行分析，并未发现url跳转及应用端口变化。但是也发现了页面访问异常的原因，如下图（此图只是用来举例）：

在当时页面访问异常时，红色“wait”时间很长，基本和卡顿时间一至，红色wait的含义就是web server返回数据到客户端的时间。因此，可以断定，问题出现在服务器返回客户端数据出现异常。

3.2  使用tcpdump来定位问题

Tcpdump是解决任何疑难杂症的神器，但是由于tcpdump所抓的数据相比httpwacht不是很直观，因此抓包的时候需要一定技巧和耐心去分析。

  在使用tcpdump抓包时，个人建议有两个参数非常有必要加上，“-e”和“-n”，-e是显示IP地址对应的mac地址，-n是显示实际的数字端口号。

除此之外，在抓包过程中数据流各个环节都要抓，综合分析，更容易定位问题。如在此次抓包中分别在“client—负载均衡”“负载均衡-web server”以及web server上三个点来抓包。抓包过程略过，下图是发现问题的数据包。“Client-负载均衡”之间的数据包。如下图红色标示：

红色标示分析如下：

客户端—负载均衡 “10.2.4.17（54:7f:ee:1e:d2:01）”—“10.1.29.248（00:90:0b:2d:d7:e7）”

负载均衡—客户端  “10.1.29.248(00:90:0b:2d:d7:e7)”—“10.2.4.17(5c:51:4f:4f:49:cb)”

由此可以清楚看到问题所在，负载均衡在返回给客户端数据包的时候与客户端请求数据包路径不一致，因此可以判断负载均衡网关配置问题。查看负载均衡网关配置为10.1.29.1，而用户说该网段的网关应该都指向10.1.29.254，因此，修改负载均衡网关来解决此问题。

修改完负载均衡网关后，经过测试问题依旧，没有解决。

3.4  继续使用tcpdump抓包，深入分析

此时，问题陷入纠结状态，没办法，只能继续抓包分析，再次抓包的话建议使用-w参数，将抓包数据保存成文件，便于深入细致分析。

最终，发现问题，更改部署模式，问题解决。问题数据如下图：

分析如下：

首先，根据上图抓包数据能看到序号为91和92之间的数据包之间的时间差为17秒，而这个时间段也刚好是页面出现异常的时间段。在继续分析为什么两个数据包之间的时间间隔有17秒之久。先看间隔17秒之前的最后两个数据包90和91。序号为90的数据包是客户端确认序列号76的数据传输的ack确认，由ack75291能够看出来。在序列号76之后，负载均衡还传输了很多个数据包。回过头来我们再看看序号为90的数据包的特点，在这个数据包中客户端win size值为259，而负载均衡向客户端传输数据的数据包长度len值为1460，由此可见此时客户端允许接受的数据包大小259小于负载均衡发送的数据包大小1460。因此，出现了第91个数据包[tcp windows update]信息。

所以基本我们可以定位页面访问异常的问题就是客户端接收缓存不足造成的问题。

因此要解决这个问题，最简单的方式就是负载均衡在回传数据给客户端时不参与win size协商，客户端与服务器直接协商。因此，负载均衡需要开启源地址透传功能来解决此问题。经过更改负载均衡配置，及EBS网关配置，再次测试。问题解决。

 

四、特别说明：

以前在很多项目中额很多应用都部署过负载均衡，没有出现过类似的问题，为什么EBS应用会出现这种问题，从下图的httpwatch抓包可以看出一些原因。由下图可以看出，当用户点击EBS上一个菜单时，客户端是以post方式发送一些参数给服务器。服务器收到数据后会回传大量数据。回传过程中传输速度太快导致客户端没有足够的缓存接收。