TCP

TCP快速重传和超时重传都会面临到一个重传什么包的问题，因为发送端也不清楚丢失包后面传送的数据是否有成功的送到。主要原因还是对于TCP的确认系统，不是特别的好处理这种不连续确认的状况了，只有低于ACK number的片段都被收到才有进行ACK，out-of-order的片段只能是等待，同时，这个时间窗口是无法向右移动的。

假设服务器给客户端发送了序号为0-1000的数据包，客户端只收到0-800和820-1000的数据，序号为801-819的数据缺失。此时，客户端就会向服务器发送反馈，发送ACK=800并且增加SACK通知服务端收到了SLE=820，SRE=1000的数据包。那么，服务器就知道下次需要从seq=801开始发，并且发801-819这段数据，不需要重复发送820-1000的数据，因为此时已经收到了。 在这个过程中，SACK就能够保证发送端只传输中间丢失的部分数据，不需要重复发送已接收到的数据，提升网络效率。

SACK(Selective Acknowledgment) SACK：selective ACK，即TCP的选项，来允许TCP单独确认非连续的片段，用于告知真正丢失的包，只重传丢失的片段 D-SACK：duplicate selective ACK，即使用SACK来告诉发送方有哪些数据被重复接收了。 SLE: Sequence Left Edge of already acknowledged data when Selective Acknowledgments are used，即已收到tcp数据的左边界。 SRE: Sequence Right Edge of already acknowledged data when Selective Acknowledgments are used， 即已收到tcp数据的右边界。

SACK是一个TCP的选项，来允许TCP单独确认非连续的片段，用于告知真正丢失的包，只重传丢失的片段。要使用SACK，2个设备必须同时支持SACK才可以，建立连接的时候需要使用SACK Permitted的option，如果允许，后续的传输过程中TCP segment中的可以携带SACK option，这个option内容包含一系列的非连续的没有确认的数据的seq range，这些SYN包中SACK Permitted 选项，双方都支持才对。

Kind 5 Length 剩下的都是没有确认的segment的range了 比如说segment 501-600 没有被确认，那么Left Edge of 1st Block = 501，Right Edge of 1st Block = 600，TCP的选项不能超过40个字节，所以边界不能超过4组。

SACK通常是由数据接收方产生，如果在connection建立的时候，SYN包中有SACK-Permitted 的选项为true，同时自身也支持SACK，那么可以在接收异常的时候，产生SACK option. 如果要发送，SACK中需要携带接收队列中所有没有被确认的数据段信息。

如果接收方选择发送带有SACK的ACK，需要遵循如下规则：

第一个block需要指出是哪一个segment触发SACK option ，我认为就是谁乱序了，才会导致SACK

尽可能多的把所有的block填满

SACK 要报告最近接收的不连续的数据块

接收端的行为：

数据没有被确认前，都会保持在滑动窗口内

每一个数据包都有一个SACKed的标志，对于已经标示的segment，重新发送的时候会忽略

如果SACK丢失，超时重传之后，重置所有数据包SACKed 标志

D-SACK主要是使用了SACK来告诉发送方有哪些数据被重复接收了，如果是D-SACK，那么SACK option的第一个block代表被重复发送的序列片段

需要注意的点：

D-SACK仅仅是接收端报告一个重复的连续的片段

每个重复的连续片段只能在一个block中

重复片段的序列号，特别注意右端序号应该是重复报文的最后一个seq + 1。（具体见下方）

第二个block指的是data没有被确认的

从图中可以看出seg4 out-of-order会触发SACK，说明已经收到4500-5000的数据，中间丢了4001-4499的数据。但是这个ACK报文丢掉了。发送方又重传了seg1，接收方此时会生成D-SACK，block1中存放了dup的segment，block2中存放了收到但没有确认（ACK要等于5000才算是确认过）的segment。

注：个人觉得，图中seg4报文的回复不正确，SACK应该是4500-4999，即对应的SLE和SRE。图中最后一个seg1的回复中，SACK是正确的，是D-SACK。 RFC2883中对D-SACK的解释如下：左端是重复报文的第一个seq，右端是跟在重复报文的最后一个seq后面的序号，即重复报文的最后一个seq + 1。

还有比较多的例子，详细的可以参考 RFC2883。

总起来说，D-SACK还是带了诸多的好处，能否让发送方了解是ACK丢了还是发送的数据包丢了，重复发送就说明是ACK丢了呗，同时也能够掌握网络上的一些事情，比如out-of-order，超时重传等，这样了解了网络，才能更好的做流控。