4. TCP Tahoe 与 Reno：算法演进、优缺点对比、适用场景
说到拥塞控制，TCP Tahoe 和 Reno 是绕不开的两个经典算法。我刚开始做流媒体传输优化时，第一个深入研究的拥塞控制算法就是 Tahoe。说实话，那时候觉得它挺聪明的，后来才发现它有个让人头疼的毛病——太「激进」了。
Reno 的出现，说白了就是给 Tahoe 打了个补丁。但就是这个补丁，让 TCP 拥塞控制进入了一个新阶段。今天咱们就好好聊聊这两个算法，看看它们到底差在哪，各自适合什么场景。
4.1 TCP Tahoe：拥塞控制的「开山之作」
Tahoe 是 1988 年由 Van Jacobson 提出的。它的核心思想很简单：没丢包就加速，丢包了就减速。嗯，听起来很直觉对吧？
它主要包含三个机制：
- 慢启动（Slow Start）：连接刚建立时，cwnd 从 1 开始，每收到一个 ACK 就翻倍。指数增长，直到达到 ssthresh。
- 拥塞避免（Congestion Avoidance）：进入线性增长阶段，每个 RTT 只增加 1 个 MSS。
- 快速重传（Fast Retransmit）：收到 3 个重复 ACK 时，不等超时，直接重传丢失的包。
但 Tahoe 有个关键问题：一旦检测到丢包，它就把 cwnd 直接降到 1，然后重新慢启动。我在项目中遇到过这种情况——一个短暂的网络抖动，Tahoe 就把吞吐量打回原形，恢复起来特别慢。
Tahoe 的丢包响应流程：
- 收到 3 个重复 ACK 或超时
- ssthresh = cwnd / 2
- cwnd = 1
- 重新进入慢启动
你想想看，如果 cwnd 已经涨到 100 了，突然降到 1，这得损失多少带宽？这就是 Tahoe 最被诟病的地方——反应过度。
4.2 TCP Reno：给 Tahoe 打了一个关键补丁
Reno 在 1990 年出现，它保留了 Tahoe 的所有机制，只改了一个地方：快速恢复（Fast Recovery）。
Reno 的思路是：既然收到了重复 ACK，说明网络还能正常工作，只是丢了一个包而已。没必要从头开始，半速运行就够了。
Reno 的快速恢复逻辑：
- 收到 3 个重复 ACK → ssthresh = cwnd / 2
- cwnd = ssthresh + 3（因为已经收到的 3 个重复 ACK 代表有 3 个包离开了网络）
- 每收到一个重复 ACK，cwnd += 1
- 收到新 ACK 时，cwnd = ssthresh，进入拥塞避免
说白了，Reno 把「归零重启」改成了「半速继续」。这个改动看似不大，但在实际网络中效果非常明显。我记得有一次做跨国传输优化，用 Tahoe 时带宽利用率只有 30% 左右，换成 Reno 后直接提升到了 60%。
4.3 核心差异对比
咱们用一张表来直观对比一下：
| 对比维度 | Tahoe | Reno |
|---|---|---|
| 丢包响应 | cwnd 直接降到 1 | cwnd 降到 ssthresh |
| 恢复速度 | 慢（需要重新慢启动） | 快（直接进入拥塞避免） |
| 带宽利用率 | 低，尤其在高延迟链路 | 较高 |
| 公平性 | 较好 | 较好 |
| 实现复杂度 | 简单 | 稍复杂（多了快速恢复状态机） |
| 对单包丢失 | 过度反应 | 合理处理 |
| 对多包丢失 | 表现一般 | 表现较差（Reno 的致命弱点） |
这里我要特别强调一下：Reno 在处理单包丢失时表现很好，但一旦出现多包丢失（比如一个窗口内丢了多个包），它就抓瞎了。为什么会这样？因为 Reno 的快速恢复只能处理一个丢包，第二个丢包会导致它再次进入快速恢复，甚至超时重传。
避坑指南：我曾经在一个无线网络项目中吃过这个亏。无线链路的突发丢包率比较高，Reno 频繁进入快速恢复，结果吞吐量还不如 Tahoe。后来我们换用了 NewReno 才解决问题。所以如果你的网络环境丢包率超过 1%，Reno 可能不是最佳选择。
4.4 适用场景分析
说了这么多，到底什么时候用 Tahoe，什么时候用 Reno？我个人的经验是这样的：
Tahoe 适合的场景
- 低延迟、低丢包的网络：比如数据中心内部网络，丢包极少，Tahoe 的激进恢复影响不大
- 对公平性要求极高的场景：Tahoe 的 AIMD 特性非常公平，多个流之间能很好地共享带宽
- 教学和实验环境：Tahoe 实现简单，适合用来理解拥塞控制的基本原理
Reno 适合的场景
- 互联网通用场景：Reno 是 90 年代到 2000 年代初的默认 TCP 实现，适合大多数有线网络
- 高延迟链路：比如跨洋传输，Reno 的快速恢复能显著提升带宽利用率
- 单包丢失为主的网络：比如光纤网络，丢包通常是随机单包丢失
4.5 算法演进流程图
下面这张图展示了 Tahoe 和 Reno 在丢包处理上的核心差异：
4.6 实际项目中的选择建议
如果你现在要做一个流媒体传输系统，该怎么选？我给出几个实际建议：
我的选择原则：
- 有线网络、低丢包（< 0.1%）：用 Reno，带宽利用率更高
- 无线网络、高丢包（> 1%）：别用 Reno，考虑 NewReno 或 BBR
- 实时性要求高（如直播）：Tahoe 的激进恢复反而可能更好，因为快速降速能减少排队延迟
- 公平性敏感（如多用户共享链路）：两者都可以，但 Tahoe 更公平
最后说一句：Tahoe 和 Reno 都是 30 多年前的算法了。现在的主流系统很少直接使用它们，但理解这两个算法是学习更复杂拥塞控制算法的基础。CUBIC、BBR、Vegas 这些算法，或多或少都借鉴了 Tahoe 和 Reno 的设计思想。
嗯，这一章就到这里。记住：没有最好的算法，只有最适合场景的算法。下次遇到拥塞控制问题，先看看你的网络环境是什么样的，再决定用哪个算法。