当前位置：首页 > TCP/IP > 正文

TCP拥塞控制之TCP Tahoe和TCP Reno

TCP/IP
2022-11-23
2266
更新：2022-11-23 10:28:25

## TCP Tahoe

1986年至1988年间，Van Jacobson提出了基本的拥塞控制方案，并制定了第一个实现协议，即**TCP Tahoe**。传输比率应考虑接收和拥塞窗口的值，使发送器限制在**最小值为 rwnd 且最大值为 cwnd 的传输比率。**

> ◼ 慢启动（在连接启动时快速查找网络容量或数据包超时）
>
> 1、 窗口从最大 MSS 开始
> 2、 为每个数据包的 ACK 增加窗口
> 3、 呈指数增长的拥塞窗口以感知网络容量
>
> ◼ 拥塞避免状态——在接近最大网络容量时仔细探测
> ◼ 三次重复确认(DACK)
> ◼ 快速重新传输意味着如果您收到三次重复确认 ACK，不要等待超时就重新传输丢失的段。

**Tahoe 机制的 FSM：**

![image-20221123093859855](https://ngdcn.com/zb_users/upload/2022/11/tahoe_reno/image-20221123093859855.png)

## TCP Reno

1990 年**TCP Reno**引入了**AIMD**算法（加法增加/乘法减少）的应用：

1、 传输速率将逐渐增加，直到发生一些数据包丢失。
2、 增加将通过线性增加拥塞窗口来实现，即通过增加一个值。
3、 如果推断出拥塞，则传输率将降低，但在这种情况下，将通过乘以一个值来降低。

在超时时表现与 Tahoe 相同

> ◼ 在三次重复 ACK 上：
>
> 1、 设置拥塞窗口阈值为 2 
> 2、 将拥塞窗口设置为拥塞 win/2 –> 快速恢复
> 3、发送数据膨胀/填充拥塞窗口大小（快速恢复）
> 4、重传丢失的段（快速重传）
> 5、保持拥塞避免状态
>
> ◼ TCP Reno 添加了额外的优化，三次重复 ACK不会导致 TCP 丢失一个 RTT 价值的传输而是等待丢失的段被确认（注：网络还没有那么糟，只是认为其轻微拥塞）。

**Reno 机制的 FSM：**

![image-20221123094415196](https://ngdcn.com/zb_users/upload/2022/11/tahoe_reno/image-20221123094415196.png)

**基本上，Tahoe 和 Reno 之间的区别在于快速恢复。**

观察信号：

◼ **增加 ACK**：传输进行顺利
◼ **重复的 ACK**：有些东西丢失了，延迟了
◼ **超时**：坏事了，网络太糟糕

声明：本文素材来源于网络，仅供学习使用，如有侵权请联系网站删除(ngdcn_admin@163.com)。