Wireshark抓包分析解决TCP滑动窗口机制问题

文章来源：https://m.toutiaocdn.com/item/6696278587143619079/?app=news_article×tamp=1564133671&req_id=20190726173430010027041153996E729&group_id=6696278587143619079

某天接到一线工程师反馈，用户在登录和使用某台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内核）等国产的软件。

                                            Server C抓包

                                               Server  B 抓包

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次:

                                                            Server B 用户认证

                                                            Server  C用户认证

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

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

                                                Window  Scale

2 Server在SYN+ACK同理如上：

                                      Server B Window Scale

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

                                         ACK window scale