不要只看延迟：线路好不好，尤其是长连接，远不止 RTT 一个指标
以前折腾 VPS 和线路的时候，我发现大家很容易把注意力放在一个指标上：延迟。比如：这个节点到北京 150ms，那个节点 190ms。那当然是 150ms 的线路更好。我不是说延迟不重要，也不是鄙视和炫耀。但是我自学《计算机网络：自顶向下方法》后发现、重新思考和总结了一下。
对于 SSH、网页访问这种交互场景，这样看问题并没有什么大错。因为 TCP 包头等体积很小，往往等不到 TCP 拥塞窗口扩大后就发送完毕。但最近我自己用 Rclone 做大批量备份到德国 Hetzner Storage Box，遇到了一个挺有意思的现象：多加了这台圣何塞 VPS，反而更快。
我的路径原本大概是：
电脑 → 代理圣何塞 → Hetzner 德国
后来改成：
电脑 → 代理圣何塞 → GreenCloud 圣何塞 → Hetzner 德国
按直觉，多绕一台机器似乎应该更慢。但实际做了几次几十 GB 的备份以后，后者反而几乎每次都是更快。这时候再回头看，就会发现：“延迟低”与“长时间传输吞吐高”本来就是两个不同的问题。
对于一个持续几十分钟甚至几个小时的 TCP 长连接，真正影响最终吞吐量的东西还有很多，例如：
- 丢包率
- TCP 拥塞窗口（cwnd）
- 重传
- 拥塞控制状态
- 链路本身的稳定性和抖动
- 上游 Transit
- 运营商之间的 Peering
- 具体的路由选择以及链路拥塞情况
RTT 当然重要，但它并不能单独决定最终速度。例如一条跨洲线路 RTT 是 150ms，看起来很高，但只要路径稳定、丢包很低，TCP 建立起足够大的拥塞窗口以后，依然可以维持很不错的吞吐。反过来，一条 RTT 更低的线路，如果中间存在拥塞、丢包或者互联质量不好，TCP 拥塞窗口不断受到影响，实际速度反而可能更差。
所以对于我这种：
几十 GB 的文件 ↓ SFTP ↓ rclone ↓ 持续数小时
这种典型的长连接、大流量传输场景，我现在会更关注：这条路径能不能让 TCP 长时间稳定地跑起来，而不只是 ping 看起来好不好看。这也是为什么我后来测试线路时，不再只看 ping 的平均 RTT，而会继续看 MTR、丢包、抖动、实际吞吐，以及具体的上游和路由。
拿我这次的路径来说，GreenCloud 圣何塞到 Hetzner 德国的测试大约是：
San Jose → Frankfurt → Hetzner RTT ≈ 152 ms 最终目标丢包 = 0% 抖动 ≈ 0.8 ms
单看 152ms，其实并没有什么特别神奇的地方。
但如果这条路径能够长期保持稳定，而另一条“看起来更直接”的路径在欧洲方向存在拥塞或互联问题，那么实际的大文件传输速度完全可能反过来。
所以现在我自己的经验是：测线路，不要只看延迟。尤其是准备拿 VPS 做 备份、SFTP、rclone、下载、上传、流媒体或者其他长期保持的 TCP 连接时，单独比较一个 ping 数字，很可能不足以说明实际体验。
当然，这并不是说 RTT 不重要。对于交互式应用、连接建立、请求响应以及 TCP 的带宽时延积等问题，RTT 依然非常重要（通俗来说是小的、即刻发送成功的网络包）。只是对于长时间稳定传输来说，RTT 只是其中一个变量。
有时候真正决定“这条线路到底好不好用”的，反而是那个测速页面上最不起眼的东西：丢不丢包、稳不稳定，以及你的 TCP 能不能一直把窗口撑起来。
还是觉得，有必要重温经典，从经典中来，又回到经典。
大家也不要只看我的博客，我也是个人愚见。 还是要经典常备手边，随时翻阅。经常我们的问题就在那里，静静地回答了。
现在人工智能能一瞬间生成注释完善、变量清晰的代码，但是这只是人类已有知识的拼接总结；无法知道为什么现实里要妥协很多问题，TCP 就是工程落地、妥协协调各个方面的需求，终成一代协议典范，至今仍生生不息。
评论
发表评论