开发者社区> 异步社区> 正文

《Wireshark网络分析的艺术》—一篇关于VMware的文章

简介:
+关注继续查看

本节书摘来自异步社区《Wireshark网络分析的艺术》一书中的一篇关于VMware的文章,作者林沛满,更多章节内容可以访问云栖社区“异步社区”公众号查看。

一篇关于VMware的文章
Wireshark网络分析的艺术
有位读者在VMware的知识库里找到一篇文章,觉得很像他正在遭遇的一个性能问题,便转发给我确认。作为好为人师的技术员,我当然不能让读者失望。

这篇文章大概讲了这样一件事。

问题描述
某些iSCSI存储阵列在出现网络拥塞时处理不当,会严重影响VMware的读写性能。这和它们的TCP实现方式有关。

解决方式
在VMware和存储阵列上关闭延迟确认(Delayed ACK)

VMware和iSCSI存储阵列是什么?我在知识库里找到一个网络拓扑,看起来很简单,大概如图1所示。我们无需理解得很深,只要把iSCSI存储阵列当作一台服务器,再把VMware当作其客户端就行了,两者通过以太网传输数据。


5c409c8ea581fe5db10ec06f98a3c2ca8bdaa638

乍一看,这个“问题描述”与“解决方式”简直风马牛不相及。网络拥塞怎么能靠关闭延迟确认来解决?不过出于对VMware的一贯信任,我决定还是好好研究一下。

我们先要明白什么叫延迟确认,它可以用一个简单的例子来说明:在上海的笔记本上启动Wireshark抓包,然后用Putty远程登录一台位于悉尼的服务器。由图2可见,在上海发出一个SSH请求之后,经过149毫秒左右(即1号包和2号包之间的时间差)收到了悉尼的回复,这是正常的往返时间。但是笔记本收到回复之后,却没有立即确认,而是延迟了200毫秒以上(即2号包和3号包之间的时间差)才确认。


b7f34d7f1a07bd3ef42c236ab857a0af571ba868

这个现象就是传说中的延迟确认,我在上一本书中也介绍过。为了让大家更好地理解它,我们再做个对比实验:我在笔记本上关闭了延迟确认,然后再次连接悉尼的服务器。从图3可见2号包和3号包之间几乎没有时间差了(只有0.000121秒,可以忽略)。

25419f9b33cea93b463fa6bec72c2a740bb1c3b7

启用延迟确认是有好处的,假如在这等待的200毫秒里,上海的笔记本恰好有数据要发,就可以在发数据时捎带确认信息,省去了一个纯粹的确认包。图4就符合这种情况。笔记本收到11号包之后,等了41毫秒左右(即11号包和12号包之间的时间差)恰好又有一个SSH请求要发,就顺便把确认捎带过去了,因此省掉了一个纯粹的确认包。之所以有很多TCP协议栈默认启用延迟确认,正是基于这个原因——少一些确认包可以节省带宽嘛。

bcd8eb24e011664ca717a8bc1a7e6ac2aa01d403

延迟确认的坏处也很明显,就是会凭空多出一段延迟。这个机制的作用很像你中午懒得去食堂吃饭,便等到下午出门上课时顺便去吃一点。结果就是少跑了一趟食堂,但是吃饭时间却被延后了。

理解了延迟确认的原理,我们再回顾VMware的那篇文章。一般来说,偶尔浪费200毫秒的等待时间并不算严重的问题,VMware为什么要这么在意呢?又不是等待很多个200毫秒。当我联想到“很多个”时,终于明白了——这世界上还真的存在一种很老的TCP的实现(RFC 2582),会导致拥塞时出现多个200毫秒的等待时间。详情且看下文分析。

图5从客户端的视角演示了启用延迟确认时,某些TCP协议栈在处理网络拥塞时的状况。


a53d8ab53d076a2c21a7c7a2c5edb1e891b00706

这个传输过程发生了以下事件。

1.客户端在同一时刻(或者说同一窗口)发送了9个TCP包,其中3、4、5号因为拥塞丢失了。

2.到达服务器的6、7、8、9号包触发了4个“Ack 3”,于是客户端快速重传3号包,此时它并不知道4号包也丢了。

3.由于服务器上启用了延迟确认,所以它收到3号包之后,等待了200毫秒才回复Ack 4。

4.客户端重传4号包,然后服务器又等待了200毫秒才回复Ack 5。

5.客户端重传5号包,然后服务器又等待了200毫秒才回复Ack 10。

6.客户端传输新的10号包,自此该网络拥塞就完全恢复了。

由于当时没有抓包,因此以上分析仅是我的推测。还有另一种可能是在某个200毫秒的延迟过程中,那些丢包的RTO(Retransmission Timeout)已经被触发,所以进入了超时重传阶段。无论符合哪一种可能,性能都会严重下降,因此VMware建议关闭延迟确认是很有道理的,只不过没把原理说清楚。我甚至怀疑写这篇文章的人也没真正理解,因为里面还提到了慢启动之类不太相关的东西。

假如把延迟确认关闭掉,那该TCP协议栈处理拥塞的过程就变成图6所示。包还是那些包,不过浪费在延迟确认上的600毫秒就省下来了。只要往返时间不是太长,那些丢包也不会触发超时重传,所以避免了第二种可能。


e8fabe9e278ec9b311a466895f2ebf4250827604

我把分析结果告诉了那位读者,确保这个修改没什么副作用。于是他壮着胆子关闭了延迟确认,果然VMware的性能就飙升了。图7是他在关闭之后抓的网络包,和上文分析的一模一样,果然连续丢了很多包,而且每个重传都需要确认一次。

9c7b07e6cf66437eb0a3cbfe7c9c88ae76d718ef

我以前分享的案例都是先在Wireshark中找到症状,然后再结合协议分析找到原因的。而这次纯粹是依靠协议分析,预测能从包里看到什么,然后再用Wireshark验证的。听起来似乎是完全靠灵感,但灵感不是天生的,它来自长期的训练。只有在Wireshark中看过了延迟确认和大量重传的样子,才可能意识到它们放在一起会出大问题。

注意:
如果对那篇VMware的文章感兴趣,可以在其知识库http://kb.vmware.com中搜索1002598来找到它。
本文仅用于学习和交流目的,不代表异步社区观点。非商业转载请注明作译者、出处,并保留本文的原始链接。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Wireshark抓包分析/TCP/Http/Https及代理IP的识别
前言   坦白讲,没想好怎样的开头。辗转三年过去了。一切已经变化了许多,一切似乎从没有改变。   前段时间调研了一次代理相关的知识,简单整理一下分享之。如有错误,欢迎指正。 涉及 Proxy IP应用 原理/层级wireshark抓包分析 HTTP head: X-Forwarded-For/ Proxy-Connection/伪造  X-Forwarded-For/ 以及常见的识别手段等几个方面。
2017 0
MongoDB · 特性分析 · Sharded cluster架构原理
为什么需要Sharded cluster? MongoDB目前3大核心优势:『灵活模式』+ 『高可用性』 + 『可扩展性』,通过json文档来实现灵活模式,通过复制集来保证高可用,通过Sharded cluster来保证可扩展性。 当MongoDB复制集遇到下面的业务场景时,你就需要考虑使用Sh
2707 0
+关注
异步社区
异步社区(www.epubit.com)是人民邮电出版社旗下IT专业图书旗舰社区,也是国内领先的IT专业图书社区,致力于优质学习内容的出版和分享,实现了纸书电子书的同步上架,于2015年8月上线运营。公众号【异步图书】,每日赠送异步新书。
12049
文章
0
问答
文章排行榜
最热
最新