TCP系列25—重传—15、DSACK虚假重传探测

一、DSACK介绍

RFC2883通过指定使用SACK来指示接收端的重复包(duplicate packet)扩展了RFC2018对SACK选项的定义(SACK选项的介绍和示例参考前面内容)。RFC2883建议在收到重复报文的时候，SACK选项的第一个块(这个块也叫做DSACK块)可以用来传递触发这个ACK确认包的系列号，这个就是DSACK(duplicate-SACK)功能。这样允许TCP发送端根据SACK选项来推测不必要的重传。进而利用这些信息在乱序传输的环境中执行更健壮的操作。这个DSACK扩展是与原有的SACK选项的实现相互兼容的。DSACK的使用也不需要TCP连接的双方额外协商(只要之前协商了SACK选项即可)。当TCP的发送方不理解DSACK扩展的时候会简单的丢弃DSACK块并继续处理SACK选项中的其他块。

当DSACK使能的时候，总结起来如下

• 一个DSACK块只用来传递一个接收端最近接收到的重复报文的系列号，每个SACK选项中最多有一个DSACK块

• 接收端每个重复包最多在一个DSACK块中上报一次。如果接收端依次发送了两个带有相同DSACK块信息的ACK报文，则表示接收端接收了两次重复包，因此带有DSACK块信息的ACK确认包传输丢失的时候重复包信息也会丢失。

• 和普通的SACK块一样，DSACK块左边指定重复包的第一个字节的系列号，右边指定重复包最后一个字节的下一个系列号

• 如果收到重复报文，第一个SACK块应该应该指定触发这个ACK确认包的系列号(这个SACK块也叫做DSACK块)。如果这个重复报文是一个大的不连续块的一部分，那么接下来的这个SACK块应该指定这个大的不连续块，额外的SACK块应该按照RFC2018指定的顺序排列。

另外还有一种部分重复段(partial duplicate segment)的上报场景，我们会在示例中展示说明。注意按照上面的描述，DSACK块有可能处于ack number之前。接收端在接收到SACK报文的时候，应该把第一个SACK块与这个ACK报文的ack number比较(而不是和当前已经接收到的最大的ack number比较)，如果小于等于ack number则说明是DSACK块，如果大于ack number则应该与第二个SACK块比较，如果第二个SACK块包含第一个SACK块，则说明第一个SACK块为DSACK块，如果上面两个条件都不满足说明第一个SACK块是普通的SACK块。

在linux中/proc/sys/net/ipv4/tcp_dsack控制发出的报文中是否携带DSACK信息，但是不管该参数设置为何值，对于接收的TCP报文，linux总是会执行DSACK块的检测处理。当linux检测到DSACK块信息的时候会尝试撤销拥塞控制对于拥塞窗口的作用。另外在TLP丢包探测中也可以用来做loss probe的丢包探测。

二、wireshark示例

1、tcp_dsack=1，接收到ack number之前的数据包

如下图所示，client和server三次握手后，依次发送No4(1-6)、No6(7-13)、No8(7-13)、No10(14-20)四个数据包，server端接收到No8时候发现是一个重复包，因此回复一个带有DSACK的ACK确认包(No9)，其中DSACK块信息为(7-14)，表示收到了一个系列号为(7-13)的重复包。

2、tcp_dsack=1，接收到ack number之后的数据包

• client端分别发送No4(1-6)和No6(7-13)，server端正常回复不带有SACK选项的ACK确认包

• 接着client发送No8(21-27)，模拟系列号(14-20)的报文在由client向server传输的过程中丢包

• server端回复一个带有SACK选项的ACK确认包(No9)，其中包含一个SACK块(21-28)

• client端继续发送No10(24-34)，server端回复No11的ACK确认包，包含一个SACK块(21-35)

• 接着client发送No12(42-48)，模拟系列号为(35-41)的报文传输过程中发生丢失

• server端回复No13的ACK报文，带有两个SACK块，依次为(42-49)和(21-35)

• client端发送No14(28-34)，这个数据包与No10数据包系列号相同

• server端收到No14的重复包之后，回复No15确认包，带有一个DSACK块(28-35)和两个额外的SACK块，这两个SACK块依次为(21-35)(42-49)

• 接着client发送No16(14-20)，server端回复No17确认包，带有一个SACK块(42-49)。

• client发送No18(35-41)，server端回复No19确认包，不带有SACK信息，整个传输过程结束

3、tcp_dsack=1，接收到ack number之后的部分重传段

此处不在罗嗦叙述过程，此处仅把SACK的信息文字补充描述一下，其他信息请自行下载对应的wireshark文件

其中No9、No11、No13、No15包含SACK信息，No9包含一个SACK块(28-35)，No11包含一个SACK块(28-42)，No13包含两个SACK块信息(49-56)、(28-42)，No15包含一个DSACK块(28-42)和一个额外的SACK块(21-56)，注意此处No14(21-55)与之前的两个SACK块(49-56)、(28-42)都是重复包，着一个TCP包与前面的三个包内容重复还发送了新的数据，这种同时带有新数据和重复数据的tcp报文就叫做部分重传段，当部分重传段中同时带有多个重复段的时候，协议规定DSACK块值反馈第一个重复端的系列号范围。可以看到此时linux的处理是符合协议的。

4、tcp_dsack=1，接收到ack number之前的部分重传段

此处同样仅用文字描述一下SACK信息，No9带有一个SACK块(21-28)，No11带有一个SACK块(21-35)，No13带有两个SACK块(42-49)和(21-35)，No15数据包带有一个DSACK块(21-56)。注意这里与上面同样是带有两个重复段大的部分重传段，但是linux反馈的DSACK信息却把两个重复段都包含了，而且还扩展到了最新发送的55系列号(DSACK块中的56表示55系列号的后一个系列号)。RFC2883协议中的对这种场景的描述是：

When the SACK option is used for reporting partial duplicate segments, the first D-SACK block reports the first duplicate sub-segment.  If the data packet being acknowledged contains multiple  partial duplicate sub-segments, then only the first such duplicate sub-segment is reported in the SACK option.

而linux的处理则是，如果当前接收到的数据包的系列号与待接收的连续系列号相同，那么回复的DSACK块的起始系列号则为乱序队列中的最小系列号，终止系列号则为新收到的数据包的最大系列号加1。显然linux的处理与协议要求不符合，而且与DSACK扩展功能的预期不相符，具体原因我也没查到(不过并不是所有不符合协议的实现都是bug，有些实现可能会在协议的基础上做一些扩展)。

补充信息：

1、示例4场景中描述的linux的DSACK处理逻辑位于函数tcp_ofo_queue中

来自为知笔记(Wiz)