聊一聊tcp 拥塞控制五 d-sack reordering lost-pkt
查看之前的blog：浅析sack
dsack检测
根据RFC 2883，DSACK的处理流程如下：
1）look at the first SACK block :
—If the first SACK block is covered by the Cumulative Acknowledgement field, then it is a D-SACK
block, and is reporting duplicate data.
—Else, if the first SACK block is covered by the second SACK block, then the first SACK block is a
D-SACK block, and is reporting duplicate data.
2）otherwise, interpret the SACK blocks using the normal SACK procedures.
简单来说，符合以下任一情况的，就是DSACK：
1）第一个SACK块的起始序号小于它的确认序号，说明此SACK块包含了确认过的数据。
2）第一个SACK块包含在第二个SACK块中，说明第一个SACK块是重复的
static bool tcp_check_dsack(struct sock *sk, const struct sk_buff *ack_skb, struct tcp_sack_block_wire *sp, int num_sacks, u32 prior_snd_una) { struct tcp_sock *tp = tcp_sk(sk); u32 start_seq_0 = get_unaligned_be32(&sp[0].start_seq);/* 第一个SACK块的起始 */ u32 end_seq_0 = get_unaligned_be32(&sp[0].end_seq);/* 第一个SACK块的结束 */ bool dup_sack = false; /* 如果第一个SACK块的起始序号小于它的确认序号，说明此SACK块包含了确认过的数据， * 所以第一个SACK块是DSACK。 */ if (before(start_seq_0, TCP_SKB_CB(ack_skb)->ack_seq)) { dup_sack = true; tcp_dsack_seen(tp); NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPDSACKRECV); } else if (num_sacks > 1) { u32 end_seq_1 = get_unaligned_be32(&sp[1].end_seq);/* 第二个块的结束序号 */ u32 start_seq_1 = get_unaligned_be32(&sp[1].start_seq);/* 第二个块的起始序号 */ if (!after(end_seq_0, end_seq_1) && !before(start_seq_0, start_seq_1)) {/* 如果第一个SACK块包含在第二个SACK块中，说明第一个SACK块是重复的，即为DSACK */ dup_sack = true; tcp_dsack_seen(tp); NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPDSACKOFORECV); } } /* D-SACK for already forgotten data... Do dumb counting. undo_retrans记录重传数据包的个数，如果undo_retrans降到0， * 就说明之前的重传都是不必要的，进行拥塞调整撤销 */ /* undo_marker为进入Recovery或FRTO状态时记录的snd_una，prior_snd_una为根据该ACK 更新窗口前的snd_una。如果回复的DSACK在这块中间，说明是超时重传或FRTO后进行的重传，因此需要减 少undo_retrans。当undo_retrans减小到0，说明之前的重传都是不必要的，网络并没有拥塞，因此要进行拥 塞调整撤销。*/ if (dup_sack && tp->undo_marker && tp->undo_retrans > 0 && !after(end_seq_0, prior_snd_una) && after(end_seq_0, tp->undo_marker)) tp->undo_retrans--; return dup_sack; }
乱序检测的目的时探测网络是否发生重排导致的丢包，并以此来更新 dupthresh 值。只要能收到一个 ACK 或者 SACK，其序列号位于当前已经被 ACK 或 SACK 的数据包最大的序列号之前，就说明网络发生了重排造成了乱序，此时如果涉及的数据包大小大于当前能容忍的网络乱序值，即 dupthresh 值，就说明网络乱序加重了，此时应该更新 dupthresh 值。之所以保持 dupthresh 的值递增，是考虑其初始值 3 只是一个经验值，既然真实检测到乱序，如果其值比 3 小，并不能说明网络的乱序度估计偏大，同时 TCP 保守地递增乱序度，也是为了让快速重传的进入保持保守的姿态，从而增加友好性。
转载：
一、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，有些实现可能会在协议的基础上做一些扩展)。
