Appearance
408
计算机网络
CN-05-05 TCP可靠传输机制
一、定位信息
- 圈层：核心层
- 前置知识：需要掌握TCP报文段格式（序号、确认号、校验和），理解TCP面向字节流的特点
- 知识网络位置：TCP可靠传输是TCP协议的核心价值所在——它建立在网络层不可靠服务之上，通过序号、确认、重传三大机制向上层提供可靠的数据传输服务，是流量控制和拥塞控制的底层基础
- 考点热度等级：H级（高频重点）——可靠传输机制是TCP综合题的核心考查内容，涉及序号计算、超时重传、快重传等
二、知识点讲解
2.1 可靠传输的基本原理
TCP在不可靠的IP层之上实现可靠传输，核心思想是：通过序号保证有序，通过确认保证到达，通过重传保证不丢。
可靠传输的三个基本机制：
- 序号机制：每个字节都有编号，接收方据此排序
- 确认机制：接收方告知发送方已收到的数据范围
- 重传机制：超时未确认或收到冗余确认时重新发送
2.2 序号机制
TCP将数据视为连续的字节流，每个字节都有一个32位的序号。发送方为每个报文段设置序号（该报文段第一个字节的编号），接收方根据序号将数据重新排序。
例如：发送方要发送3000字节的数据，MSS（最大报文段长度）为1000字节，则：
- 第1个报文段：seq=1000，数据=字节1000~1999
- 第2个报文段：seq=2000，数据=字节2000~2999
- 第3个报文段：seq=3000，数据=字节3000~3999
2.3 确认机制
TCP采用**累积确认（Cumulative ACK）**机制：确认号N表示序号N之前的所有数据都已正确接收。
| 确认方式 | 说明 | TCP是否采用 |
|---|---|---|
| 逐条确认 | 每收到一个报文段就确认一次 | 是（基本方式） |
| 累积确认 | 确认号表示"此号之前全部收到" | 是（核心机制） |
| 选择确认（SACK） | 窗口中哪些字节已收到，哪些缺失 | 是（可选扩展） |
延迟确认（Delayed ACK）：TCP接收方不必立即确认每个报文段，可以延迟一段时间（通常200ms），如果有数据要发送则捎带确认（Piggybacking）。但延迟不能超过最大延迟（通常500ms），且每收到两个报文段至少发送一个确认。
2.4 超时重传机制
发送方发出报文段后启动一个重传计时器（Retransmission Timer）。如果在计时器超时前没有收到确认，就重传该报文段。
超时时间（RTO, Retransmission Timeout）的确定是关键问题。RTO应略大于往返时间RTT，但RTT是动态变化的。TCP使用以下公式估算：
- 测量样本RTT（SampleRTT）：从发送报文段到收到确认的时间
- 计算加权平均RTT（EstimatedRTT）： 其中 通常取0.125（1/8）
- 计算RTT偏差（DevRTT）： 其中 通常取0.25（1/4）
- 计算超时时间（RTO）：
2.5 快重传机制
超时重传的问题是等待时间太长。**快重传（Fast Retransmit）**机制让发送方尽早知道个别报文段的丢失。
快重传的工作原理：
- 接收方每收到一个失序的报文段，就立即发送一个冗余确认（重复确认），确认号为期望收到的下一个字节序号
- 接收方在收到下一个期望的报文段之前，每收到一个后续报文段都要发送冗余确认
- 发送方一旦收到3个冗余确认（即同一个确认号的第4次出现），就立即重传丢失的报文段，而不等待超时
发送方 接收方
| |
|--- seq=1, 100字节 ----------->| 正常收到，ack=101
|<-------- ack=101 ------------|
| |
|--- seq=101, 100字节 --------->| 丢失！
| |
|--- seq=201, 100字节 --------->| 收到但失序，发冗余确认
|<-------- ack=101 ------------| 冗余确认#1
| |
|--- seq=301, 100字节 --------->| 收到但失序，发冗余确认
|<-------- ack=101 ------------| 冗余确认#2
| |
|--- seq=401, 100字节 --------->| 收到但失序，发冗余确认
|<-------- ack=101 ------------| 冗余确认#3（第4个相同ack）
| |
|--- seq=101, 100字节 --------->| 立即重传！（快重传）
|<-------- ack=401 ------------| 累积确认到4012.6 冗余确认与SACK
冗余确认（Duplicate ACK）：接收方收到失序报文段时发送的确认，确认号为期望的下一个字节序号。快重传利用连续3个冗余确认来判断报文段丢失。
SACK（Selective Acknowledgment，选择确认）：累积确认只告诉发送方"我收到哪了"，不能告诉发送方"哪些具体字节已收到"。SACK选项允许接收方在确认中附加一个"已收到的字节范围"列表，让发送方只重传真正丢失的部分。
SACK选项通过TCP首部的"选项"字段实现，格式为：[左边界1, 右边界1], [左边界2, 右边界2], ...
2.7 TCP可靠传输机制总览
| 机制 | 解决的问题 | 核心方法 |
|---|---|---|
| 序号 | 数据可能乱序到达 | 每个字节编号，接收方按序号重组 |
| 确认 | 不知道对方是否收到 | 累积确认，告知已收到的最大连续序号 |
| 超时重传 | 数据可能丢失 | RTO超时后重传 |
| 快重传 | 超时等待太久 | 收到3个冗余确认立即重传 |
| 校验和 | 数据可能出错 | 16位校验和检测 |
| SACK | 累积确认效率低 | 告知具体哪些字节已收到 |
三、记忆与理解辅助
口诀："序号确认加重传，可靠传输三板斧；超时太慢用快传，三个冗余就动手"——记住可靠传输的三大基本机制和快重传的触发条件。
公式记忆：RTO = EstimatedRTT + 4×DevRTT。记忆技巧："估计值加上四倍偏差"——偏差越大，超时越保守。
对比记忆：超时重传 vs 快重传——超时重传是"等不及了"（计时器超时），快重传是"听出来了"（3个冗余确认暗示丢包）。快重传通常比超时重传更快触发。
类比记忆：累积确认像老师批改作业——"第1到第5题都对了"（确认号=6），而不是"第1题对了、第2题对了..."逐个确认。SACK像老师说"第1、2、4、5题对了，第3题没交"。
四、例题与精解
例题1（基础巩固）
题目：TCP发送方连续发送了序号为1000、2000、3000的三个报文段（每个1000字节）。接收方依次收到了序号为1000和3000的报文段，序号为2000的报文段丢失。此时接收方发送的确认号为（ ），发送方收到3个冗余确认后应重传的报文段序号为（ ）。
A. 2000, 2000
B. 3000, 2000
C. 2000, 3000
D. 4000, 2000
命题意图：考查累积确认机制和快重传的触发条件。
精解：
审题分析：接收方收到seq=1000（正常）和seq=3000（失序），seq=2000丢失。
解题思路：
- 累积确认：确认号 = 期望收到的下一个字节序号 = 已收到的最大连续字节序号 + 1
- 收到seq=1000的数据（字节1000~1999），确认号应更新为2000
- seq=2000的数据丢失，seq=3000的数据到达但失序
- 接收方对seq=3000的报文段发送冗余确认，确认号仍为2000
完整步骤：
- 收到seq=1000：累积确认ack=2000
- seq=2000丢失，seq=3000到达（失序）：发送冗余确认ack=2000
- 确认号 = 2000（因为2000~2999的数据缺失）
- 快重传：收到3个冗余确认（ack=2000出现4次）后，重传seq=2000的报文段
方法反思：累积确认的关键是确认号只关注"最大连续已收"的边界。失序报文段不会更新确认号，只会触发冗余确认。
答案：A
例题2（中等提升）
题目：TCP发送方测量到的SampleRTT值依次为：100ms, 120ms, 90ms。初始EstimatedRTT=100ms，初始DevRTT=5ms，α=0.125，β=0.25。经过三次测量后，RTO的值约为（ ）。
A. 130ms
B. 120ms
C. 115ms
D. 140ms
命题意图：考查TCP超时时间RTO的计算过程，包括EstimatedRTT、DevRTT和RTO的递推公式。
精解：
审题分析：需要按照TCP的公式逐次更新EstimatedRTT和DevRTT，最后计算RTO。
解题思路：使用递推公式，每次测量后更新EstimatedRTT和DevRTT。
完整步骤：
第一次测量：SampleRTT=100ms
- EstimatedRTT = (1-0.125)×100 + 0.125×100 = 0.875×100 + 0.125×100 = 100ms
- DevRTT = (1-0.25)×5 + 0.25×|100-100| = 0.75×5 + 0.25×0 = 3.75ms
- RTO = 100 + 4×3.75 = 115ms
第二次测量：SampleRTT=120ms
- EstimatedRTT = 0.875×100 + 0.125×120 = 87.5 + 15 = 102.5ms
- DevRTT = 0.75×3.75 + 0.25×|120-102.5| = 2.8125 + 0.25×17.5 = 2.8125 + 4.375 = 7.1875ms
- RTO = 102.5 + 4×7.1875 = 102.5 + 28.75 = 131.25ms
第三次测量：SampleRTT=90ms
- EstimatedRTT = 0.875×102.5 + 0.125×90 = 89.6875 + 11.25 = 100.9375ms
- DevRTT = 0.75×7.1875 + 0.25×|90-100.9375| = 5.390625 + 0.25×10.9375 = 5.390625 + 2.734375 = 8.125ms
- RTO = 100.9375 + 4×8.125 = 100.9375 + 32.5 = 133.4375ms ≈ 133ms
最接近的选项是A（130ms）。
方法反思：RTO计算虽然公式简单但步骤繁琐，考研中通常只考一轮或两轮递推。关键是记住三个公式的含义：EstimatedRTT是加权平均，DevRTT是偏差的加权平均，RTO是估计值加四倍偏差。
答案：A
五、考情分析
- 考查频次：近5年408真题中可靠传输相关题目约出现5~8次
- 常见题型：选择题（确认号计算、快重传触发条件）和综合题（结合流量控制/拥塞控制的完整分析）
- 分值占比：4~8分
- 命题趋势：近年倾向于将可靠传输与流量控制、拥塞控制综合考查，题目综合性增强。RTO计算和SACK机制也有考查趋势
- 基于大纲与命题规律推测
六、易错点提醒
错误表现：将累积确认号理解为"已收到的最后一个字节的序号"
- 错误原因：直觉上认为"确认号=最后收到的"
- 正确理解/做法：确认号 = 期望收到的下一个字节序号 = 已收到的最大连续字节序号 + 1。例如收到字节0~999，确认号=1000，不是999。
错误表现：认为收到3个冗余确认后就进入拥塞控制的"快恢复"阶段
- 错误原因：将"快重传"和"快恢复"混为一谈
- 正确理解/做法：快重传是一种可靠传输机制（尽早重传丢失报文段），快恢复是一种拥塞控制算法（调整拥塞窗口）。快重传后是否进入快恢复取决于具体的拥塞控制策略（Reno版本会，Tahoe版本不会）。
错误表现：认为TCP的每个报文段都必须立即确认
- 错误原因：过度简化确认机制
- 正确理解/做法：TCP支持延迟确认——接收方可以等待最多500ms再发送确认，期间如果有数据要发送则捎带确认。每收到两个报文段至少发送一个确认。
错误表现：在RTO计算中忘记DevRTT的更新
- 错误原因：只关注EstimatedRTT的更新，忽略了DevRTT也需要同步更新
- 正确理解/做法：每次测量都要同时更新EstimatedRTT和DevRTT，然后用更新后的两个值计算RTO。
七、来源标注
- 依据2026考研统考大纲·计算机网络部分
- 依据《计算机网络（第8版）》谢希仁版
- 依据《计算机网络：自顶向下方法（第8版）》James F. Kurose版
- 依据RFC 6298 - Computing TCP's Retransmission Timer