超时重传机制
所谓的超时重传是指,我们在发送数据包之后,在一定时间内没有收到对应的ACK的时候,发送端会认为这个数据包已经丢失,那么这个时候就会重新去发送一个数据包。
检测丢失segment的方法从概念上讲还是比较简单的,每一次开始发送一个TCP segment的时候,就启动重传定时器,定时器的时间一开始是一个预设的值(Linux 规定为1s),随着通讯的变化以及时间的推移,这个定时器的溢出值是不断的在变化的,有相关算法计算RTO。如果在ACK收到之前,定时器到期,协议栈就会认为这个片段被丢失,重新传送数据
在实现超时重传的时候,我们会将被发送的数据段放在一个窗口中等待被确认。没有确认的数据是不会移走的。只有在接收到ACK的时候才会移开。如果在一定时间后还没有接收到ACK那么就会重新发送。
快速重传机制
在超时重传中,重点是定时器溢出超时了才认为发送的数据包丢失,快速重传机制,实现了另外的一种丢包评定标准,即如果我连续收到3次dup ACK,发送方就认为这个seq的包丢失了,立刻进行重传,这样如果接收端回复及时的话,基本就是在重传定时器到期之前,提高了重传的效率。
在传输过程中会出现out-of-order的现象,但是在滑动窗口中会有严格的顺序控制,假设有4,5,6三个待接收的数据包,先收到了5,6,协议栈是不会回复对5,6包的确认,而是根据TCP协议的规定,当接收方收到乱序片段时,需要重复发送ACK, 在这个地方会发送报文4 seq的ACK,表明需要报文4没有被接收到,如果此后收到的是报文7,那么仍然要回报文4 seq的ACK,如果连续发送3个 dup ACK,接收端认为这个片段已经丢失,进行快速重传。
SACK机制
快速重传和超时重传都会面临到一个重传什么包的问题,因为发送端也不清楚丢失包后面传送的数据是否有成功的送到。主要原因还是对于TCP的确认系统,不是特别的好处理这种不连续确认的状况了,只有低于ACK number的片段都被收到才有进行ACK,out-of-order的片段只能是等待,同时,这个时间窗口是无法向右移动的。
正式因为后续OUT-OF-ORDER的报文段的发送状况也不清楚,所以Server也不是特别清楚要如何去处理这种状况,不过一般来说只能有2中状况:
-
只重传超时的数据包,这种方法是最常想到的,比较实用与后面的数据包都能够正常接收的状况,只重传超时的数据包,但是如果比较坏的情况下,丢失了很多封包呢? 那就需要一个一个的等待超时了,很浪费时间。
-
重传这个片段以及之后的所有包,这种方法在最坏的状况下,看起来效率还是挺高的,但是如果只有一个包丢失,就去重传后面所有接受到的包,流量浪费也是很严重的,还会造成拥堵。
SACK机制:
SACK是一个TCP的选项,来允许TCP单独确认非连续的片段,用于告知真正丢失的包,只重传丢失的片段。要使用SACK,2个设备必须同时支持SACK才可以,建立连接的时候需要使用SACK Permitted的option,如果允许,后续的传输过程中TCP segment中的可以携带SACK option,这个option内容包含一系列的非连续的没有确认的数据的seq range。