什么是TCP New Reno？

TCP New Reno是TCP Reno的扩展版本。 它克服了Reno的局限性。 TCP Reno是TCP协议的第二种变体，它内置了拥塞控制算法。 拥塞处理并不是原始TCP/IP协议套件中的一部分。 TCP Reno是TCP Tahoe的扩展版本，而NewReno则是TCP Reno的进一步扩展。 在Reno网络中，当发生数据包丢失时，发送方会将cwnd的值减少50%，同时也会降低ssthresh的值。 这样，网络就能轻松地从拥塞状态中恢复过来。 但是，Reno面临着非常严重的积压问题，这严重影响了其业绩表现。

当在同一个拥塞窗口中丢失了多个数据包时（比如1-10个），那么每当检测到某个数据包丢失时，就会将cwnd减少50%。 因此，当发生两次数据包丢失时，当前的连接速度将会下降4倍（即减少50%）。 不过，每次在拥塞窗口中减少50%的频率就足以弥补所有丢失的数据包。 假设 cwnd=1024，而在这一时间段内有10个数据包被丢弃。那么，Reno会将 cwnd 减少50%，共10次。最终，cwnd 会变为 1024/2^10 = 1。真是令人惊讶啊。 发送方需要经历10次RTT时间，才能再次将其cwnd值提升到1024。更不用说使用AIMD算法了。

雷诺的局限性：

1. 在相同的拥塞窗口中，要检测到多个数据包的丢失情况，需要花费相当长的时间。
2. 它可以在同一时间窗口内出现多次数据包丢失的情况时，减少拥堵窗口的次数。其中，只需减少一次即可满足需求。

新雷诺·埃维奥尔是如何发展的呢？

这个想法是为了克服Reno的局限性而提出的。 诀窍在于，需要让发送方知道：在相同的拥塞窗口期间，所有丢失的数据包都需要将传输速率降低50%。 这是通过部分确认机制来实现的。 这种新的ACK机制被引入，目的是让发送方能够得知这一情况。 在Reno中，当接收到重传数据包的ACK信号后，系统会将其视为新的ACK信号。随后，系统会立即恢复正常的传输状态，并再次进入AIMD模式。如果再次发生数据包丢失的情况（且当前的数据传输窗口仍然有效），那么系统会重复上述步骤，即将数据传输窗口缩小一半。 但是，NewReno的发送方会检查重新传输的数据包的ACK信号是否为新的。也就是说，该特定连接中的所有数据包是否都已经被接收端确认了。 如果接收方已经收到了该特定连接中所有数据包的确认消息，那么发送方就会认为这些确认是完整的；否则，这些确认就只算作部分确认而已。 如果这是部分确认的话，那么发送方就不会再次将数据包的传输速率减少50%。 它将会保持现状，不会脱离快速恢复阶段。

NewReno解决方案：

它采用了“部分确认”的概念。 当发送方收到第一个被重新传输的数据包的确认消息时，它不会将其视为“新的确认”，这与TCP Reno的做法不同。 NewReno会检查在那个特定窗口内，所有已经传输的数据包是否都得到了确认。 如果同一拥塞窗口中丢失了多个数据包，那么接收方在接收到重新传输的数据包之后，仍然会发送重复的ACK信号。 这样就能让发送方明白，并非所有数据包都成功传达到了接收方。因此，发送方不会将这次的确认视为新的数据。 它将其视为部分确认，因为只确认了部分数据，而不是全部数据。 Reno在接收到新的ACK后，通常会从快速恢复阶段中退出。但是NewReno认为这个ACK只是部分性的，因此Reno并不会从快速恢复阶段中退出。 它很明智地决定在接收到整个拥塞窗口的累积确认后，结束快速恢复阶段。

因此，NewReno能够立即检测到多个数据包的丢失情况，而不会像Reno那样过早地退出快速恢复阶段。

通过一个例子来理解：

假设：

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

步骤18到20TCP Reno将其视为一个新的确认信号，从而从快速恢复阶段退出，进入自适应调整阶段。而NewReno则将其视为部分确认信号，并持续处于快速恢复阶段。发送方会检查是否收到了该拥塞窗口中所有数据包的确认信号。如果收到了所有数据包的确认信号，那么这就是一个新的确认信号；否则，就是部分确认信号。

步骤21在18到20之间，TCP Reno会将拥塞窗口增加1/7。不过，NewReno仍然保持cwnd=7不变，因为它仍处于快速恢复阶段，尚未进入自适应调整阶段。在收到3个重复确认后，它重新发送了数据包4。

步骤22至26：发送方会收到重复的确认消息，同时仍然保持cwnd为“飞行中”状态。每次收到确认消息后，发送方都会向连接中发送一个新的数据包。快速恢复阶段尚未结束，因为发送方还没有收到新的确认消息。

步骤27接收方收到了由发送方重新传输的包4。现在，接收方已经按顺序收到了1到26号的所有数据包。丢失的包3和包4也被接收方收到了。因此，接收方现在会发送一个累积确认，表示它已经收到了包4到26号的数据包，即ACK-26。在最后一步之前，接收方一直发送着重复的ACK-3，表示它已经收到了直到包3的数据包。现在，发送方收到了这个累积确认，然后会检查这个确认是否是一个新的确认信息。

ACK received > cwnd ? Yes : No26 > 10 ? yes : No

因此，是的，ACK-26确实是一种新的ACK。所以，现在发送方将不再处于快速恢复阶段了。

需要注意的是，与Reno版本相比，发送方在快速恢复阶段停留的时间更长。不过，对于相同的拥塞窗口来说，这种处理方式并没有降低cwnd和ssthresh的值。而TCP Reno版本则不具备这种功能。