TCP重传机制

TCP重传机制

TCP要保证所有的数据包都可以到达,所以,必需要有重传机制。

注意,接收端给发送端的ACK只会确认最后一个连续的包。比如,发送端发了#1,#2,#3,#4,#5一共五份数据,接收端收到了#1,#2,于是返回ACK=3,然后收到了#4(#3未收到),此时的TCP会怎么办?我们要知道,seqACK是以字节数为单位,所以返回ack的时候,不能跳着确认,只能确认最大的连续收到的包,不然,发送端就以为之前的都收到了。

超时重传机制

一种是不返回ack,死等#3,当发送方发现收不到#3的ack超时后,会重传#3。一旦接收方收到#3后,会ack返回4——意味着#3和#4都收到了。

但是,这种方式会有比较严重的问题,那就是因为要死等#3,所以会导致#4和#5即便已经收到了,而发送方也完全不知道发生了什么事,因为没有收到ACK,所以,发送方可能会悲观地认为也丢了,所以有可能也会导致4#和#5的重传。

对此有两种选择:

  1. 仅重传 timeout 的包。也就是第3份数据。
  2. 重传 timeout 后所有的数据,也就是#3,#4,#5这三份数据。

第一种会节省带宽,但是慢;第二种会快一点,但是会浪费带宽,也可能会做无用功。但总体来说都不好。因为都在等 timeout,timeout 可能会很长。

快速重传机制

于是,TCP引入了一种叫 Fast Retransmit 的算法,不以时间驱动,而以数据驱动重传。也就是说,如果包没有连续到达,就ack最后那个可能被丢了的包,如果发送方连续收到3次相同的ack,就重传。Fast Retransmit 的好处是不用等 timeout 了再重传。

比如:如果发送方发出了#1,#2,#3,#4,#5份数据,第一份先到送了,于是就ack回2,结果#2因为某些原因没收到,3到达了,于是还是ack回2,后面的#4和#5都到了,但是还是ack回#2,因为2还是没有收到,于是发送端收到了三个ack=2的确认,知道了#2还没有到,于是就马上重传#2。然后,接收端收到了#2,此时因为#3,#4,#5都收到了,于是ack回6。示意图如下:快速重传机制

Fast Retransmit 只解决了一个问题,就是timeout 的问题,它依然面临一个艰难的选择,就是重传之前的一个,还是重传所有的问题。对于上面的示例来说,是重传#2呢,还是重传#2,#3,#4,#5呢?因为发送端并不清楚这连续的3个ack(#2)是谁传回来的?也许发送端发了20份数据,是#6,#10,#20传来的呢。这样,发送端很有可能要重传从#2到#20的这堆数据(这就是某些TCP的实际的实现)。可见,这是一把双刃剑。

SACK 方法

另外一种更好的方式叫:Selective Acknowledgment (SACK)(参看RFC 2018),这种方式需要在TCP头里加一个SACK的东西,ACK还是Fast RetransmitACK,SACK则是汇报收到的数据碎版。参看下图:SACK

这样,在发送端就可以根据回传的SACK来知道哪些数据到了,哪些没有到。于是就优化了Fast Retransmit 的算法。当然,这个协议需要两边都支持。在 Linux下,可以通过tcp_sack参数打开这个功能(Linux 2.4后默认打开)。

这里还需要注意一个问题——接收方Reneging,所谓Reneging的意思就是接收方有权把已经报给发送端SACK里的数据给丢了。这样干是不被鼓励的,因为这个事会把问题复杂化了,但是,接收方这么做可能会有些极端情况,比如要把内存给别的更重要的东西。所以,发送方也不能完全依赖SACK,还是要依赖ACK,并维护Timeout,如果后续的ack没有增长,那么还是要把SACK的东西重传,另外,接收端这边永远不能把SACK的包标记为ACK

注意:SACK会消费发送方的资源,,试想,如果一个攻击者给数据发送方发一堆SACK的选项,这会导致发送方开始要重传甚至遍历已经发出的数据,这会消耗很多发送端的资源。详细的东西请参看《TCP SACK的性能权衡》

Duplicate SACK – 重复收到数据的问题

Duplicate SACK又称D-SACK,其主要使用了 SACK来告诉发送方有哪些数据被重复接收了。RFC-2833 里有详细描述和示例。下面举几个例子(来源于RFC-2833)

D-SACK使用了SACK的第一个段来做标志,如果SACK的第一个段的范围被ACK所覆盖,那么就是D-SACK;如果SACK的第一个段的范围被SACK的第二个段覆盖,那么就是D-SACK

示例一:ACK丢包

下面的示例中,丢了两个ACK,所以,发送端重传了第一个数据包(3000-3499),于是接收端发现重复收到,于是回了一个SACK=3000-3500,因为ACK都到了#4000意味着收到了#4000之前的所有数据,所以这个SACK就是D-SACK——旨在告诉发送端我收到了重复的数据,而且我们的发送端还知道,数据包没有丢,丢的是ACK包。

Transmitted Received ACK Sent
Segment Segment (Including SACK Blocks)
3000-3499 3000-3499 3500 (ACK dropped)
3500-3999 3500-3999 4000 (ACK dropped)
3000-3499 3000-3499 4000, SACK=3000-3500
示例二:网络延误

下面的示例中,网络包(1000-1499)被网络给延误了,导致发送方没有收到ACK,而后面到达的三个包触发了Fast Retransmit 算法,所以重传,但重传时,被延误的包又到了,所以,回了一个SACK=1000-1500,因为ACK已到了#3000,所以,这个SACKD-SACK——标识收到了重复的包。

这个案例下,发送端知道之前因为“Fast Retransmit算法”触发的重传不是因为发出去的包丢了,也不是因为回应的ACK包丢了,而是因为网络延时了。

Transmitted Received ACK Sent
Segment Segment (Including SACK Blocks)
500-999 500-999 1000
1000-1499 (delayed)
1500-1999 1500-1999 1000, SACK=1500-2000
2000-2499 2000-2499 1000, SACK=1500-2500
2500-2999 2500-2999 1000, SACK=1500-3000
1000-1499 1000-1499 3000
1000-1499 3000, SACK=1000-1500

可见,引入了D-SACK,有这么几个好处:

  1. 可以让发送方知道,是发出去的包丢了,还是回来的ACK包丢了。
  2. 是不是自己的 timeout太小了,导致重传。
  3. 网络上出现了先发的包后到的情况(又称reordering)
  4. 网络上是不是把我的数据包给复制了。

知道这些东西可以很好得帮助TCP了解网络情况,从而可以更好的做网络上的流控。
Linux下的tcp_dsack参数用于开启这个功能(Linux 2.4后默认打开)


转载自:http://www.uml.org.cn/safe/201407041.asp?artid=2511 作者:火龙果软件