net做网站遇到的问题,打不开建设银行网站,户外拓展公司网站开发,网站编程设计如何写备注一、概述FRTO虚假超时重传检测我们之前重传章节的文章已经介绍过了#xff0c;这里不再重复介绍#xff0c;针对后面的示例在说明两点1、FRTO只能用于虚假超时重传的探测#xff0c;不能用于虚假快速重传的探测。2、延迟ER重传触发的进入Recovery状态时候#xff0c;并不会…一、概述FRTO虚假超时重传检测我们之前重传章节的文章已经介绍过了这里不再重复介绍针对后面的示例在说明两点1、FRTO只能用于虚假超时重传的探测不能用于虚假快速重传的探测。2、延迟ER重传触发的进入Recovery状态时候并不会立即更新cwnd。本篇在演示FRTO的同时还会涉及到ER超时重传、TLP探测、SACK关闭场景下的拥塞撤销后面或者前面都会有针对这些场景的专门介绍文章。一、wireshark示例1、FRTO与ER我们通过一个示例看一下关闭SACK时候tcp_sack0FRTO虚假超时探测和拥塞撤销的处理同时我们需要设置关闭TSopt选项否则Eifel探测会先于FRTO探测到虚假超时tcp_timestamps0后面我们会介绍到Eifel探测。如下设置相关参数******Inspiron:~$sudo ip route add local 127.0.0.2 dev lo congctl reno initcwnd 3 ssthresh lock 15 #参考本系列destination metric文章******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-No9server端慢启动过程不再解释注意因为关闭了SACK功能因此TLP功能也不会使能因此server端在收到No7数据包的时候会重新启动RTO定时器后面也不会被改写为TLP定时器。发出No9后ssthresh15 cwnd4 packets_out4 sacked_out0 lost_out0 retrans_out0。No10RTO超时后server端从Open状态切换为Loss状态更新prior_ssthreshmax(ssthresh, cwnd*3/4)15 ssthreshmax(cwnd/2, 2)2 cwnd1并把No5、No6、No8、No9四个数据包标记为lostlost_out4接着重传No5数据包retrans_out1。并且当前满足使能FRTO的条件。No11-No13No11报文为client对No5的确认包server端收到No11报文后更新packets_out3 lost_out3retrans_out0发现当前使能了FRTO功能并且No11这个报文的ack number确认了新的数据包因此server端FRTO尝试发出新的未发送数据包此时cwnd1in_flight3-(30)00因此发出一个数据包即No12FRTO对这个ACK报文的处理结束。接着reno的慢启动更新cwnd2又发出一个新数据包即No13。最终packets_out5。No14server端收到No14报文后更新packets_out4lost_out2发现No14这个确认包相比No11又确认了新的数据包而且新确认的数据包是未曾重传过的No6数据包因此server端FRTO认定之前的No10重传为虚假超时重传接着进行拥塞撤销更新cwndmax(cwnd,2*ssthresh)4ssthresh max(ssthresh,prior_ssthresh)15并取消No8、No9数据包的lost标记更新lost0server端从Loss状态切换为Open状态。接着reno的慢启动更新cwnd5。No15-No16同样是延迟到达的ACK报文最终ssthresh15 cwnd7 packets_out2 sacked_out0 lost_out0 retrans_out0。No17No17是No10的确认包是一个dup ACKserver端收到No17后更新sacked_out1并从Open状态切换为Disorder状态此时满足sacked_out0 packets_out (sacked_out 1) packets_out 4这几个条件且没有待发送的新数据因此触发延迟ER设置ER定时器为RTT/4(大约为35ms)。处理完No17后ssthresh15 cwnd7 packets_out2 sacked_out1 lost_out0 retrans_out0。No18ER定时器超时后server端从Disorder状态切换到Recovery状态更新high_seq351 prior_ssthreshmax(ssthresh, cwnd*3/4)15 ssthreshmax(cwnd/2, 2)3并把No12数据包标记为lost更新lost_out1接着重传这个数据包即发出No18并更新retrans_out1 prr_out1。最终ssthresh3 cwnd7 packets_out2 sacked_out1 lost_out1 retrans_out1。注意ER定时器超时重传的时候并没有直接削减cwnd。No19-No20No19是一个partial ACK更新packets_out1 sacked_out0 lost_out0 retrans_out0SACK关闭场景下收到partial ACK会立即把partial ACK的ack number对应的数据包(即No13)标记为lost因而又更新lost_out1接着进入更新cwnd的流程注意这里newly_acked_sacked0 因此并不会更新cwnd 接着重传标记为lost的数据包即No20更新retrans_out1prr_out2。No21No21是No13数据包的确认包server端收到No21的时候更新packets_out0lost_out0retrans_out0Ack351high_seq即正好到达Recovery point但是因为此时SACK处于关闭状态因此server端并不会从Recovery状态切换到Open状态更新cwndmin(cwnd, in_flightdupthresh)3 最终处理完No21后ssthresh3 cwnd3 packets_out0 sacked_out0 lost_out0 retrans_out0 prr_delivered0 prr_out2。(No21数据包的处理请参考介绍SACK关闭场景拥塞撤销处理的文章)。No22-No23server端收到虚假重传的dup ACK的确认包最终处理完No23后server端处于Recovery状态ssthresh3 cwnd3 packets_out0 sacked_out0 lost_out0 retrans_out0 prr_delivered0 prr_out2。2、FRTO与TLP我们会在DSACK拥塞撤销的文章中用示例演示了server与client协商好TSopt后如果收到不带有TSopt选项的数据包虽然协议建议静默丢弃这种报文但是linux仍然正常接收处理。这个示例我们先来看一下client如果与server协商好SACK选项后而client侧代码bug或者其他原因导致收到乱序包后回复的dup ACK没有携带SACK信息时候server端会如何处理。同样在执行示例前如下设置相关TCP参数******Inspiron:~$sudo ip route add local 127.0.0.2 dev lo congctl reno initcwnd 5 ssthresh lock 4 #参考本系列destination metric文章******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后 ssthresh4 cwnd4cwnd_cnt1 packets_out5 sacked_out0 lost_out0 retrans_out0 fackets_out0server端处于Open状态并设置了TLP定时器PTO2*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。No17PTO定时器超时触发loss probe过程此时缓存中有待发送的新数据因此发出No17数据包更新packets_out6并取消PTO定时器设置成RTO定时器。No18server端收到No18后又会把RTO定时器重设为PTO定时器定时时间大约为100ms。No19-No24这几个数据包的处理与No17、No18类似。收到No24后重设PTO定时器定时时间为100ms。此时 ssthresh5 cwnd4cwnd_cnt1 packets_out9 sacked_out0 lost_out0 retrans_out0 fackets_out0server端处于Open状态注意此时cwnd4in_flight9可以看到loss probe报文并不会受到拥塞控制cwnd的限制。No25当PTO定时器再次超时的时候此时server端的缓存中已经没有待发送的新数据包因此重传最后发送的数据包(即No23)注意虽然No25发生了数据包的重传但是TLP重传后server端TCP仍然会停留在Open状态而且并不会更新lost_out等字段因此重传完No25后 ssthresh4 cwnd4cwnd_cnt1 packets_out9 sacked_out0 lost_out0 retrans_out0 fackets_out0server端TCP处于Open状态并且当前设置有RTO定时器。No26server端在收到No26这个dup ACK后的处理与No13类似最终会把RTO定时器重设为PTO定时器定时时间大约为100ms。No27No26设置的PTO定时器超时后发现当前已经有了一个TLP超时重传(即No25)因此不会在进行TLP尾包重传而是设置RTO定时器定时时间大约为250ms最终RTO超时触发No27重传此时server端由Open状态切换为Loss状态发出No27后以指数回退重设RTO定时器相关状态变量如下prior_ssthresh4 ssthresh2 cwnd1cwnd_cnt1 packets_out9 sacked_out0 lost_out9 retrans_out1 fackets_out0。No28No28的ack number确认了未重传的数据包因此触发FRTO拥塞撤销更新cwndmax(cwnd,2*ssthresh)4ssthresh max(ssthresh,prior_ssthresh)4同时server端从Loss状态切换为Open状态然后在Open状态下进入reno的拥塞避免过程No28的ack number新确认了9个数据包9/cwnd2因此更新cwndcwnd26cwnd_cnt9-2*41最终ssthresh4 cwnd6cwnd_cnt1 packets_out0 sacked_out0 lost_out9 retrans_out0 fackets_out0来自为知笔记(Wiz)转载于:https://www.cnblogs.com/lshs/p/6038792.html
