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

重传机制

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

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

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

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

超时重传

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

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

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

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

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

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

快速重传

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

在上图中，发送方发送了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段。

请记住，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）具有以下几个优点：

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

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

总结

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

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