移动网站开发入门企业名录软件

TCP快速重传机制为啥出现重复ACK

简单来说，丢失数据包后发送方至少发了三个请求，每个请求返回接收方下一次期待的序列号ACK，也就是丢失数据包之前的一个正常请求的确认ACK值

在 TCP（Transmission Control Protocol，传输控制协议）的快速重传机制中，当接收方收到三次相同的 ACK（Acknowledgment，确认）值时就会触发快速重传，之所以会出现这种情况以及它的原理如下：

一、正常的 TCP 确认机制回顾

在 TCP 通信中，发送方发送数据报文段后，接收方会对收到的报文段进行确认，发送 ACK 报文告知发送方已成功接收对应的数据。正常情况下，接收方按照顺序接收报文段，每收到一个报文段就回复一个对应的 ACK，发送方根据 ACK 来判断数据是否被正确接收，进而决定是否继续发送后续报文段等操作。

二、出现三次相同 ACK 的原因

过程：

• 数据丢失情况：假设发送方按顺序发送了报文段 1、报文段 2、报文段 3 等，其中报文段 2 在传输过程中丢失了（可能由于网络拥塞、链路故障等原因），接收方成功收到了报文段 1，但是一直没收到报文段 2，所以就没办法对报文段 3 及后续按顺序到达的报文段进行正常确认（因为 TCP 是面向字节流的可靠协议，要求按顺序接收数据）。

• 重复 ACK 的产生：当接收方收到报文段 3 时，由于它期望收到的是报文段 2，此时接收方并不会对报文段 3 进行正常的按序确认（也就是不会确认报文段 3 对应的序列号等内容），而是会再次发送一个对报文段 1 最后一个字节的确认 ACK（这个 ACK 对应的序列号其实就是报文段 1 最后一个字节的序列号），意思是告诉发送方 “我还在等报文段 2 呢，前面的报文段 1 我已经收到了”。之后，如果发送方继续发送了报文段 4、报文段 5 等，只要报文段 2 没到，接收方每次收到新的报文段后，都会重复发送这个针对报文段 1 的 ACK，就这样，当发送方连续收到三个相同的 ACK（都是针对报文段 1 最后一个字节的确认 ACK）时，就可以推断出报文段 2 大概率是丢失了。

三、快速重传及后续处理

• 快速重传触发：发送方一旦收到三次相同的 ACK，就不会傻傻地等到超时定时器到期（TCP 原本还有超时重传机制，如果等待足够长时间没收到 ACK 就重传数据，但超时时间相对较长），而是立即启动快速重传，重传那个被认为丢失的报文段（也就是上述例子中的报文段 2）。

• 资源利用合理性分析：虽然表面上看好像重传了可能接收方已经收到的数据（比如接收方后续可能已经收到了报文段 2，只是发送方还没等到相应的 ACK 就触发了快速重传），但实际上这种机制是非常有必要且高效的。因为相比一直等到超时定时器到期再重传（超时时间往往较长，会造成传输效率低下、延迟增加等问题），快速重传能够更快地对可能丢失的数据进行补发，尽早恢复正常的传输秩序，从整体的传输效率和减少延迟角度来看，它所带来的收益远远大于偶尔重传可能已经收到的数据这种小 “浪费”，而且网络环境中数据真正丢失的情况还是比较常见的，快速重传机制多数时候是在做有效的补救工作。

所以，三次相同 ACK 的出现是因为接收方在期望的报文段未按序到达时，通过重复发送之前已正确接收报文段对应的 ACK 来提醒发送方有数据丢失，发送方据此来触发快速重传机制，以保障 TCP 传输的可靠性和高效性。

• ACK也表示接收端下一次期望收到的序列号，就能解释为啥发送了后面的数据包，也可能返回前面丢失的确认应答。也能解释滑动窗口，不关心部分ACK信息丢失，只要确保最后一个ACK值，就能确定窗口中前部分请求接收到了