TCP 长肥管道性能分析

先来说TCP 下载速度为什么这么慢?一文的答案:是因为接收端窗口太小。

这是一个典型「长肥管道」的问题。长,是说这个 TCP 连接的延迟很大,距离很长;肥,是说这个 TCP 连接的传输内容很多,尝试使用最大吞吐来传输内容,管道很粗,是肥。长肥管道的性能分析方法就是提示里面的《用 Wireshark 分析 TCP 吞吐瓶颈》介绍的,用此方法可以初步定位出来大部分的问题。

使用文中的方法打开 tcptrace 图,我们会看到这是一个典型的受接收端窗口限制的问题。

蓝色的线每次发送都受到绿色的线限制,即受到接收端窗口的影响

如果切换到 window scaling 图,会看到发送中的数据已经是和 window size 一样了。

window scaling 图

在这个问题中,我还加入了几个丢包。但是传输受到接收端的影响太大,丢包造成的影响倒是可以忽略不计了。如果把接收端的窗口扩大到很大,吞吐就会受到丢包的影响。(一般来说,如果丢包率到了千分之一,TCP 吞吐就会下降的很严重)。

类似问题另一个可以关注的地方是 TCP 的专家信息,Wireshark 会帮你分析接收端的窗口大小,如果接收端说自己的接收窗口已经是 0 了,请不要再继续发送了,我们可以在 Wireshark 中看到类似的提示。

Wireshark TCP 接收端窗口已满

其实我这次的抓包也有这些信息,只是为了不让这个问题太简单,我把所有的包接收端窗口改成最小为 1 了,所以读者没有看到这个提示,嘻嘻。

今年 Netflix 技术博客发布了一篇 debug 文章:Investigation of a Cross-regional Network Performance Issue。文中因为一个超时问题,最终定位到内核代码变更,导致接收端窗口大小不正确,影响了性能。我想说的是,原文在排查问题的时候,去看最近有哪些变更,定位到了内核问题。如果使用本文介绍的方法,排查思路是:请求超时 > 抓包确认 TCP 传输时间 > tcptrace 分析长肥管道传输性能问题 > 定位到接收端的窗口大小问题。这个思路按图索骥,更加 solid.

==计算机网络实用技术 目录==

这篇文章是计算机网络实用技术系列文章中的一篇,这个系列正在连载中,我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题,经过精心构造和编写,每个文件附带抓包文件,通过实战来学习网路分析。

如果本文对您有帮助,欢迎扫博客右侧二维码打赏支持,正是订阅者的支持,让我公开写这个系列成为可能,感谢!

没有链接的目录还没有写完,敬请期待……

  1. 序章
  2. 抓包技术以及技巧
  3. 理解网络的分层模型
  4. 数据是如何路由的
  5. 网络问题排查的思路和技巧
  6. 不可以用路由器?
  7. 网工闯了什么祸?
  8. 网络中的环路和防环技术
  9. 延迟增加了多少?
  10. TCP 延迟分析
  11. 重新认识 TCP 的握手和挥手
  12. 重新认识 TCP 的握手和挥手:答案和解析
  13. TCP 下载速度为什么这么慢?
  14. TCP 长肥管道性能分析
  15. 后记:学习网络的一点经验分享
与本博客的其他页面不同,本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。


TCP 长肥管道性能分析”已经有8条评论

  1. 原文里的pcap报文打开之后tcptrace结果跟你文章里的图不一样啊,是不是传错pcap文件了?

      • 不知道是不是我打开的姿势不对?我这边打开看第13-14s左右,对应的Y轴seq number只有100左右

        • 我知道了,你看的是第 0 个 stream,这个抓包文件中有两个 tcp 连接,(iperf3工具产生的),stream 0 是控制连接,stream 1 才是真正发送数据的。

          注意看右下角的 Stream

          • 这倒不是很好做,因为 tcp 是 Linux Kernel 控制的,Kernel 实现会顶慢 rwnd(在 rwnd 这么小的情况下)。所以…… 我是抓包之后修改 pcap 文件的。

            使用 scapy 打开 pcap 文件,然后 match 接收端的包,把 widow size + 1 就可以了。

Leave a comment

您的电子邮箱地址不会被公开。 必填项已用 * 标注