题目是

> 当（29）时，`TCP` 启动快重传。  
> A. 重传计时器超时  
> B. 连续收到同一段的三次应答  
> C. 出现拥塞  
> D. 持续计时器超时

正确答案是

**B，连续收到同一段的三次应答。**

如果按照 `TCP` 标准中的严格说法来描述，B 选项最好写成

**发送方连续收到 3 个重复 `ACK` 时，触发快重传。**

题目里的「连续收到同一段的三次应答」实际上就是在表达这个意思。经典 `TCP Reno` 所采用的快重传算法，会把连续出现的 `3` 个重复 `ACK` 看成某个报文段很可能已经丢失的信号，因此不再等待 `RTO` 重传定时器超时，而是直接重传推测丢失的那个报文段。`RFC 5681` 对这一行为有非常明确的规定，快重传使用 `3 duplicate ACKs` 来判断报文段可能丢失，并且无需等待重传定时器到期。

理解这道题，真正需要抓住的是两个字，**快**。

正常情况下，`TCP` 并不会因为发送出去一个数据段以后暂时没有收到确认，就立刻再发一次。否则网络稍微出现一点延迟，发送方就会不断制造重复数据。

所以 `TCP` 设置了重传计时器。

发送数据以后，发送方等待 `ACK`。如果经过一段时间仍然没有得到有效确认，重传计时器达到 `RTO`，也就是 `Retransmission Timeout`，发送方才会进行超时重传。

这种办法很可靠，却存在一个明显的问题。

假设网络已经通过后续数据明确告诉发送方，中间某一段数据丢失了，如果仍然坚持等到 `RTO` 超时再处理，就浪费了时间。

快重传正是为了减少这一段等待时间。

我们可以直接按照一个真实的 `TCP` 数据流来观察。

假设发送方连续发送下面几个数据段，每个数据段携带 `1000 Byte` 数据。

```text
段 1    Seq = 1000    数据范围 1000 ～ 1999
段 2    Seq = 2000    数据范围 2000 ～ 2999
段 3    Seq = 3000    数据范围 3000 ～ 3999
段 4    Seq = 4000    数据范围 4000 ～ 4999
段 5    Seq = 5000    数据范围 5000 ～ 5999
```

假设段 `1` 正常到达。

接收方已经获得 `1000 ～ 1999`，所以下一个希望收到的字节是 `2000`。

接收方返回

```text
ACK = 2000
```

这个 `ACK` 的意思并不是「我收到了编号 2000 的数据」。

它真正表达的是

```text
2000 以前的数据已经连续收到
下一步希望收到从 2000 开始的数据
```

这里特别容易在考试中产生误解。

`TCP ACK` 是累计确认。

`ACK = 2000` 表示接收方已经连续正确收到 `2000` 之前的所有字节，下一个期待字节序号是 `2000`。

现在出现关键情况。

段 `2`

```text
Seq = 2000
```

在网络中丢失。

可是段 `3` 没有丢。

于是接收方看到了

```text
Seq = 3000
```

接收方会发现一个问题。

自己正在等的是

```text
Seq = 2000
```

结果突然来了 `3000`。

说明中间出现了一个序号空洞。

接收方不能把累计确认号推进到 `4000`，因为 `2000 ～ 2999` 仍然没有收到。

于是接收方再次发送

```text
ACK = 2000
```

这里就产生了第一个重复 `ACK`。

随后段 `4`

```text
Seq = 4000
```

也到达接收方。

问题依旧存在。

虽然 `3000 ～ 3999` 和 `4000 ～ 4999` 都到了，可是最前面的 `2000 ～ 2999` 仍然缺失。

所以累计确认仍然不能越过这个缺口。

接收方再次发送

```text
ACK = 2000
```

这就是第二个重复 `ACK`。

段 `5` 到达以后，同样的逻辑再次发生。

接收方仍然返回

```text
ACK = 2000
```

这就是第三个重复 `ACK`。

此时发送方看到的确认序列大致是

```text
ACK = 2000
ACK = 2000
ACK = 2000
ACK = 2000
```

第一个 `ACK = 2000` 是正常确认。

后面连续出现的三个 `ACK = 2000` 才叫做三个重复 `ACK`。

这一区别非常重要，因为考试中经常有人把「总共收到三个相同 `ACK`」和「收到三个重复 `ACK`」混成一件事。

经典定义讨论的是

```text
3 duplicate ACKs
```

也就是在正常那个 `ACK` 之后，又来了三个重复确认。

于是发送方可以作出一个相当合理的判断。

段 `2000 ～ 2999` 很可能丢了。

而且发送方手里还有一个很强的旁证。

为什么接收方能够连续发回三个 `ACK = 2000`

因为后面的数据段正在不断到达接收方。

如果整个网络完全中断，接收方根本没有新数据可以处理，自然也不会不断产生重复 `ACK`。

所以三个重复 `ACK` 所传达的信息并不是单纯的「网络很慢」。

它表达的是一种更具体的状态。

后面的数据仍然能够通过网络到达，但是某个前面的数据段形成了缺口。

这种状态非常适合快重传。

发送方此时不需要继续傻等 `RTO`。

直接重传

```text
Seq = 2000
```

就可以了。

这正是 `Fast Retransmit` 中 `Fast` 的来源。

普通超时重传的逻辑可以概括为

```text
发送数据
等待 ACK
等待
等待
RTO 超时
重传
```

快重传的逻辑则是

```text
发送数据
收到重复 ACK
收到重复 ACK
收到重复 ACK
判断中间数据很可能丢失
立即重传
```

两者都属于丢失恢复机制，但触发条件完全不同。

`RFC 5681` 明确指出，收到 `3` 个重复 `ACK` 后，`TCP` 会重传看起来已经丢失的报文段，而不等待重传计时器到期。

这里也解释了为什么 A 选项非常具有迷惑性。

A 写的是

> 重传计时器超时

看到「重传」两个字，很容易顺手选择 A。

但 A 对应的是另一套机制，也就是

```text
Retransmission Timeout
```

通常简称

```text
RTO
```

`RTO` 到期以后确实会发生重传。

但这个动作叫超时重传，不是题目询问的快重传触发条件。

`RFC 6298` 对 `TCP` 重传定时器的管理给出了标准算法。重传计时器到期后，发送方需要重新发送最早尚未被确认的报文段，并对 `RTO` 进行退避处理。

所以我们可以建立一个非常重要的考试对应关系。

```text
RTO 超时
        ↓
超时重传


3 个重复 ACK
        ↓
快重传
```

这两个必须分开记忆。

如果题目问

> 什么情况下 `TCP` 进行重传

那么答案可能涉及多种情况。

如果题目精确地问

> 什么情况下 `TCP` 启动快重传

那么经典答案几乎已经被锁定

```text
3 个重复 ACK
```

C 选项「出现拥塞」的问题，则在于把原因、推断和具体触发事件混在了一起。

丢包经常与拥塞有关。

快重传又属于 `TCP` 拥塞控制与丢失恢复体系中的重要算法。

所以「拥塞」和「快重传」之间确实有关联。

但是协议不能按照「感觉网络有点堵」这种抽象条件执行算法。

协议需要能够观察的具体事件。

对于经典快重传而言，可观察事件就是重复 `ACK`。

也就是说，我们不能写成

```text
发现拥塞
        ↓
必然快重传
```

因为拥塞可能通过多种信号表现出来。

其中一种情况是发生丢包，并形成三个重复 `ACK`。

另一种情况可能严重到后续数据根本没有到达接收端，于是连三个重复 `ACK` 都无法产生。

此时最终可能只能依靠 `RTO` 超时检测丢失。

所以同样是报文丢失，可能走两条完全不同的恢复路径。

一种情况是

```text
后续报文继续到达接收端
        ↓
不断产生重复 ACK
        ↓
3 个重复 ACK
        ↓
快重传
```

另一种情况是

```text
报文丢失
        ↓
后续报文不足以产生 3 个重复 ACK
        ↓
发送方持续等待
        ↓
RTO 到期
        ↓
超时重传
```

这也解释了快重传为什么不能彻底替代超时重传。

考虑一个很简单的情况。

发送方当前只剩最后一个报文段需要发送。

这个报文段丢了。

由于它后面已经没有更多报文段，接收方不可能因为收到后续乱序数据而连续生成三个重复 `ACK`。

快重传根本没有机会被触发。

于是重传计时器仍然必不可少。

`TCP` 需要同时保留

```text
基于 ACK 反馈的快速丢失检测
```

和

```text
基于时间的最终丢失检测
```

前者速度快。

后者覆盖面更完整。

把它放到生活中的可靠运输机制里理解也很直观。

假定仓库按照编号连续发送

```text
100
101
102
103
104
```

收货方反馈

```text
100 已收到
还在等 101
```

后来收货方却先后收到 `102`、`103`、`104`。

每收到一个后面的包裹，都再次告诉发货仓库

```text
还在等 101
```

发货仓库连续听到三次同样的信息以后，完全没必要继续等规定的超时时间结束。

`102`、`103`、`104` 都已经到了，偏偏一直缺 `101`，`101` 在运输途中丢失的可能性已经很高。

仓库于是提前补发 `101`。

这就是快重传的思维方式。

这里也能理解为什么标准采用三个重复 `ACK`，而不是看到一个重复 `ACK` 就立刻重传。

因为网络中的报文并不保证永远严格按照发送顺序抵达。

假设发送顺序为

```text
A
B
C
D
```

由于不同路由、队列调度、链路状态或者底层设备行为，接收端有可能短暂看到

```text
A
C
B
D
```

这叫报文重排序。

如果发送方只看到一个重复 `ACK` 就认定数据丢失，会产生大量不必要的重传。

所以一个重复 `ACK` 的证据太弱。

两个重复 `ACK` 仍可能来自短暂的乱序。

经典算法等到三个重复 `ACK`，在速度和误判之间取得一个工程上的折中。

这也是为什么考试不能把快重传简单理解成「一看到重复确认就重传」。

标准规则强调的是

```text
3 个重复 ACK
```

而不是

```text
1 个重复 ACK
```

也不是

```text
2 个重复 ACK
```

更不是

```text
等待 RTO
```

D 选项里的「持续计时器」则属于完全不同的问题。

持续计时器通常与 `TCP` 的零窗口处理有关。

接收方的缓冲区可能暂时塞满，于是通过窗口字段通知发送方

```text
Window = 0
```

此时发送方不能继续正常发送大量数据。

后来接收方缓冲区腾出了空间，会向发送方通告新的非零窗口。

问题在于，这个窗口更新报文也可能在网络中丢失。

于是会出现一种麻烦局面。

接收方认为

```text
我已经有空间了
```

发送方却仍然认为

```text
对方窗口还是 0
```

发送方因此不发送。

接收方又因为没有新情况，不一定再次发送窗口更新。

连接可能陷入长期等待。

针对这种零窗口状态，`TCP` 会使用零窗口探测机制，也就是 `Zero Window Probe`。现代 `TCP` 规范要求发送方支持零窗口探测，并周期性确认接收窗口是否重新打开。

所以持续计时相关机制解决的问题主要是

```text
接收窗口为 0
        ↓
发送方暂停正常发送
        ↓
需要定期探测窗口是否恢复
```

而快重传解决的是

```text
某报文段疑似丢失
        ↓
后面的报文仍然抵达
        ↓
产生重复 ACK
        ↓
3 个重复 ACK
        ↓
快速重传缺失报文段
```

两件事完全不是同一条逻辑链。

把四个选项放在一起比较，结构就非常清楚了。

A 中的重传计时器超时，会触发超时重传。

B 中的连续三个重复确认，会触发经典快重传。

C 中的拥塞属于更宽泛的网络状态，不是这道题要求的直接触发条件。

D 中的持续计时器主要服务于零窗口探测一类问题，与快重传没有对应关系。

再往深一点看，快重传其实体现了 `TCP` 一个非常漂亮的设计思路。

只靠时间判断数据是否丢失，信息利用率太低。

如果接收方不断发回重复 `ACK`，这些 `ACK` 已经携带了关于网络状态的信息。

发送方完全可以利用这种反馈更早判断丢包。

因此 `TCP` 的丢包检测并不是只有一个闹钟。

它同时在观察网络反馈。

可以把两套机制记成一句非常实用的口诀。

```text
三次重复 ACK，快重传
RTO 到时间，超时重传
零窗口不动，持续探测
```

考试中如果看到

```text
3 个重复 ACK
```

脑中应该立刻关联

```text
Fast Retransmit
```

如果看到

```text
RTO expires
```

应该关联

```text
Retransmission Timeout
```

如果看到

```text
zero window
persist
window probe
```

应该关联

```text
零窗口探测
```

而如果题目继续追问收到三个重复 `ACK` 以后发生什么，就已经从快重传进入快恢复和拥塞控制部分了。

经典 `TCP Reno` 中，第三个重复 `ACK` 到达以后，不只是重新发送缺失报文段，还会调整慢启动阈值 `ssthresh` 与拥塞窗口 `cwnd`，随后进入快恢复过程。`RFC 5681` 将 `Fast Retransmit` 与 `Fast Recovery` 放在一起定义，就是因为它们经常连续发生。

这里还能形成另一个很重要的知识链。

```text
3 个重复 ACK
        ↓
判断某个报文段可能丢失
        ↓
Fast Retransmit
        ↓
调整 ssthresh 与 cwnd
        ↓
Fast Recovery
```

而发生 `RTO` 时，发送方对网络状态的判断通常更加悲观。

原因很直观。

三个重复 `ACK` 至少说明后续某些报文仍然能够穿过网络，网络虽然发生丢包，却仍然在工作。

超时却可能说明反馈长时间没有有效到达。

所以经典拥塞控制算法面对两者时，采取的窗口调整策略也有所不同。

这也是网络考试经常把「快重传」「快恢复」「慢开始」「拥塞避免」「超时重传」混在同一组选项里的原因。

这些概念并不是孤立的名词，它们其实组成了一套连续的反馈控制系统。

回到第 29 题，真正需要记住的不是单独一个字母 B，而是这一幅过程图。

```text
            某数据段丢失
                 │
                 │
        后续数据是否继续到达
             ／        ＼
           是            否
           │             │
     产生重复 ACK       无法形成足够
           │           的重复 ACK
     连续 3 个重复 ACK     │
           │             │
       快重传          等待 RTO
           │             │
       快恢复          超时重传
```

只要这幅逻辑关系在脑中建立起来，类似题目的选项再怎么改变措辞，也很难混淆。

因此本题最终答案仍然是

**（29）B，连续收到同一段的三次应答。**

更严谨、更适合作为知识点记忆的表述则是

**`TCP` 发送方收到 3 个重复 `ACK` 后，可以在 `RTO` 到期之前触发快重传，对推测丢失的报文段进行重传。**

考试口诀可以压缩成十二个字

**三个重复确认，立即启动快重传。**

## 参考资料

`RFC 5681`，`TCP Congestion Control`，其中第 `3.2` 节定义了 `Fast Retransmit` 与 `Fast Recovery`。[RFC 5681 TCP Congestion Control](https://www.rfc-editor.org/rfc/rfc5681.html?utm_source=chatgpt.com)

`RFC 6298`，`Computing TCP's Retransmission Timer`，规定了 `TCP RTO` 与重传定时器的计算和管理方法。[RFC 6298 Computing TCP's Retransmission Timer](https://www.rfc-editor.org/rfc/rfc6298.html?utm_source=chatgpt.com)

`RFC 9293`，`Transmission Control Protocol TCP`，是目前 `TCP` 核心协议规范之一，其中包含零窗口探测等机制。[RFC 9293 Transmission Control Protocol](https://www.rfc-editor.org/rfc/rfc9293.html?utm_source=chatgpt.com)

当（29）时，TCP 启动快重传。   A. 重传计时器超时   B. 连续收到同一段的三次应答   C. 出现拥塞   D. 持续计时器超时

TCP 快重传为什么由 3 个重复 ACK 触发？

紫薇堂堂主

网络与通信

操作系统

编程语言

TCP快重传由发送方连续收到3个重复ACK触发，无需等待RTO超时。重复ACK表明后续数据仍能到达，仅中间报文段丢失，发送方立即重传缺失数据。经典TCP Reno算法中，3个重复ACK后进入快恢复阶段，调整拥塞窗口。RTO超时对应超时重传，持续计时器处理零窗口探测，两者与快重传触发条件不同。

数据丢失

代码解释

数据流

路由

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

TCP 快重传为什么由 3 个重复 ACK 触发？-腾讯云开发者社区-腾讯云

TCP 快重传为什么由 3 个重复 ACK 触发？

TCP 快重传为什么由 3 个重复 ACK 触发？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐