TCP协议(二) 重传 乱序和丢包

TCP重传机制

接收端给发送端的Ack确认只会确认最后一个连续的包，比如，发送端发了1,2,3,4,5一共五份数据，接收端收到了1，2，于是回ack 3，然后收到了4和5。

1)超时重传

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

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

对此有两种选择：

• 一种是仅重传timeout的包。也就是第3份数据。
• 另一种是重传timeout后所有的数据，也就是第3，4，5这三份数据。

第一种会节省带宽，但是慢(原因是直到超时，重传3)；

第二种会快一点，但是会浪费带宽，也可能会有无用功。

2）快速重传机制

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

比如：如果发送方发出了1，2，3，4，5份数据，1和2先到了，于是就ack回3，结果3因为某些原因没收到，4到达了，于是还是ack回3，后面的4和5都到了，但是还是ack回3，因为3还是没有收到，于是发送端收到了三个ack=3的确认，知道了3还没有到，于是就马上重转3。然后，接收端收到了3，此时因为4，5都收到了，于是ack回6。

3）选择重传

Selective Acknowledgment (SACK) 这种方式需要在TCP头里加一个SACK的东西，ACK还是Fast Retransmit的ACK，SACK则是汇报收到的数据碎版：

这样，在发送端就可以根据回传的SACK来知道哪些数据到了，哪些没有到。于是就优化了Fast Retransmit的算法。当然，这个协议需要两边都支持。