重传机制

超时重传机制

所谓的超时重传是指，我们在发送数据包之后，在一定时间内没有收到对应的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中状况：

1. 只重传超时的数据包，这种方法是最常想到的，比较实用与后面的数据包都能够正常接收的状况，只重传超时的数据包，但是如果比较坏的情况下，丢失了很多封包呢？ 那就需要一个一个的等待超时了，很浪费时间。

2. 重传这个片段以及之后的所有包，这种方法在最坏的状况下，看起来效率还是挺高的，但是如果只有一个包丢失，就去重传后面所有接受到的包，流量浪费也是很严重的，还会造成拥堵。

SACK机制：

SACK是一个TCP的选项，来允许TCP单独确认非连续的片段，用于告知真正丢失的包，只重传丢失的片段。要使用SACK，2个设备必须同时支持SACK才可以，建立连接的时候需要使用SACK Permitted的option，如果允许，后续的传输过程中TCP segment中的可以携带SACK option，这个option内容包含一系列的非连续的没有确认的数据的seq range。