使用示例的 TCP Reno 协议

TCP Reno是TCP协议的重要组成部分，其主要职责是负责网络中的拥塞控制问题。TCP Reno实际上是TCP Tahoe的扩展版本——而TCP Tahoe则是一种内置的拥塞控制算法。

TCP Reno模式包括慢启动、AIMD功能、快速重传机制以及快速恢复机制。

TCP Reno的工作原理

假设：

1. 发送方拥有无限的数据可以发送。
2. initcwnd = 10个段
3. 第3个和第4个数据包被丢弃了。

让我们通过一个例子来了解一下TCP Reno的工作原理：

步骤1:最初，发送方向网络中发送了10个数据包，而无需等待任何确认信号。

cwnd = 10, inflight = 10. 

我们事先假设，第3个和第4个数据包已经丢失了，发送方目前还不知道这一点。

步骤2-5：发送方收到了数据包1的确认，于是将cwnd的值增加1。因此，cwnd现在为11。由于数据包1已经被接收方接收到，所以它还没有被传输出去。因此，处于传输状态的数据包数量为10-1=9。不过，处于传输状态的数据包数量最大只能是cwnd的值，所以发送方会继续向连接中发送2个新的数据包。于是，数据包11和12就被发送出去了。

当新的ACK信号到达发送端，且当前传输的包数小于等于cwnd时，发送方会将其cwnd和inflight值各增加1，然后向网络发送2个新的数据包。步骤2到5的过程也遵循相同的逻辑。

步骤6：

• 当接收方接收到顺序混乱的数据包时（即1、2、5、7这样的顺序），它就会生成重复的ACK信号。
• 接收方会依次发送最后一个已接收数据包的确认信号。
• 当发送方收到第三个重复的确认消息时，就会重新发送丢失的数据包（即数据包3）。
• 这一次，cwnd并没有像上述步骤那样增加。

当在TCP Reno中检测到数据包丢失时，会有以下4种情况发生：

1. Cwnd减少了一半，即 Cwnd = Cwnd/2。
2. Sthresh的值被缩小到cwnd的一半，即Sthresh = cwnd/2。
3. 发送者会在被称为“沉默的半窗口”的时间内保持沉默。
4. 发送方进入快速恢复阶段。

在半个沉默窗口期间，发送方不会传输任何新的数据包。但是，由于确认了某个数据包已经丢失，因此发送方会立即重新传输该数据包。这种情况就是“infight”大于“cwnd”的情况。发送方会保持沉默，直到“infight”等于“cwnd”。这个时间段就被称为“半个沉默窗口”。

步骤7-12：这就是所谓的“沉默的半窗”。发送方收到了之前传输过的数据包的确认消息，但并没有向网络中发送任何新的数据包。由于发送方没有按顺序接收到所有数据包，因此它还会收到重复确认的消息。而重新传输的数据包3仍然在传输过程中，且尚未被接收方收到。

步骤13-17：半窗口的沉默状态已经结束，现在发送方在收到重复的ACK信号时，会继续传输数据包。如果发送方不继续传输新的数据包，那么每个ACK信号后，传输的数据量就会减少1。为了充分利用网络资源，必须不断传输新的数据包。

步骤18: 发送方收到了数据包3的确认消息。由于该数据包是在进入快速恢复阶段之前被重新发送的，因此这个确认消息被视为一个新的确认信息。此时，发送方从快速恢复阶段中退出，进入自适应调整阶段。所谓“自适应调整”，指的是每次收到确认消息时，数据速率会相应增加1/cwnd。因此，实际传输的数据量则会随着每个RTT的增加而增加1个单位。

步骤19和20：发送方收到了数据包3的重复确认信息，即ACK-1和ACK-2。我们知道，数据包4已经丢失了（这是我们的假设），但发送方目前还不知道这一点。这就是TCP Reno的一个主要局限性。

接收方已经按顺序收到了数据包1、2、3。而数据包4则缺失了，因此，接收方正在发送最后一个已收到的数据包（即数据包3）的重复确认信号。

步骤21：发送方收到了关于数据包3的第三次确认信号。这表明下一个数据包已经丢失了，而数据包4也丢失了。此时，系统将再次进入快速恢复模式。不过在此之前，发送方会重新发送数据包4。

Thus, cwnd = current cwnd / 2inflight > cwnd {exception}Enters Fast recovery.

TCP Reno的限制：

1. 它无法在单个连接窗口大小内检测到多次数据包丢失的情况。因此，它会将连接窗口的大小减少相应的次数（即减少与丢失的数据包数量相对应的次数）。这样一来，连接窗口的大小就会显著减小，而这是不必要的操作，因为只要减少连接窗口的大小一次，网络就能从拥塞状态中恢复过来。
2. 在半窗静默期间，发送方因为处于闲置状态而浪费了资源。
3. 在相同的拥塞窗口中，要检测到多个丢失的数据包，需要花费相当长的时间。
4. 在长距离传输过程中，性能会下降：TCP Reno以数据包丢失作为拥塞的指示器。当数据包因为与拥塞无关的原因而丢失时，比如传输过程中出现长时间的延迟，那么TCP Reno的性能就会显著下降。
5. 公平性问题：当多个流共享同一个瓶颈链路时，TCP Reno并不总是公平的。这是因为，无论有多少个流共享该链路，TCP Reno都会以相同的比例降低每个数据包的发送速率。
6. 有限的拥塞控制：TCP Reno旨在针对每个数据流进行拥塞控制。然而，在现代网络环境中，数据流往往会有多条路径，而这些路径上的拥塞程度也有所不同。因此，TCP Reno无法有效利用这些特性。
7. 无法处理突发流量：TCP Reno并不适合处理突发流量的情况，因为它依赖数据包的丢失来检测拥塞情况。虽然突发流量会导致拥塞，但并不一定会引发数据包的丢失，因此其性能表现并不理想。