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则是汇报收到的数据碎版:

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

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

 

 

    原文作者:maple_wei
    原文地址: https://blog.csdn.net/zhanweizhao_111/article/details/106332923
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞