网络的救命稻草:重传机制如何确保数据顺利传输?

举报
努力的小雨 发表于 2023/12/13 13:01:00 2023/12/13
【摘要】 在网络传输中,数据的可靠性和稳定性一直是一个重要的挑战。幸运的是,重传机制应运而生,为我们解决了这个问题。本文将深入探讨重传机制在网络中的应用和工作原理。我们将介绍TCP中最常见的超时重传和快速重传,以及SACK和D-SACK这两种高级重传机制。了解这些机制如何工作可以帮助我们更好地理解数据传输的可靠性和稳定性的保障。

重传机制

在设计架构或涉及网络时,我们都知道网络是不可靠的,可能会发生超时、断开连接、网络分区等各种问题。这些问题对于数据传输的可靠性和稳定性产生了很大的挑战。为了解决这些问题,各个组织都设立了专门的网络部门,致力于研究和解决网络问题。

TCP实现可靠传输的方式之一是通过序列号与确认应答。在TCP中,当发送端的数据包到达接收主机时,接收主机会返回一个确认应答消息,表示已经成功接收到数据。
image

然而,由于网络的不可靠性,有时候确认应答消息可能丢失或延迟到达。为了解决这个问题,TCP引入了重传机制。接下来说说常见的重传机制:

  • 超时重传:当发送端发送了一个数据包后,会启动一个定时器,等待接收端的确认应答。如果在指定的时间内没有收到确认应答,发送端会认为数据包丢失,然后重新发送该数据包。
  • 快速重传:在TCP中,如果发送端连续收到3个重复的确认应答,就会认为有一个数据包丢失了。此时,发送端会立即重传该数据包,而不再等待超时。
  • SACK:SACK是Selective Acknowledgement(选择性确认)的缩写,它允许接收端在确认应答中指定哪些数据包已经收到,哪些数据包还没有收到。这样,发送端就可以根据接收端的确认情况,有选择地进行重传。
  • D-SACK:D-SACK是Duplicate Selective Acknowledgement(重复选择性确认)的缩写,它允许接收端在确认应答中指定哪些数据包是重复接收的。发送端可以根据这些信息来判断哪些数据包需要重传。

超时重传

超时重传是TCP中最简单也是最常见的形式之一,它的工作原理如下:发送方在发送数据后会设定一个定时器,当超过一定时间后,如果发送方未收到接收方发送的ACK数据包,就会触发超时重传机制,即重新发送之前未收到ACK的数据包。

超时重传机制主要应用于以下两种情况中:

  1. 数据包未能到达接收方:在这种情况下,接收方无法发送ACK确认,因为它根本没有收到数据包。
  2. 接收方发送的ACK丢失:在这种情况下,接收方确实接收到了数据包并发送了ACK,但ACK在网络传输过程中丢失了。

image

如果超时重发的数据,再次超时的时候,又需要重传的时候,TCP 会将下一次超时时间间隔设为先前值的两倍。通过将超时时间间隔加倍,TCP 在网络不稳定时能够适当延长等待时间,以期待数据包能够成功传输。这种策略的目的是避免过早地重传数据,从而减少网络拥塞和带宽浪费。

通过观察上述两种情况,我们需要记住:网络传输是双向的,因此在任何时候都需要考虑发送方和接收方之间的传输线路。这样,我们就可以更好地理解下面要介绍的几种重传机制。

超时触发重传存在的一个问题是,超时周期可能相对较长,导致数据传输的延迟。为了解决这个问题,我们可以采用「快速重传」机制,从而缩短重传的等待时间。

快速重传

TCP还有一种称为快速重传(Fast Retransmit)的机制,它不是基于时间而是基于数据的驱动重传。快速重传机制的工作原理其实非常简单,我用一张图来说明:

image

在上图中,发送方发送了1、2、3、4、5五份数据:

  1. 第一份数据Seq1先到达接收方,接收方发送了Ack2回应;
  2. 由于某些原因,第二份数据Seq2未到达,但第三份数据Seq3到达了,接收方仍然发送了Ack2回应;
  3. 后面的Seq4和Seq5都到达了,但接收方仍然发送了Ack2回应,因为Seq2还未到达;
  4. 发送方收到了三个Ack=2的确认,意识到Seq2还未到达,于是在定时器过期之前,重传了丢失的Seq2;
  5. 最后,接收方收到了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段。

image

请记住,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机制一样重发实际上缺少的数据包。

如下图所示:
image

  • 接收方发送给发送方的两个ACK确认应答都丢失了,所以发送方超时后重传了第一个数据包(3000~3499)。
  • 接收方发现数据是重复收到的,于是回复了一个SACK=3000-3500,告诉发送方3000-3500的数据已经被接收了。因为ACK已经到了4000,意味着4000之前的所有数据都已收到,所以这个SACK代表着D-SACK。
  • 这样发送方就知道数据没有丢失,是接收方的ACK确认报文丢失了。此时,发送方就不会再重发剩下的数据包,从而减少了多余的网络传输。

第二种情况:网络延时

image

  • 在发送方发送的数据包(1000-1499)经历了网络延迟,导致发送方未收到Ack 1500的确认报文。
  • 随后,接收方收到了延迟的数据包(1000-1499)并触发了快速重传机制,随后接收方发送了三个相同的ACK确认报文。
  • 由于ACK已经到达3000,接收方在回复中包含了SACK=1000~1500,表示接收方收到了重复的数据包,所以这个 SACK 是 D-SACK,表示收到了重复的包。
  • 这样发送方就明白,快速重传机制被触发的原因不是因为发送出去的数据包丢失,也不是因为回复的ACK丢失,而是由于网络延迟的存在。

可以看出,D-SACK(Duplicate Selective Acknowledgment)具有以下几个优点:

  1. 它可以提供给发送方有关丢包原因的信息,发送方可以知道是发送的数据包丢失了还是接收方的ACK包丢失了。
  2. 它可以帮助发送方判断是否由于网络延迟而导致数据包丢失。
  3. 它可以帮助发送方判断是否网络中的数据包被复制了。

在Linux系统中,可以通过设置net.ipv4.tcp_dsack参数来启用或禁用D-SACK功能(在Linux 2.4版本之后,默认为启用状态)。

总结

重传机制是为了解决网络不可靠性而存在的一种方法。TCP通过序列号与确认应答来实现可靠传输,但由于网络的问题,确认应答可能会丢失或延迟到达。为了解决这个问题,TCP引入了重传机制,包括超时重传、快速重传、SACK和D-SACK。

超时重传是最常见的重传机制,当发送端发送数据包后,等待一定时间内未收到确认应答时,会重新发送数据包。快速重传是基于数据的驱动重传,当发送端连续收到三个重复的确认应答时,会立即重传丢失的数据包。SACK允许接收端在确认应答中指定已收到的数据包,发送端可以根据这些信息有选择地进行重传。D-SACK则是在SACK的基础上,告知发送端哪些数据包是重复接收的。

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。