某天接到一线工程师反馈,用户在登录和使用某台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内核)等国产的软件。
ServerC抓包
serverB抓包
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次:
ServerB用户认证
ServerC用户认证
问题反馈给系统工程师,通过修改相应的参数,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同理如上:
serverB window scale
3 Ack,Client端最终协商出滑动窗口:2053*256=525568远大于本次故障的64420;
ACK window scale
如大家对抓包并使用wireshark或者科来分析故障,可留言关注,分享更多案例和技巧。