不要只看延迟:线路好不好,尤其是长连接,远不止 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,而会继续看 M...