RACK为TCP BBR提供动力源

2016-10-22 10:04:29来源:作者:一蓑烟雨任平生人点击

第七城市

先从需求谈起吧。

在上一篇文章《 Google's BBR TCP拥塞控制算法的四个变速引擎》的最后,我提到bbr算法作为一个标称功率十足的引擎需要源源不断的能源供给,而这类能源就是数据包。又提到,TCP的快速重传机制几乎只会将判断为LOST的数据包重传一次,因此当重传数据包再次丢失,滑动窗口无法滑动的时候,将会无法提供数据包发送,bbr引擎就会失速,此时只能等待TCP的超时!当然,超时的代价有点大,不单单是对于拥塞控制而言,对于整个连接而言,都无异于异常劫难!

因此,bbr需要源源不断的数据包供给它开大马力运行,bbr并不在乎这些数据包是新数据包,标记为LOST的数据包,重传过的数据包,甚至是构造的错包...只要有数据包即可!bbr真正彻底实现了拥塞控制与数据包标记/发送之间解耦合。

说完了需求,再谈方案。

Linux内核在bbr之前就已经引入了RACK机制,旨在快速发现并重传那些曾经重传后再次丢失的数据包,这些数据包的处理至关重要,如果不及时处理,便会陷入RTO的深渊。当然,RTO的回调在你自己手上,你也可以处理得不那么激进,然而对于已经失速的连接,继续勉强撑着也算是自欺欺人了...RACK解决了这个问题。然而bbr之前的RACK并没有获得最大收益,原因在于虽然RACK可以即时地探知哪些数据包丢失,特别是那些重传后再次丢失的数据包,但是由于此时拥塞窗口的计算已经固定地朝着ssthresh的方向PRR跌落下去,受限于拥塞窗口,即时准备再多的可发送数据也无法着实发送出去!bbr引擎可以即时消化掉RACK送上来的能源,二者配合就开启了一台动力十足的高端引擎。

RACK(请先看 这个draft)从名字上看,Recent ACK,即最近的ACK,当然也包括SACK,因此正确的名字应该是Recent (s)ACK,RACK并不记录数据被(s)ACK的时间,而是在收到ACK的时候,记录被该ACK确认的数据包的发送时间,在这些发送时间中取Recent,即最晚发送的。RACK的思想是,记录这个Recent (s)ACK所确认数据包的发送时间T.rack,然后给定一个时间窗口twin,在时间T.rack-twin之前发送的未被确认的数据包均被标记为LOST,然后这些数据包会被交给发送逻辑去发送。这非常符合常理。

RACK的代码超级简单,核心逻辑就一个文件两个函数,位于net/ipv4/tcp_recovery.c中的:

/* * 在一次(s)ACK的处理过程中更新被确认的数据包的最晚发送时间rack.mstamp。 * xmit_time-当前处理的被确认的数据包的发送时间 * sacked-当前处理的被确认的数据包的sacked标记,被选择确认过吗?被重传过吗?等等。 */void tcp_rack_advance(struct tcp_sock *tp, const struct skb_mstamp *xmit_time, u8 sacked);/* * 根据tcp_rack_advance记录的最晚发送的被确认的数据包的发送时间rack.mstamp以及 * 重传队列里未被选择确认的数据包的发送时间skb.mstamp的差,判断是否标记为LOST。 * RACK内置有一个twin,凡是符合rack.mstamp-skb.mstamp>twin的数据包,均标记为LOST。 * 如果该数据包被重传过,那么清除其被重传过的印记! */int tcp_rack_mark_lost(struct sock *sk);

以上就是关于RACK的两个接口,TCP在处理ACK的时候会调用这两个接口:

1).处理ACK携带的信息(TCP头的ACK号或者选项中sACK块)时调用tcp_rack_advance;

这个RACK机制的简单性就在于,它不再区分正常的顺序ACK以及SACK,它只比较时间戳,不管发送顺序如何,只基于确认携带的信息来决定一个数据包是不是要被重传。以下面的序列为例:

1|2|3|4|5|6|7|8|

假设一个ACK确认了4,那么UNA则是5,假设这个ACK没有携带SACK信息,只是确认了4,那么rack.mstamp就是4发送的时间了,现在的问题是,4之后的5,6,7,8怎么可能在4之前发送呢?它明明是位于4之后的啊!RACK的简单性就体现在这里!5,6,7,8虽然在4后面但是谁也不能保证它们就一定是按照序列号顺序发送的,更加合理的做法是记录发送时间序列!典型的场景是,4,5,6,7,8均是重传过的数据包,首先重传了7,8,然后重传了6,然后重传4,最后重传5,这样发送的时间序列就是:

1|2|3|7|8|6|4|5|

现在4被确认了,按照上述时间序,我有理由继续等待5的确认到来,因为5是在4之后发送的,然而7,8,6却都是在4之前发送的,到底等不等呢?这里7是最先发送的,要判断skb7.mstamp与rack.mstamp之间的差值了,如果大于twin,说明继续等待7的选择确认是不可忍受的,反之,如果在twin之内,那么便有理由继续等待了,可能是乱序了!同样的策略处理8和6。

这样处理是不是更加简单些呢?只需要按照时间序比较数据包最近一次的发送时间与rack.mstamp之间的差即可!完全忽略这个数据包是不是曾经被重传过,这样就解决了按照序列号进行LOST判断的复杂性问题。

然而,在乱序的情况下,你可能会认为RACK机制可能会误传很多并未丢失(实际上是乱序到达或者ACK乱序反馈)的数据包,事实上这里就体现了twin时间窗口的作用,RACK的时间序并非严格的时间序,它是一个带有缓冲的准时间序机制。就算你认为twin也没用,再不济你也可以将RACK关掉的!

注意twin的选择,一般而言是最小RTT的1/4,这里的最小RTT是与SRTT无关的,它是真实测量出来的离散RTT的win_minmax(请在《 Google's BBR TCP拥塞控制算法的四个变速引擎》看win_minmax详情)最小值,基于一个自动向后滑动的时间窗口采样的最小RTT,这里的主要目的不是平滑掉噪点(这有点像鸵鸟策略...),而是过滤掉非拥塞导致的抖动,这是一种主动发现噪点的行为,可以将 BufferBloat的影响最小化。

有了RACK机制,bbr再也不用为无包可发这种事发愁了。

只要bbr可以根据(s)ACK采集到带宽和RTT,那么bbr就可以根据这些带宽,RTT的反馈全速率运行,而能让带宽和RTT反馈回来的,正是发出去的包,再次重申,无论是新包还是重传包,只要发送去,它们都可以反馈回结果,不管是ACK,SACK,还是DSACK...我们又绕回来了,RACK机制即使在已经发生丢包/乱序等事件时也能提供源源不断的可发送的数据包(即标记为LOST的数据包)。这个过程平滑的运行,不必再等待RTO超时!

在bbr之前,一旦发生丢包或者严重乱序,TCP就会接管拥塞控制算法,但现在不了!以前的做法是错误的,所谓的丢包,乱序,这些都是TCP的拥塞控制状态机逻辑自己猜的,相当大程度是不真实的,任何算法都无法准确猜出是不是真的发生了丢包,想欺骗一只蝙蝠撞墙是很容易的,同样,TCP也是一个瞎子!所以,bbr的做法是正确的:

bbr算法本身: 计算发送速率和窗口。

TCP拥塞控制状态机: 准备新数据,标记LOST(传统方式以及RACK方式),即提供可传输的数据包,灌入bbr算法提供的食道。

TCP传输逻辑: 实际传输任何可以传输的数据包,新的数据包,所有标记为LOST的数据包。

以上3者相互配合,回答了 ”传输多少?“,”传输什么?“,”怎么传输?“ 等问题,并且三者之间完全基于当下的(s)ACK反馈来交互,彼此之间则完全独立。

...

接下来干什么?

接下来我来吐个槽,事情要从工业革命后,人们企图将蒸汽机装在马车上开始...

第七城市

最新文章

123

最新摄影

微信扫一扫

第七城市微信公众平台