某天接到一线工程师反馈，用户在登录和使用某台server的远程桌面过程中延迟非常大，而连接其他的server正常。一线工程师已经做了以下尝试：

1 使用client去ping server，没有丢包，返回延迟比较小；

2 更换server至交换机的物理链路；

3 更换上行交换机；

一线工程师怀疑是server端的问题，但无法证明自己的推测，陷入了"我"为什么是"我"的死锁，甩锅也是需要强力证据来支撑的。一切展示给我们的故障现象，一定都隐藏在底层的错误积累。

一线工程师在Client端的汇聚交换机做了端口镜像，从Client端（A：172.16.26.107）分别mstsc正常Server（B：172.16.4.26）和非正常Server（C：172.16.0.105），并使用wireshark抓包。

说到wireshark说段有趣的事，wireshark的开发者在分析和排查网络的故障的时候，最初使用sniffer，后来sniffer收费了，换成我们可能第一反应是去"破解"，但是开发者有版权意识：）自己开发并开源至今，当然如果对于英文不好，可以使用科来（基于wireshark内核）等国产的软件。

分析：1 SYN ---SYN,ACK---ACK，通过time的时间戳能看的出响应时间都很短，在0.001S左右，印证了网络质量没有问题。

2 在SYN，ACK时，C并没有携带WS（windows scale），导致在三次握手协商后,滑动窗口为分别为：64240，525568（Calculated windows size = windows size *Window size scaling factor）。其实到这里基本可以判断出故障的原因了：C由于没有开启Window scale，导致tcp协商时无法自动调节CWS，导致在交互过程中需要大量的ACK，影响了整体相应时间。我们对比以下用户认证的过程也可以看得出，B只需要3次交互，而C需要6次:

问题反馈给系统工程师，通过修改相应的参数，msrdp访问缓慢故障解决。

以下简单介绍本次用到的tcp三次握手中的几个参数：

1 TCP ACK的时候默认最大64240，我们姑且不扣除ip和tcp头部的20+20开销，那么这个值应该是65535=2^16，也就是每个窗口16bit，最大64k的速度，但由于现在网络带宽的大幅提升不足以支撑目前的需求，因此设计了options位的window scale来放大，由TCP发起端携带，如果发起端未携带，则被请求段不会携带该option位，本次是8=2^3，2^8=256倍：

2 Server在SYN+ACK同理如上：

3 Ack，Client端最终协商出滑动窗口：2053*256=525568远大于本次故障的64420；

如大家对抓包并使用wireshark或者科来分析故障，可留言关注，分享更多案例和技巧。