先来说TCP 下载速度为什么这么慢?一文的答案:是因为接收端窗口太小。
这是一个典型「长肥管道」的问题。长,是说这个 TCP 连接的延迟很大,距离很长;肥,是说这个 TCP 连接的传输内容很多,尝试使用最大吞吐来传输内容,管道很粗,是肥。长肥管道的性能分析方法就是提示里面的《用 Wireshark 分析 TCP 吞吐瓶颈》介绍的,用此方法可以初步定位出来大部分的问题。
使用文中的方法打开 tcptrace 图,我们会看到这是一个典型的受接收端窗口限制的问题。
如果切换到 window scaling 图,会看到发送中的数据已经是和 window size 一样了。
在这个问题中,我还加入了几个丢包。但是传输受到接收端的影响太大,丢包造成的影响倒是可以忽略不计了。如果把接收端的窗口扩大到很大,吞吐就会受到丢包的影响。(一般来说,如果丢包率到了千分之一,TCP 吞吐就会下降的很严重)。
类似问题另一个可以关注的地方是 TCP 的专家信息,Wireshark 会帮你分析接收端的窗口大小,如果接收端说自己的接收窗口已经是 0 了,请不要再继续发送了,我们可以在 Wireshark 中看到类似的提示。
其实我这次的抓包也有这些信息,只是为了不让这个问题太简单,我把所有的包接收端窗口改成最小为 1 了,所以读者没有看到这个提示,嘻嘻。
今年 Netflix 技术博客发布了一篇 debug 文章:Investigation of a Cross-regional Network Performance Issue。文中因为一个超时问题,最终定位到内核代码变更,导致接收端窗口大小不正确,影响了性能。我想说的是,原文在排查问题的时候,去看最近有哪些变更,定位到了内核问题。如果使用本文介绍的方法,排查思路是:请求超时 > 抓包确认 TCP 传输时间 > tcptrace 分析长肥管道传输性能问题 > 定位到接收端的窗口大小问题。这个思路按图索骥,更加 solid.
==计算机网络实用技术 目录==
这篇文章是计算机网络实用技术系列文章中的一篇,这个系列正在连载中,我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题,经过精心构造和编写,每个文件附带抓包文件,通过实战来学习网路分析。
如果本文对您有帮助,欢迎扫博客右侧二维码打赏支持,正是订阅者的支持,让我公开写这个系列成为可能,感谢!
没有链接的目录还没有写完,敬请期待……
- 序章
- 抓包技术以及技巧
- 理解网络的分层模型
- 数据是如何路由的
- 网络问题排查的思路和技巧
- 不可以用路由器?
- 网工闯了什么祸?
- 网络中的环路和防环技术
- 延迟增加了多少?
- TCP 延迟分析
- 重新认识 TCP 的握手和挥手
- 重新认识 TCP 的握手和挥手:答案和解析
- TCP 下载速度为什么这么慢?
- TCP 长肥管道性能分析
- 后记:学习网络的一点经验分享
与本博客的其他页面不同,本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。
原文里的pcap报文打开之后tcptrace结果跟你文章里的图不一样啊,是不是传错pcap文件了?
是不是不因为我贴的是放大图原因?这个图是可以放大看的。
不知道是不是我打开的姿势不对?我这边打开看第13-14s左右,对应的Y轴seq number只有100左右
我知道了,你看的是第 0 个 stream,这个抓包文件中有两个 tcp 连接,(iperf3工具产生的),stream 0 是控制连接,stream 1 才是真正发送数据的。
注意看右下角的 Stream
确实是。学到了。多谢!
很想学习一下如何用iperf3制造出接收端窗口为 1的tcp流
这倒不是很好做,因为 tcp 是 Linux Kernel 控制的,Kernel 实现会顶慢 rwnd(在 rwnd 这么小的情况下)。所以…… 我是抓包之后修改 pcap 文件的。
使用 scapy 打开 pcap 文件,然后 match 接收端的包,把 widow size + 1 就可以了。
棒!