Reno状态迁移图

在这里插入图片描述

实例分析Reno和NewReno

我们假设当前处于拥塞避免状态。
如下图，[0-11]的这个窗口内的12个数据包从发送方发送。不过1、4数据包还没到达接收方就丢失了。
一般情况下，发送方发送了seq=0,len=1的数据包后，接收方回复的ACK包为ack=1，代表接收方接下来期待的是序号seq从1的数据包。但本节例子为了简便表示，发送方发送了Data[0]后，接收方回复的是ACK[0]，但代表的同样是接收方接下来期待的是Data[1]以及以后的数据。

在这里插入图片描述

Reno的不足之处

普通的Reno的协议会有一个问题：当一个传输窗口出现多个数据包丢失时，一旦第一个丢失的包重传成功，发送方就会收到一个new ACK，从而太早地离开快速恢复状态，但实际上窗口内的其他丢失数据还没有完成重传。在快速恢复状态下的这种ACK被称为局部ACK（本例中，相对于partial ACK，full ACK则是Data[11]）。接下来从示例分析：
在这里插入图片描述

收到的第一个ACK[0]是作为一个new ACK，所以还是处于拥塞避免状态。窗口往后平移1，所以窗口有新的数据可以发送（as allowed），所以马上发送Data[12]。
接下来收到了三个重复的ACK[0]，所以进入快速恢复状态。转移到快速恢复状态的过程中，重传数据包Data[1]（即retransmit missing segment。Data[1]是接收方接下来期待的数据包，所以重传它）
接下来发送方会收到ACK[3]，然后按照Reno算法，这是一个new ACK（也是局部ACK），所以会转移回拥塞避免状态。但不会发送任何数据，且把窗口变为之前处于拥塞避免时的窗口的一半大小。
但ACK[3]只是一个局部ACK。
- 上图为收到ACK[3]的时机，但在Reno算法中，这里不会发送数据。
接下来，我们需要另外三个ACK[3]来触发快速重传机制以快速重传Data[4]，不然，在重传计时器超时之前，传输通道一直会处于空闲状态。并且，在重传计时器超时以后，转移到慢启动状态，严重影响网络吞吐性能（进入慢启动后，需要从1开始重新开始寻找合适的窗口大小，这不就严重影响了吗）。
- 实际上，如果没有9-11的数据包，那么确实不会有另外三个ACK[3]。

NewReno如何解决问题

NewReno协议中，当处于快速恢复状态时收到了局部ACK时，NewReno能得知丢失的数据包还未重传，然后根据局部ACK来重传接收方期待的数据包。

NewReno协议中，会把每个局部ACK当作重复的ACK[0]来看待，这样的话，既然作为重复ACK，那么就会发出新的数据来（如下图）。
在这里插入图片描述
所以NewReno协议收到局部ACK时（特指处于快速恢复状态），会做两个动作：

作为重复ACK，增加窗口长度，发送新数据。
作为局部ACK本身，发送丢失的数据。

并且在快速恢复状态，NewReno会记录上一个数据传输窗口的最高序列号。仅当接收到序列号不小于恢复点的ACK，才停止快速恢复状态。

接下来从示例分析，直接从与上面不同的地方开始讲起吧：
在这里插入图片描述

收到三个重复ACK后，进入到快速恢复状态。但此时记录恢复点，因为窗口是[1-12]，所以恢复点是12。
接下来发送方会收到ACK[3]，然后按照NewReno算法，这是一个局部ACK：
- 因为是局部ACK[3]，所以发送丢失数据4。如下图。
- 因为当作重复ACK，所以发送新数据17。如下图。
当接收方收到4以后，数据就连起来了。那么回复ACK[16]。
当发送方收到ACK[16]，发现这个ACK大于了恢复点，那么此时才退出快速恢复状态。
- 进入快速恢复前，窗口大小为12。进入快速恢复时，做了 ssthresh=cwnd/2，退出快速恢复时，做了 cwnd = ssthresh。所以此时cwnd为6。
- 收到ACK[16]，说明接收方现在期待17以及以后数据。[17-22]的窗口大小为6。之前已经发过[17-21]了，所以这里只需要发22。
当发送方收到ACK[17]，窗口大小几乎不变（cwnd=cwnd+MSS*(MSS/cwnd)），窗口往后移动1的单位，所以发送新数据23。
之后都是正常流程