一、概述

FRTO虚假超时重传检测我们之前重传章节的文章已经介绍过了,这里不再重复介绍,针对后面的示例在说明两点

1、FRTO只能用于虚假超时重传的探测,不能用于虚假快速重传的探测。

2、延迟ER重传触发的进入Recovery状态时候,并不会立即更新cwnd。

本篇在演示FRTO的同时,还会涉及到ER超时重传、TLP探测、SACK关闭场景下的拥塞撤销,后面或者前面都会有针对这些场景的专门介绍文章。

一、wireshark示例

1、FRTO与ER

我们通过一个示例看一下关闭SACK时候,tcp_sack=0,FRTO虚假超时探测和拥塞撤销的处理,同时我们需要设置关闭TSopt选项,否则Eifel探测会先于FRTO探测到虚假超时,tcp_timestamps=0,后面我们会介绍到Eifel探测。如下设置相关参数

  1. ******@Inspiron:~$sudo ip route add local 127.0.0.2 dev lo congctl reno initcwnd 3  ssthresh lock 15   #参考本系列destination metric文章
  2. ******@Inspiron:~$ sudo ethtool -K lo tso off gso off  #关闭tso gso以方便观察cwnd变化

业务场景:server端在与client端建立连接后休眠1s,然后写入50bytes数据,接着休眠46ms,然后以3ms为间隔连续写入6次,每次写入50bytes。client在收到第一个数据包并回复ACK确认包后,server与client之间的RTT突然变大(RTT大约从50ms突变为300ms,例如移动终端切换场景),然后server端触发虚假RTO超时。最终TCP流交互如下图所示。

No1-No9:server端慢启动过程,不再解释,注意因为关闭了SACK功能,因此TLP功能也不会使能,因此server端在收到No7数据包的时候会重新启动RTO定时器,后面也不会被改写为TLP定时器。发出No9后ssthresh=15, cwnd=4, packets_out=4, sacked_out=0,  lost_out=0, retrans_out=0。

No10:RTO超时后,server端从Open状态切换为Loss状态,更新prior_ssthresh=max(ssthresh, cwnd*3/4)=15, ssthresh=max(cwnd/2, 2)=2, cwnd=1,并把No5、No6、No8、No9四个数据包标记为lost,lost_out=4,接着重传No5数据包,retrans_out=1。并且当前满足使能FRTO的条件。

No11-No13:No11报文为client对No5的确认包,server端收到No11报文后,更新packets_out=3, lost_out=3,retrans_out=0,发现当前使能了FRTO功能,并且No11这个报文的ack number确认了新的数据包,因此server端FRTO尝试发出新的未发送数据包,此时cwnd=1,in_flight=3-(3+0)+0=0,因此发出一个数据包即No12,FRTO对这个ACK报文的处理结束。接着reno的慢启动更新cwnd=2,又发出一个新数据包即No13。最终packets_out=5。

No14:server端收到No14报文后,更新packets_out=4,lost_out=2,发现No14这个确认包相比No11又确认了新的数据包,而且新确认的数据包是未曾重传过的No6数据包,因此server端FRTO认定之前的No10重传为虚假超时重传,接着进行拥塞撤销,更新cwnd=max(cwnd,2*ssthresh)=4,ssthresh = max(ssthresh,prior_ssthresh)=15,并取消No8、No9数据包的lost标记,更新lost=0,server端从Loss状态切换为Open状态。接着reno的慢启动更新cwnd=5。

No15-No16:同样是延迟到达的ACK报文,最终ssthresh=15, cwnd=7, packets_out=2, sacked_out=0,  lost_out=0, retrans_out=0。

No17:No17是No10的确认包,是一个dup ACK,server端收到No17后更新sacked_out=1,并从Open状态切换为Disorder状态,此时满足

sacked_out>0, packets_out >= (sacked_out + 1) , packets_out < 4这几个条件且没有待发送的新数据,因此触发延迟ER,设置ER定时器为RTT/4(大约为35ms)。处理完No17后ssthresh=15, cwnd=7, packets_out=2, sacked_out=1,  lost_out=0, retrans_out=0。

No18:ER定时器超时后,server端从Disorder状态切换到Recovery状态,更新high_seq=351, prior_ssthresh=max(ssthresh, cwnd*3/4)=15, ssthresh=max(cwnd/2, 2)=3,并把No12数据包标记为lost,更新lost_out=1,接着重传这个数据包,即发出No18,并更新retrans_out=1, prr_out=1。最终ssthresh=3, cwnd=7, packets_out=2, sacked_out=1,  lost_out=1, retrans_out=1。注意ER定时器超时重传的时候并没有直接削减cwnd。

No19-No20:No19是一个partial ACK,更新packets_out=1, sacked_out=0,  lost_out=0, retrans_out=0,SACK关闭场景下收到partial ACK,会立即把partial ACK的ack number对应的数据包(即No13)标记为lost,因而又更新lost_out=1,接着进入更新cwnd的流程,注意这里newly_acked_sacked=0, 因此并不会更新cwnd ,接着重传标记为lost的数据包即No20,更新retrans_out=1,prr_out=2。

No21:No21是No13数据包的确认包,server端收到No21的时候,更新packets_out=0,lost_out=0,retrans_out=0,Ack=351=high_seq,即正好到达Recovery point,但是因为此时SACK处于关闭状态,因此server端并不会从Recovery状态切换到Open状态,更新cwnd=min(cwnd, in_flight+dupthresh)=3, 最终处理完No21后,ssthresh=3, cwnd=3, packets_out=0, sacked_out=0,  lost_out=0, retrans_out=0, prr_delivered=0, prr_out=2。(No21数据包的处理请参考介绍SACK关闭场景拥塞撤销处理的文章)。

No22-No23:server端收到虚假重传的dup ACK的确认包,最终处理完No23后,server端处于Recovery状态,ssthresh=3, cwnd=3, packets_out=0, sacked_out=0,  lost_out=0, retrans_out=0, prr_delivered=0, prr_out=2。

TCP系列48—拥塞控制—11、FRTO拥塞撤销-LMLPHP

2、FRTO与TLP

我们会在DSACK拥塞撤销的文章中用示例演示了server与client协商好TSopt后,如果收到不带有TSopt选项的数据包,虽然协议建议静默丢弃这种报文,但是linux仍然正常接收处理。这个示例我们先来看一下client如果与server协商好SACK选项后,而client侧代码bug或者其他原因导致收到乱序包后回复的dup ACK没有携带SACK信息时候,server端会如何处理。同样在执行示例前如下设置相关TCP参数:

  1. ******@Inspiron:~$sudo ip route add local 127.0.0.2 dev lo congctl reno initcwnd 5  ssthresh lock 4   #参考本系列destination metric文章
  2. ******@Inspiron:~$ sudo ethtool -K lo tso off gso off  #关闭tso gso以方便观察cwnd变化

业务场景:server端在与client端建立连接后休眠1000ms,接着以3ms为间隔,连续发送10个数据包,每个数据包的大小为50bytes,其中高亮标出的No7数据包在传输中丢失。client对于收到的乱序的报文回复的dup ACK确认包并不带有SACK选项。最终如下图所示:

No1-No12:连接建立后的拥塞避免过程,最终发出No23后, ssthresh=4, cwnd=4,cwnd_cnt=1, packets_out=5, sacked_out=0,  lost_out=0, retrans_out=0, fackets_out=0,server端处于Open状态,并设置了TLP定时器,PTO=2*RTT,大约为100ms。

No13:这个dup ACK是对No8报文的回复,但是可以看到里面并没有SACK选项,但是在三次握手的时候client和server端是协商了SACK的,因此server端在收到这种不带有SACK选项的dup ACK的时候,并不会更新sacked_out,因此server端也并不会进入Disorder状态。但是server端在收到这个dup ACK的时候,会先取消PTO定时器并设置成RTO定时器,然后检查收到报文的ack number是否能取消RTO定时器,因为收到的报文ack number并没有完整确认数据,因此仍然保留有RTO定时器的设置,接着server端在检查如果当前有设置RTO定时器,就会尝试取消RTO定时器设置为PTO定时器。因此收到No13后,server端最终又会重新设置PTO定时器为2*RTT,大约为100ms。

No14-No16:这几个报文的处理与No13类似,最终收到No16后,重设PTO定时器为100ms。

No17:PTO定时器超时,触发loss probe过程,此时缓存中有待发送的新数据,因此发出No17数据包,更新packets_out=6,并取消PTO定时器设置成RTO定时器。

No18:server端收到No18后又会把RTO定时器重设为PTO定时器,定时时间大约为100ms。

No19-No24:这几个数据包的处理与No17、No18类似。收到No24后,重设PTO定时器,定时时间为100ms。此时 ssthresh=5, cwnd=4,cwnd_cnt=1, packets_out=9, sacked_out=0,  lost_out=0, retrans_out=0, fackets_out=0,server端处于Open状态,注意此时cwnd=4,in_flight=9,可以看到loss probe报文并不会受到拥塞控制cwnd的限制。

No25:当PTO定时器再次超时的时候,此时server端的缓存中已经没有待发送的新数据包,因此重传最后发送的数据包(即No23),注意虽然No25发生了数据包的重传,但是TLP重传后,server端TCP仍然会停留在Open状态,而且并不会更新lost_out等字段,因此重传完No25后, ssthresh=4, cwnd=4,cwnd_cnt=1, packets_out=9, sacked_out=0,  lost_out=0, retrans_out=0, fackets_out=0,server端TCP处于Open状态,并且当前设置有RTO定时器。

No26:server端在收到No26这个dup ACK后的处理与No13类似,最终会把RTO定时器重设为PTO定时器,定时时间大约为100ms。

No27:No26设置的PTO定时器超时后发现当前已经有了一个TLP超时重传(即No25),因此不会在进行TLP尾包重传,而是设置RTO定时器,定时时间大约为250ms,最终RTO超时触发No27重传,此时server端由Open状态切换为Loss状态,发出No27后以指数回退重设RTO定时器,相关状态变量如下,prior_ssthresh=4, ssthresh=2, cwnd=1,cwnd_cnt=1, packets_out=9, sacked_out=0,  lost_out=9, retrans_out=1, fackets_out=0。

No28:No28的ack number确认了未重传的数据包,因此触发FRTO拥塞撤销,更新cwnd=max(cwnd,2*ssthresh)=4,ssthresh = max(ssthresh,prior_ssthresh)=4,同时server端从Loss状态切换为Open状态,然后在Open状态下进入reno的拥塞避免过程,No28的ack number新确认了9个数据包,9/cwnd=2,因此更新cwnd=cwnd+2=6,cwnd_cnt=9-2*4=1,最终ssthresh=4, cwnd=6,cwnd_cnt=1, packets_out=0, sacked_out=0,  lost_out=9, retrans_out=0, fackets_out=0

TCP系列48—拥塞控制—11、FRTO拥塞撤销-LMLPHP

05-11 17:57