TCP 超时重传和快速重传有什么区别？SACK 为什么能减少重复发送？

知识点详解：中间一段没到，后面几段却先到了

ACK 报的是下一个期待字节，不是消息编号

先用一个简化例子：发送五段等长数据，字节区间依次是 [100,200)、[200,300)、[300,400)、[400,500)、[500,600)。

区间右端不包含在内。接收端收到 [100,200) 后，期待下一个字节 200，可以发 ACK=200。

这里的 200 是字节序号，不是“第 200 条业务消息”。TCP 不负责给应用消息划边界，拆帧问题在已有题目中另讲。

现在假设 [200,300) 丢了，后面三段却陆续到达。连续数据仍停在 200 前，接收端不能因为看见最后一段，就把缺口假装填上。

重复 ACK，把缺口线索带回发送方

每次收到后续乱序段，接收端可以继续告知目前期待 200。发送方看到重复的 ACK=200，就知道连续确认没有向前推进，但后续数据仍在到达。

经典 RFC 5681 快速重传以三个符合条件的重复 ACK 作为丢失线索，不必一直等 RTO 到期。

这里有个容易数错的地方：确认第一段的 ACK=200 是首次确认。后面三个乱序段各自引出的 ACK=200，才是三个重复 ACK，不能把第一次也算进去。

乱序、重复数据或 ACK 复制，也可能造成重复确认，所以这是恢复算法的判断规则，不是对网络现场的绝对证明。

没有足够后续数据，快速重传也可能等不到

假设丢掉的是最后一段，后面没有更多数据到达接收端，就可能没有足够重复 ACK 作为快速重传触发信号。

此时，超时重传仍然重要。它根据未被确认的数据和计时器推进恢复，而不是要求接收端主动知道发送方还有哪段丢了。

RFC 6298规定了 RTO 的计算与退避。它不是所有连接统一写死的一秒循环；需要结合往返时间测量及其变化，连续超时时还会退避。

ACK 丢了也可能让发送方重传已经到达的数据。接收端按序号识别重复，不需要把相同字节作为另一份新应用数据交付。

SACK 多带了一张“已收到区间”的清单

在中间缺 [200,300)、后面 [300,600) 已经到达时，仅有累积 ACK=200，主要说明连续确认停在哪里。

如果两端按约定启用 SACK，接收端还可以报告 [300,600) 这段已经收到。发送方因此拥有更具体的信息，能够重点处理缺口，而不是把所有尚未累积确认的数据都当成同样未知。

RFC 2018明确说明 SACK 不改变 ACK 字段的累积含义，它是附加区间信息。不是把 ACK=200 改成 ACK=600，跨过缺失部分。

SACK 的信息也需要实际恢复算法利用。它帮助更准确地判断重发范围，不保证网络再也丢包，也不意味着每次都完全不会重复发送。

快速重传、快速恢复、拥塞控制，不能全叫重发

快速重传回答“何时先重发疑似缺失段”。

快速恢复和拥塞控制还会调整发送节奏，避免在可能拥塞的网络上继续无节制发送。两者有联系，但不是同一动作的两个名字。

现代实现还可能结合其他丢失检测机制。面试如果问经典算法，可以先说明经典三个重复 ACK；如果问 Linux 某版本的实际表现，就要核对该版本、配置和协议选项，不能只背教材输出固定结论。

为什么 TCP 可靠，也不能证明一次订单已经成功？

TCP ACK 说明相应字节在传输层的接收进展，不保证应用已经完成解析、数据库提交或业务处理。

假设客户端已经把请求发出，等待业务响应时超时。可能是服务端没处理，也可能是处理完成后响应延迟或丢失。

因此，应用重复写入需要自己的请求身份和幂等规则。TCP 重传一般负责同一连接的字节恢复，应用重试则可能发起一次新的业务请求，不能把两者混为同一种去重。

面试官继续追问

没收到 ACK，就表示数据一定丢了吗？

不一定。数据、ACK 或路径延迟都可能影响确认。发送方按已有信号处理未知状态。

三个重复 ACK 是所有 TCP 实现唯一重传条件吗？

不是。它是经典快速重传规则。实际恢复机制还受实现版本和协商能力影响。

SACK 可以解决粘包吗？

不能。它帮助传输层报告收到的字节区间，不提供业务消息边界。应用仍需自己的帧格式。

面试速记卡

• 序号：TCP 按字节跟踪，ACK 表示下一期待字节。
• 超时重传：等待确认到期后恢复，RTO 根据测量并可退避。
• 快速重传：经典规则利用三个重复 ACK 提前识别缺口。
• SACK：补充已收到的非连续区间，不改变累积 ACK。
• 业务边界：传输确认不等于处理成功，应用重试另需幂等。