## TCP 如何保证可靠传输

## 判别规则（核心，唯一要记的）

1. **看"有没有确认机制"**：发了数据对方要回 ACK，收到 ACK 才算成功；没收到 ACK 就重传 → **TCP 可靠**
2. **看"能不能控制速度"**：发送方根据接收方窗口（流量控制）和网络状况（拥塞控制）调整发送速度 → **TCP 不会淹没对方/网络**
3. **看"丢包了怎么办"**：超时重传——发了没 ACK 就重发；快速重传——收到 3 个重复 ACK 立即重传（不用等超时） → **TCP 丢包有兜底**

一句话：**"TCP 靠 ACK 确认知道对方收没收到，靠重传保证丢了就重发，靠滑动窗口控制速度不淹没对方，靠拥塞控制不搞崩网络。"**

## 抽象描述（一句话本质）

TCP 通过**序号 + 确认 + 重传 + 校验 + 流量控制 + 拥塞控制**六大机制保证可靠传输，核心是让发送方知道「发了什么、丢了没有、对方收到没有、要不要减速」。

## 六大机制速查

| 机制 | 作用 | 解决的问题 |
|---|---|---|
| 序号（Sequence Number） | 标记每个字节的位置 | 数据丢失/乱序/重复 |
| 确认号（ACK） | 告诉对方"收到哪了" | 丢包检测 |
| 超时重传 | 定时器超时未收到 ACK 就重发 | 丢包 |
| 快速重传 | 收到 3 个重复 ACK 立即重传（不用等超时） | 丢包快速恢复 |
| 校验和（Checksum） | 检查数据完整性（传输中是否出错） | 数据损坏 |
| 流量控制（滑动窗口） | 接收方告诉发送方"我能接多少" | 接收方处理不过来 |
| 拥塞控制 | 发送方根据网络状况调整速度 | 网络过载 |

## 易混对比

| | TCP | UDP |
|---|---|---|
| 可靠性 | **可靠**（有序号/确认/重传） | **不可靠**（发了就不管） |
| 连接 | 面向连接（三次握手） | 无连接 |
| 速度 | 较慢（要确认） | 快（不确认） |
| 场景 | 文件传输、网页、邮件 | 视频直播、DNS、游戏 |

| 滑动窗口 | 拥塞控制 |
|---|---|
| 接收方能力 | 网络能力 |
| 告诉发送方"我能接多少" | 发送方根据网络状况调整 |
| 防止淹没接收方 | 防止搞崩网络 |
| 两个窗口取最小值决定发送速度 |

| 序号（Seq） | 校验和（Checksum） |
|---|---|
| 判断**重复/乱序**（这个包见过没） | 检查**数据完整性**（传输中坏了没） |
| 接收方据此丢弃重复包、重排乱序包 | 接收方据此丢弃损坏包 |
| 核心机制 | 辅助校验 |

**累积确认（Cumulative ACK）**：ACK 号表示"该号之前的所有字节都收到了"，不用逐包确认。丢一个包只重传该包之后未确认的部分，不是全重传。

## TCP 三次握手 vs 四次挥手

| | 三次握手 | 四次挥手 |
|---|---|---|
| 目的 | 建立连接 | 断开连接 |
| 次数 | 3 次 | 4 次 |
| 为什么 | SYN+ACK 合并（两次） | FIN 和 ACK 分开（半关闭） |
| 确认内容 | 确认双方收发能力 | 确认双方都知道连接关闭 |

**两次握手的问题**：旧的 SYN 延迟到达 → 服务器以为是新连接 → 分配资源等待 → 客户端没发起 → 浪费资源。三次握手让服务器确认客户端能收能发。

**为什么挥手四次**：TCP 是全双工，一方发 FIN 只表示"我不发了"，但还能接收。对方可能还有数据要发，所以 ACK 和 FIN 分开发送（半关闭状态）。

## 变体验证（3 题，全过=学会）

1. TCP 发送方发了一个包，10秒后没收到 ACK，重传了。接收方其实收到了，只是 ACK 回得慢。接收方收到重复包时，**检查序号**发现已经接收过，丢弃重复数据，重发 ACK。发送方收到重复 ACK 停止重传。 → **序号机制判断重复**
2. 陷阱题："TCP 有拥塞控制，所以 TCP 传输一定是可靠的" → **错**，拥塞控制只管速度，网络崩溃/物理链路断了/对方进程崩溃 → TCP 也无法保证
3. 陷阱题："UDP 没有序号、没有确认，所以 UDP 一定丢包" → **错**，UDP"不可靠"是指没有确认和重传机制，不是一定丢包。网络良好时 UDP 数据包很可能正常到达

## 口述要点（面试怎么讲）

- **结论先行**：TCP 靠六大机制保证可靠：序号、确认、重传、校验、流量控制、拥塞控制
- **可靠不是绝对可靠**：网络崩溃、物理链路断了、对方崩溃 → TCP 也无法保证
- **三次握手为什么两次不行**：防止旧 SYN 延迟到达造成资源浪费；两次握手服务器无法确认客户端能收
- **为什么视频直播用 UDP**：可以容忍少量丢包，不能容忍延迟；UDP 没有确认/重传/拥塞控制，开销小速度快
- **滑动窗口 vs 拥塞控制**：滑动窗口 = 接收方能力；拥塞控制 = 网络能力。两个窗口取最小值决定发送速度
- **易错点**：以为 TCP 绝对可靠；以为 UDP 一定丢包；混淆序号（判断重复）和校验和（检查完整性）

## 关系网络

| 相邻概念 | 关系 | 孤立理解会犯的错 |
|---|---|---|
| UDP | TCP 的对照组，UDP 没有序号/确认/重传，所以不可靠但快 | 以为 UDP 一定丢包 |
| 进程 vs 线程 | TCP 连接是进程级别的，线程共享地址空间不涉及 TCP | 把 TCP 连接当线程间通信 |
| 僵尸/孤儿进程 | TCP 连接的进程退出后，连接会关闭；父进程不回收连接资源可能泄漏 | 混淆进程回收和连接回收 |
| 滑动窗口 vs 拥塞控制 | 滑动窗口 = 接收方能力；拥塞控制 = 网络能力。两个窗口取最小值 | 只记一个忘了另一个 |
| 三次握手 vs 四次挥手 | 握手两次合并（SYN+ACK），挥手两次分开（FIN 和 ACK 分开）因为半关闭 | 混淆握手和挥手的次数差异 |

## 学习日期

2026-08-26

---

_每主题一页，复习时只翻本目录。_