一、概述
DSACK下的虚假重传的检测我们之前重传部分的文章已经介绍过了，这里简单说一下拥塞控制部分的实现。
linux内部会维护一个undo_retrans状态变量，其值为已经重传的次数减掉被DSACK检测到的虚假重传的次数，例如当前总共重传了5个数据包，DSACK检测到3个虚假重传，那么undo_retrans即为2。undo_retrans初始化为-1，当发生重传的时候，如果undo_retrans为-1那么就更新undo_retrans=1，否则更新undo_retrans=undo_retrans+1。这样当undo_retrans=0的时候，就表示DSACK已经检测到之前的重传都是虚假重传，可以进行拥塞撤销过程了。DSACK块只能在ACK报文中传输一次，因此当传输DSACK信息的ACK报文丢失的时候，DSACK下的拥塞撤销就不能生效了。下面我们通过DSACK下的拥塞撤销实例来看一下DSACK下的拥塞撤销过程。
二、wireshark示例
1、Open状态下DSACK的拥塞撤销
在这个示例中我们除了观察DSACK的拥塞撤销外还要看一下TSopt的协商问题。我们之前介绍TSopt选项的时候介绍过，如果server与client端协商好TSopt选项后，但随后接收到不带有TSopt选项的数据的时候，协议说TCP应该静默的丢弃这个报文(注意协议描述是应该should而不是必须must)，我们提到过linux则会正常接收这个报文，通过这个示例顺便来演示一下。在运行示例前如下设置相关参数。
******@Inspiron:~$ sudo ip route add local 127.0.0.2 dev lo congctl reno initcwnd 4 #参考本系列destination metric文章******@Inspiron:~$ sudo ethtool -K lo tso off gso off #关闭tso gso以方便观察cwnd变化
业务场景：server端在与client端建立连接后，休眠1002ms，然后连续进行17次write写入操作，每次写入50bytes数据，每次写入间隔5ms。其中高亮的No6数据包发生了乱序传输，在No11之后到达client端，client对每个收到的数据包都会回复一个ACK确认包。注意下面的示例中，server端的TCP在Open状态下，通过拥塞撤销，从拥塞避免切换到了慢启动。
No1-No3：client与server端通过三次握手建立连接，注意三次握手这里协商了TSopt，其余的废话不多说了
No4-No24：这里前面也解释过很多类似场景了，这里可以看到No4数据包没有TSopt选项，但是server端TCP依然正常接收了，另外需要补充说明的一点是server收到No17后，从Disorder模式切换到Recovery模式时候，会初始化undo_retrans=-1，然后在重传了No18后，设置undo_retrans=1。最终在发出No24后，server端处于Open状态，正在进行拥塞避免过程，prior_ssthresh=0x7fffffff， ssthresh=2， cwnd=2， cwnd_cnt=1， packets_out=2， sacked_out=0， lost_out=0， retrans_out=0， fackets_out=0，undo_retrans=1，undo_marker非0表示允许进行拥塞撤销。
No25-No27：可以看到No25带有一个DSACK块，通知server端重复收到了系列号为(51,101)的报文，server端在收到这个DSACK块的时候，更新undo_retrans=undo_retrans-1=0，接着server端发现当前undo_marker非0，即上次快速重传还没有进行过拥塞撤销，同时undo_retrans=0，因此判断之前的快速重传为虚假重传，接着进行拥塞撤销的过程，更新cwnd=max(cwnd,2*ssthresh)=4，ssthresh=max(ssthresh,prior_ssthresh)=0x7fffffff，此时in_flight=2-(0+0)+0=2，拥塞窗口允许TCP发出两个新数据包，即No26、No27，然后更新packets_out=4。这里要注意No25的SACK选项中带有的是一个DSACK块，因此并不会更新sacked_out，也不会触发server从Open状态切换到Disorder状态了。
No28-No41：server端在收到No25进行拥塞撤销后，又进入慢启动阶段，随后进入application-limited状态，这个过程不再重复叙述，最终server端在收到No41后，ssthresh=0x7fffffff，cwnd=12。
