安基网 首页 系统 网络学院 查看内容

wireshark及抓包分析助力网络工程师甩锅、TCP滑动窗口机制

2020-3-24 15:46| 投稿: xiaotiger |来自: 互联网


免责声明:本站系公益性非盈利IT技术普及网,本文由投稿者转载自互联网的公开文章,文末均已注明出处,其内容和图片版权归原网站或作者所有,文中所述不代表本站观点,若有无意侵权或转载不当之处请从网站右下角联系我们处理,谢谢合作!

摘要: 某天接到一线工程师反馈,用户在登录和使用某台server的远程桌面过程中延迟非常大,而连接其他的server正常。一线工程师已经做了以下尝试:1 使用client去ping server,没有丢包,返回延迟比较小;2 更换server至交换机的物理链路;3 更换上行交换机;一线工程师怀疑是server端的问题,但无法证明自己 ...

某天接到一线工程师反馈,用户在登录和使用某台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左右,印证了网络质量没有问题。

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访问缓慢故障解决。

以下简单介绍本次用到的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倍:

window scale

2 Server在SYN+ACK同理如上:

serverB window scale

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

ACK window scale

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



小编推荐:欲学习电脑技术、系统维护、网络管理、编程开发和安全攻防等高端IT技术,请 点击这里 注册账号,公开课频道价值万元IT培训教程免费学,让您少走弯路、事半功倍,好工作升职加薪!

本文出自:https://www.toutiao.com/a6694530596992975364/

免责声明:本站系公益性非盈利IT技术普及网,本文由投稿者转载自互联网的公开文章,文末均已注明出处,其内容和图片版权归原网站或作者所有,文中所述不代表本站观点,若有无意侵权或转载不当之处请从网站右下角联系我们处理,谢谢合作!


鲜花

握手

雷人

路过

鸡蛋

相关阅读

最新评论

 最新
返回顶部