重传机制
在设计架构或涉及网络时,我们都知道网络是不可靠的,可能会发生超时、断开连接、网络分区等各种问题。这些问题对于数据传输的可靠性和稳定性产生了很大的挑战。为了解决这些问题,各个组织都设立了专门的网络部门,致力于研究和解决网络问题。
TCP实现可靠传输的方式之一是通过序列号与确认应答。在TCP中,当发送端的数据包到达接收主机时,接收主机会返回一个确认应答消息,表示已经成功接收到数据。
然而,由于网络的不可靠性,有时候确认应答消息可能丢失或延迟到达。为了解决这个问题,TCP引入了重传机制。接下来说说常见的重传机制:
- 超时重传:当发送端发送了一个数据包后,会启动一个定时器,等待接收端的确认应答。如果在指定的时间内没有收到确认应答,发送端会认为数据包丢失,然后重新发送该数据包。
- 快速重传:在TCP中,如果发送端连续收到3个重复的确认应答,就会认为有一个数据包丢失了。此时,发送端会立即重传该数据包,而不再等待超时。
- SACK:SACK是Selective Acknowledgement(选择性确认)的缩写,它允许接收端在确认应答中指定哪些数据包已经收到,哪些数据包还没有收到。这样,发送端就可以根据接收端的确认情况,有选择地进行重传。
- D-SACK:D-SACK是Duplicate Selective Acknowledgement(重复选择性确认)的缩写,它允许接收端在确认应答中指定哪些数据包是重复接收的。发送端可以根据这些信息来判断哪些数据包需要重传。
超时重传
超时重传是TCP中最简单也是最常见的形式之一,它的工作原理如下:发送方在发送数据后会设定一个定时器,当超过一定时间后,如果发送方未收到接收方发送的ACK数据包,就会触发超时重传机制,即重新发送之前未收到ACK的数据包。
超时重传机制主要应用于以下两种情况中:
- 数据包未能到达接收方:在这种情况下,接收方无法发送ACK确认,因为它根本没有收到数据包。
- 接收方发送的ACK丢失:在这种情况下,接收方确实接收到了数据包并发送了ACK,但ACK在网络传输过程中丢失了。
如果超时重发的数据,再次超时的时候,又需要重传的时候,TCP 会将下一次超时时间间隔设为先前值的两倍。通过将超时时间间隔加倍,TCP 在网络不稳定时能够适当延长等待时间,以期待数据包能够成功传输。这种策略的目的是避免过早地重传数据,从而减少网络拥塞和带宽浪费。
通过观察上述两种情况,我们需要记住:网络传输是双向的,因此在任何时候都需要考虑发送方和接收方之间的传输线路。这样,我们就可以更好地理解下面要介绍的几种重传机制。
超时触发重传存在的一个问题是,超时周期可能相对较长,导致数据传输的延迟。为了解决这个问题,我们可以采用「快速重传」机制,从而缩短重传的等待时间。
快速重传
TCP还有一种称为快速重传(Fast Retransmit)的机制,它不是基于时间而是基于数据的驱动重传。快速重传机制的工作原理其实非常简单,我用一张图来说明:
在上图中,发送方发送了1、2、3、4、5五份数据:
- 第一份数据Seq1先到达接收方,接收方发送了Ack2回应;
- 由于某些原因,第二份数据Seq2未到达,但第三份数据Seq3到达了,接收方仍然发送了Ack2回应;
- 后面的Seq4和Seq5都到达了,但接收方仍然发送了Ack2回应,因为Seq2还未到达;
- 发送方收到了三个Ack=2的确认,意识到Seq2还未到达,于是在定时器过期之前,重传了丢失的Seq2;
- 最后,接收方收到了Seq2,此时因为Seq3、Seq4、Seq5都已经收到,接收方发送了Ack6回应。
至于为什么每次都返回的是ACK=2,而不是下一个返回当前Seq+1,是因为在快速重传机制中,接收方只返回对最后一个按序接收的数据的ACK。当接收方发现有数据丢失时,会重复发送对丢失数据前一个按序接收的数据的ACK,以触发发送方进行快速重传。因此,每次返回的ACK是重复的,以便发送方能够快速识别出数据丢失并进行重传。
因此,在快速重传的工作方式中,当收到三个相同的ACK报文时,发送端会在定时器过期之前重传丢失的报文段。虽然快速重传机制解决了超时时间的问题,但它仍然面临着另一个问题,即在重传时是重传之前的一个报文还是重传所有的报文。
举个例子,对于上述情况,是重传Seq2呢?还是重传Seq2、Seq3、Seq4、Seq5呢?发送端并不清楚这连续的三个ACK2是由哪个传回的。
根据TCP的不同实现,以上两种情况都有可能发生。这就是一把双刃剑。为了解决不知道重传哪些TCP报文的问题,SACK方法应运而生。
SACK 方法
还有一种实现重传机制的方式叫做选择性确认(Selective Acknowledgment,SACK)。SACK需要在TCP头部的"选项"字段中添加一个SACK选项,通过该选项发送缓存地图给发送方,从而让发送方知道哪些数据已经收到,哪些数据还未收到。有了这些信息,发送方就可以只重传丢失的数据。
如下图所示,当发送方收到三次相同的确认报文时,就会触发快速重传机制。通过SACK信息,发送方发现只有200~299这一段数据丢失,因此在进行重传时,只选择重复发送这个TCP段。
请记住,SACK记录的始终是当前接收到的数据包的序列号,不像ACK必须按顺序进行。乱序接收也是可以的。此外,还需要注意ACK和SACK这两个值的大小关系。在SACK机制中,ACK的值永远小于SACK的值。
要支持SACK,必须双方都要支持。在Linux系统下,可以通过设置net.ipv4.tcp_sack参数来开启该功能(从Linux 2.4版本开始,默认就是开启的)。
Duplicate SACK
看起来SACK已经很完美了,没有什么需要解决的了。但是你可以想象一下这种网络情况:发送方的数据实际上已经全部到达接收方,但是接收方却没有发送任何ACK应答数据包给发送方。这会导致发送方超时重传,首先触发的是序列号较小的数据包。接收方接收到了重复的数据包并返回给发送方,但是SACK的值小于ACK的值,这与SACK机制不同。你可以看到,D-SACK机制主要使用SACK来告知发送方哪些数据包已被重复接收,而不是像SACK机制一样重发实际上缺少的数据包。
如下图所示:
- 接收方发送给发送方的两个ACK确认应答都丢失了,所以发送方超时后重传了第一个数据包(3000~3499)。
- 接收方发现数据是重复收到的,于是回复了一个SACK=3000-3500,告诉发送方3000-3500的数据已经被接收了。因为ACK已经到了4000,意味着4000之前的所有数据都已收到,所以这个SACK代表着D-SACK。
- 这样发送方就知道数据没有丢失,是接收方的ACK确认报文丢失了。此时,发送方就不会再重发剩下的数据包,从而减少了多余的网络传输。
第二种情况:网络延时
- 在发送方发送的数据包(1000-1499)经历了网络延迟,导致发送方未收到Ack 1500的确认报文。
- 随后,接收方收到了延迟的数据包(1000-1499)并触发了快速重传机制,随后接收方发送了三个相同的ACK确认报文。
- 由于ACK已经到达3000,接收方在回复中包含了SACK=1000~1500,表示接收方收到了重复的数据包,所以这个 SACK 是 D-SACK,表示收到了重复的包。
- 这样发送方就明白,快速重传机制被触发的原因不是因为发送出去的数据包丢失,也不是因为回复的ACK丢失,而是由于网络延迟的存在。
可以看出,D-SACK(Duplicate Selective Acknowledgment)具有以下几个优点:
- 它可以提供给发送方有关丢包原因的信息,发送方可以知道是发送的数据包丢失了还是接收方的ACK包丢失了。
- 它可以帮助发送方判断是否由于网络延迟而导致数据包丢失。
- 它可以帮助发送方判断是否网络中的数据包被复制了。
在Linux系统中,可以通过设置net.ipv4.tcp_dsack参数来启用或禁用D-SACK功能(在Linux 2.4版本之后,默认为启用状态)。
总结
重传机制是为了解决网络不可靠性而存在的一种方法。TCP通过序列号与确认应答来实现可靠传输,但由于网络的问题,确认应答可能会丢失或延迟到达。为了解决这个问题,TCP引入了重传机制,包括超时重传、快速重传、SACK和D-SACK。
超时重传是最常见的重传机制,当发送端发送数据包后,等待一定时间内未收到确认应答时,会重新发送数据包。快速重传是基于数据的驱动重传,当发送端连续收到三个重复的确认应答时,会立即重传丢失的数据包。SACK允许接收端在确认应答中指定已收到的数据包,发送端可以根据这些信息有选择地进行重传。D-SACK则是在SACK的基础上,告知发送端哪些数据包是重复接收的。
我是努力的小雨,一名 Java 服务端码农,潜心研究着 AI 技术的奥秘。我热爱技术交流与分享,对开源社区充满热情。同时也是一位腾讯云创作之星、阿里云专家博主、华为云云享专家、掘金优秀作者。
💡 我将不吝分享我在技术道路上的个人探索与经验,希望能为你的学习与成长带来一些启发与帮助。
🌟 欢迎关注努力的小雨!🌟