SACK

快速重传机制

    TCP引入了一种叫Fast Retransmit的算法，不以时间驱动，而以数据驱动重传。也就是说，如果，包没有连续到达，就Ack最后那个可能被丢了的包，如果发送方连续收到3次相同的Ack，就重传。Fast Retransmit的好处是不用等timeout了再重传。 

    比如：如果发送方发出了1，2，3，4，5份数据，第一份先送到了，于是就Ack回2，结果2因为某些原因没收到，3到达了，于是还是Ack回2，后面的4和5都到了，但还是Ack回2，因为2还是没有收到，于是发送端收到了三个Ack = 2的确认，知道了2还没有收到，于是就马上重传2。然后，接收到收到了2，此时因为3，4，5都收到了，于是Ack回6。

   Fast Retransmit只解决了一个问题，就是timeout的问题，它依然面临一个艰难的选择，就是重传之前的一个还是重装所有的问题。对于上面的示例来说，是重传#2呢还是重传#2，#3，#4，#5呢？因为发送端并不清楚这连续的3个Ack(2)是谁传回来的？也许是发送端发送了20份数据，是#6，#10，#20传来的呢。这样，发送端很有可能要重传从2到20的这堆数据（这就是某些TCP的实际的实现）。

--------------------- 

内容来自：TCP的那些事儿(上)  参考链接：https://blog.csdn.net/ixidof/article/details/27716549

 

一篇Google的论文《An Argument for Increasing TCP’s Initial Congestion Window》Linux 3.0后采用了这篇论文的建议——把cwnd 初始化成了 10个MSS。 而Linux 3.0以前，比如2.6，Linux采用了RFC3390，cwnd是跟MSS的值来变的，如果MSS< 1095，则cwnd = 4；如果MSS>2190，则cwnd=2；其它情况下，则是3。

--------------------- 

内容来自：TCP的那些事儿(下)  参考链接：https://blog.csdn.net/ywk253100/article/details/27311281

 

NewReno每个RTT内只能恢复一个丢失的数据包，所以如果丢失了N个数据包，那么Fast Recovery就要持续N*RTT的时间，当N比较大时，这是一段相当长的时间。而SACK则没有这个限制，依靠SACK option的信息，它能够同时恢复

多个数据包，更加快速和平稳的恢复。
---------------------
参考链接：https://blog.csdn.net/zhangskd/article/details/7174682

注：仿真实结果与上述节点一致：当丢一半包的时候，没收到一个Partial ACK，重传第一个未被确认的数据包和一个新数据，每一轮共传输2个数据包。

 

Reno

在快速恢复阶段，每收到重复的ACK，则cwnd加1；收到非重复ACK时，置cwnd = ssthresh，转入拥塞避免阶段；如果发生超时重传，则置ssthresh为当前cwnd的一半，cwnd = 1，重新进入慢启动阶段。
Reno快速恢复阶段退出条件：收到非重复ACK。 

Reno不能有效的处理多个分组从同一数据窗口丢失，于是有了NewReno。

NewReno

NewReno修改了Reno的快速恢复算法，处理一个窗口中的多个报文段同时丢失时出现的“部分确认”（Partial ACKs，它在快速恢复阶段到达并且确认新数据，但它只确认进入快速重传之前发送的一部分数据）。
在这种情况下，Reno会退出快速恢复状态，等待定时器溢出或者重复的确认ACK到达，但是NewReno并不退出快速恢复状态，而是：

step1：重传紧接着那个部分ACK之后的报文段，拥塞窗口等于其减去partial ACK的部分。
step2：对于得到确认的新数据，cwnd++
step3：对于第一个或每一个Partial ACK，重传定时器复位。且每次都重置cwnd = 原cwnd / 2。 

NewReno算法中有变量recover，其值为检测到丢包时的最大发送序列号。只有当recover之前的数据
报都确认完后，才能推出快速恢复，进入拥塞避免阶段。
当超时时，将发送的最大序列号保存在recover变量中，结束快速恢复过程。
NewReno不支持SACK。
---------------------
原文链接：https://blog.csdn.net/zhangskd/article/details/7174682

 

参考链接：https://blog.csdn.net/qq_35733751/article/details/80157509