客户反馈卡顿时查看vmp平台上虚拟机的内存，cpu，磁盘均为正常且vmp后台操作没有卡顿现象，初步判断为网络延迟导致的卡顿

且客户查看云桌面状态栏会显示网络延迟大或者断开

客户的桌面云部署在私网中，客户端通过可信认证代理访问私网桌面云虚拟机

数据流为PC首先和防火墙x.x.46.142交互，防火墙再转发至后端云桌面服务器，本次抓包关注客户端与防火墙交互阶段 

使用ping x.x.46.142测试，测试结果都在3ms左右，但是云桌面服务是基于tcp的，故使用tcping工具来测试端口连通性以及网络延迟会更可靠

tcpping使用方法：https://www.jianshu.com/p/c246fa819d4f

根据图可见，在云桌面网络状态显示延迟时，icmp并不会有波动，但是tcping已经出现了延迟。

为了查清楚网络延迟在哪一端 在pc端（x.x.250.49）和防火墙端（x.x.56.142）侧抓包查看

选取延迟最高的几个报文 通过过滤ip.id来查看对应报文，可以看到pc端延迟为1500ms以上时，相同的包在防火墙侧的延迟仅为1ms左右，由此可判断从服务器回应到防火墙发出时，报文并没有延迟。但是客户端接受到这个报文时，已经过了1700ns，可推断防火墙到客户端的中间网络，报文产生了延迟。

• 为了证实云桌面的延迟出现在防火墙测（防火墙回包回慢了）还是延迟在网络中间（网络导致的包延迟），所以在客户端（x.x.240.49）和启明星辰防火墙（x.x.56.142）上面同时开启抓包，并且对比两份报文的延迟，重点关注rtt参数，The RTT to ACK the segment指的是从发送数据段到接收到确认应答(ACK)所经过的往返时间(Round-Trip Time)。这个时间包括数据段从发送端发送到接收端接收的时间，以及接收端发送ACK确认的时间。在网络通信中，RTT to ACK the segment是一个重要的性能指标，它可以影响数据传输的速度和稳定性。通常情况下，RTT越短，数据传输的速度就越快。
• 

 只有ack报文才有rtt参数，对比两端报文的rtt参数差异，即可得出延迟发生在哪一段。

• 上面的图片为pc端的报文，下面的图片为启明防火墙上抓取的报文，两份报文为同时抓取。通过对比RTT值（客户端报文的rtt值大于防火墙报文的rtt值， 客户端rtt为2s，防火墙的rtt为0.04），可判断延迟发生在防火墙和客户端中间，为中间网络造成的延迟。
• 

• 再随机过滤一个IP.id的报文

• 

• 可看到在两份报文中，同一个包的rtt有明显差距，客户端报文的RTT时间为1.5s意味着从客户端发送数据包到收到服务器端的确认应答总共花费了1500ms的时间，这是一个相当长的延迟。而防护墙侧抓取的报文时间在5ms之内，则表明在防火墙侧到云桌面服务器处理时间很短，防火墙从收到请求到发出ack应答报文的时间为5ms，而客户端收到这个ack报文的时间却花了1500ms，这其中相差的时间都花费在了数据包在网络中传输的处理上。
  因此可得出结论：云桌面卡顿为防火墙与客户端的中间网络延迟导致

推断为防火墙与客户端的中间网络延迟导致的故障