先来说TCP 下载速度为什么这么慢？一文的答案：是因为接收端窗口太小。
这是一个典型「长肥管道」的问题。长，是说这个 TCP 连接的延迟很大，距离很长；肥，是说这个 TCP 连接的传输内容很多，尝试使用最大吞吐来传输内容，管道很粗，是肥。长肥管道的性能分析方法就是提示里面的《用 Wireshark 分析 TCP 吞吐瓶颈》介绍的，用此方法可以初步定位出来大部分的问题。
使用文中的方法打开 tcptrace 图，我们会看到这是一个典型的受接收端窗口限制的问题。（注意，在给出的抓包文件中，实际上有两个 TCP flow，flow 是「一个 TCP 连接」的意思，也就是一个 TCP 四元组。Stream 0 是 iperf 用来做控制信息的，Stream 1 才是真正传输数据的。在实际的抓包分析中，能够正确地找到需要分析的 flow 也很重要。在这个例子中，可以通过传输数据的多少来判断。）
如果切换到 window scaling 图，会看到发送中的数据已经是和 window size 一样了。
在这个问题中，我还加入了几个丢包。但是传输受到接收端的影响太大，丢包造成的影响倒是可以忽略不计了。如果把接收端的窗口扩大到很大，吞吐就会受到丢包的影响。（一般来说，如果丢包率到了千分之一，TCP 吞吐就会下降的很严重）。
类似问题另一个可以关注的地方是 TCP 的专家信息，Wireshark 会帮你分析接收端的窗口大小，如果接收端说自己的接收窗口已经是 0 了，请不要再继续发送了，我们可以在 Wireshark 中看到类似的提示。
其实我这次的抓包也有这些信息，只是为了不让这个问题太简单，我把所有的包接收端窗口改成最小为 1 了，所以读者没有看到这个提示，嘻嘻。
今年 Netflix 技术博客发布了一篇 debug 文章：Investigation of a Cross-regional Network Performance Issue。文中因为一个超时问题，最终定位到内核代码变更，导致接收端窗口大小不正确，影响了性能。我想说的是，原文在排查问题的时候，去看最近有哪些变更，定位到了内核问题。如果使用本文介绍的方法，排查思路是：请求超时 > 抓包确认 TCP 传输时间 > tcptrace 分析长肥管道传输性能问题 > 定位到接收端的窗口大小问题。这个思路按图索骥，更加 solid.
==计算机网络实用技术 目录==
这篇文章是计算机网络实用技术系列文章中的一篇，这个系列正在连载中，我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题，经过精心构造和编写，每个文件附带抓包文件，通过实战来学习网路分析。
如果本文对您有帮助，欢迎扫博客右侧二维码打赏支持，正是订阅者的支持，让我公开写这个系列成为可能，感谢！
没有链接的目录还没有写完，敬请期待……
- 序章
- 抓包技术以及技巧
- 理解网络的分层模型
- 数据是如何路由的
- 网络问题排查的思路和技巧
- 不可以用路由器？
- 网工闯了什么祸？
- 网络中的环路和防环技术
- 延迟增加了多少？
- TCP 延迟分析
- 压测的时候 QPS 为什么上不去？
- 压测的时候 QPS 为什么上不去？答案和解析
- 重新认识 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 就可以了。
棒！
汗 选对了tcp连接 没看出蓝色的线。意思差不多看明白了 绿色的rwnd得相对其他两条线飘起来，接收端就没问题了。
是的，正常情况是这样。