之前写过一篇远程桌面无法访问——用wireshark定位问题，有朋友说比较实用，这鼓励我再写一篇。今天的这篇投稿涉及到性能问题，性能问题是比较难的，因为没有特别的 错给你做参考。
◆ ◆ ◆ ◆ ◆
客户问题
总部部署了一台ERP服务器，分支电脑的ERP客户端要通过深信服搭建的VPN来进行访问总部服务器。系统上线后，发现在分支用客户端打开后，有些数据内容要等很久才能显示出来。而在总部内 使用客户端访问ERP服务器则没有问题。同时在分支内 电脑去ping总部的服务器没有任何的丢包延时。
即，ping测试没有丢包延时，应用也能访问，没有 错，只是访问的时候显示内容要等很长时间。
拓扑环境如图（因为和公 ip没有关系，所以拓扑图中隐去不写）：
排查思路
1.分别在分支和总部设备的lan口，wan口，vpn口共6个接口上抓包。开启抓包后，再在分支电脑上打开ERP客户端访问，出现现象后，结束操作停止抓包。
2.我们要知道，TCP/IP体系模型是分层的。各层关注于自身的事物，同时下层又为上层提供服务。就比如寄信，写信双方只需要关注信件内容，快递员只需要关注如何把信件送达。但是快递员的工作又是为写信双方提供服务的。
所以做ping测试的时候，如果存在丢包延时，那肯定会影响数据的传输访问，因为ping测试是基于ICMP协议的，ICMP协议是 络层的协议。 络层出现问题，会影响上层。
是不是ping测试不丢包不延时，那访问就一定没问题呢。也不是，因为 络层上面还有传输层及应用层，也可能是传输层或应用层的问题。所以有时候客户说，“你看没有丢包延时啊，咋访问卡呢，这是咋回事啊小老弟？”，你现在应该能够解释了。
3.我们先来打开第一个抓包文件看看。即fenzhieth0，通过过滤条件，先过滤出我们先要的内容。
4.过滤完之后，可以查看丢包与重传。因为我们可以看到，使用ERP软件，传输层是用的TCP协议。如果传输层存在一定比例的丢包与重传就会影响性能。我们在主界面看到，过滤条件搜索之后的数据包展示了4157个，再点开专家信息。
5.在专家信息中，勾选只展示过滤条件搜索后的信息。可以看到重传的数据包个数。重传将近千分之五，可能会影响性能，毕竟是在公 上传输了数据。
6.我们再打开会话信息。
7.从会话信息中，我们可以看到传输数据的过程中建立了49个连接。
8.我们挑选其中一个数据传输比较多的连接。比如上图中的第三个连接，发送了815KB的数据，然后右键过滤出来。
9.此时的过滤条件会自动给你填写好显示出来。
10.再次查看该连接下，按上述方法看专家信息，其实该连接下是一个重传都没有的。接下来，我们点击一个从服务器发往客户端的包，再来看TCP流图中的Stevens时序流图，统计statistics—>TCP Stream Graphs—>time sequence （stevens）。
11.展示了如下界面，可以看到，服务器发往客户端的数据，seq 在一段时间内突然就卡住了。一直没有变化增长。我们要知道的是，tcp中的seq 用来表示一个tcp段，len表示他的长度。比如一个tcp段，他的seq 是0，长度len是2，那么下一个tcp段的seq 就是（0+2）2。这张图中，seq 连续增长就说明服务器就在一直发送数据。如果seq 在一段时间内一直保持一致，说明就没有发送数据了。
12.也就说明问题很可能就出在这块了。这段时间为什么服务器突然就停住了。
13.点击Stevens图中的卡住的点，你就能找到对应的数据包，分别是467 包和819 包。
14.此时一看上图，467 包到819 包之间的内容，就可以发现问题了。819 包在等816 包发出，而816 包发出的时候，距离468 包发出足足等了近6s。也就是说服务器再等客户端发送一个数据包，但是这个数据包不知道为何突然等了近6s才发出，才导致服务器给客户端传输的时候，seq 在一段时间内上不去。
15.而后续又看了几个连接的情况都是一模一样的。也就说明，访问卡慢是由客户端引起的，不知为何客户端会突然停止发包。
16.因为看的是分支设备eth0口抓的包，所以数据包是从内 传到设备eth0口的，可以确定的是和我们的vpn设备没有任何关系了，剩下的问题可以让ERP的工程师去排查。
更多资讯可搜索希赛 点击软考频道，或直接关注软考之家：ruankao_home。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！