四、传输层：TCP/UDP（补-11 ~ 补-13）

补-11

TCP 首部中，置 1 表示“紧急指针字段有效、本报文段含紧急数据”的标志位是（ ），TCP 首部的最小长度是（ ）字节。 A. PSH；20 B. RST；8 C. URG；20 D. FIN；40

答案：C

① 考点定位：传输层 — TCP 首部 — 标志位含义与首部最小长度。

② 知识精讲

TCP 首部结构（最小 20 字节，最大 60 字节）：

字段	长度	说明
源端口	2字节	发送方端口
目的端口	2字节	接收方端口
序号	4字节	数据段第一个字节的序号
确认号	4字节	期望收到的下一个字节序号
数据偏移	4位	指示首部长度（以4字节为单位）
保留	6位	保留未用
标志位	6位	URG/ACK/PSH/RST/SYN/FIN
窗口	2字节	接收窗口大小
校验和	2字节	差错检测
紧急指针	2字节	URG=1时有效
选项	0~40字节	可变部分

固定部分 = 20 字节（源端口2 + 目的端口2 + 序号4 + 确认号4 + 数据偏移4位 + 保留6位 + 标志位6位 = 2字节 + 窗口2 + 校验和2 + 紧急指针2 = 20字节）。注意：数据偏移/保留/标志位合计 4+6+6 = 16 位 = 2 字节，与上表一致。

六个标志位：

标志位	全称	置1含义
URG	Urgent	紧急指针有效，本报文段含紧急数据
ACK	Acknowledgment	确认号有效（建立连接后总为1）
PSH	Push	推送，接收方应尽快交付应用层
RST	Reset	重置连接（连接异常时）
SYN	Synchronize	同步序号，用于建立连接
FIN	Finish	发送方已完成数据发送，用于释放连接

URG 与紧急指针：当 URG=1 时，紧急指针字段有效，指示紧急数据在报文段中的位置。紧急数据会被优先处理（如 TCP 中断传输）。

③ 本题解析

置 1 表示“紧急指针字段有效、本报文段含紧急数据”的标志位是 URG，TCP 首部最小长度 = 固定部分 = 20 字节。对应选项 C. URG；20。

④ 选项逐项辨析

• A. PSH；20 ❌：PSH 是推送标志位，指示接收方尽快将数据交付应用层，与紧急指针无关。首部长度 20 正确但标志位错误。 误解来源：把 PSH 的“推送”误解为“紧急”。PSH 要求接收方不要等缓冲区满就立即交付应用层，是一种“催促”机制；URG 才是真正的“紧急数据”标志，配合紧急指针字段使用。两者都涉及“尽快处理”，但机制完全不同。
• B. RST；8 ❌：RST 是重置连接标志位，与紧急指针无关。8 字节是 UDP 首部长度，不是 TCP 的。 误解来源：把 UDP 首部长度（8 字节）误记为 TCP 首部长度。UDP 首部固定 8 字节（4 个 2 字节字段），TCP 首部最小 20 字节。这是两个协议的基本区别。
• C. URG；20 ✅：URG 置 1 表示紧急指针有效、含紧急数据；TCP 首部最小 20 字节，完全正确。
• D. FIN；40 ❌：FIN 是释放连接标志位，与紧急指针无关。40 字节既不是 TCP 首部的最小长度也不是最大长度——40 是选项字段的最大长度，首部最大 60 字节 = 20 固定 + 40 选项，最小 20 字节。 误解来源：把 TCP 首部最大长度（60 字节 = 20 固定 + 40 选项）误记为最小长度。或者把“40 字节”当成了另一个协议的首部长度。TCP 首部最小 20 字节（无选项时），最大 60 字节（选项占 40 字节）。

⑤ 易混对比

标志位	含义	对应场景	易混点
URG	紧急指针有效	传输紧急数据（如 Telnet 中断信号）	与 PSH 混淆（都涉及“尽快处理”）
ACK	确认号有效	除初始 SYN 外，建立连接后总为 1	建连前 ACK=0 不代表错误
PSH	推送数据	要求接收方尽快交付应用层	与 URG 混淆（PSH 不涉及紧急指针）
RST	重置连接	连接异常、拒绝连接	与 FIN 混淆（RST 是异常断开，FIN 是正常关闭）
SYN	同步序号	建立连接（三次握手）	建连时 SYN=1, ACK=0
FIN	结束发送	释放连接（四次挥手）	与 RST 混淆（FIN 优雅关闭，RST 强制重置）

TCP vs UDP 首部：

• TCP 首部：20~60 字节（固定 20 + 选项 0~40）
• UDP 首部：固定 8 字节（源端口2 + 目的端口2 + 长度2 + 校验和2）

相近概念辨析：URG vs PSH——URG 是“这段数据很重要，优先处理”（配合紧急指针指向紧急数据末尾）；PSH 是“别攒着了，赶紧交给应用层”（不涉及紧急指针）。实际网络中 URG 极少使用，PSH 较常见（如交互式应用每敲一个键就发送）。

⑥ 拓展延伸

• 与主库相关题号：主库第 42 题（IPv4 首部固定长度 20 字节——与 TCP 首部长度对比）、第 60 题（三次握手/四次挥手）、第 61 题（SYN 与 ACK 的值）、第 121 题（TCP 与 UDP 对比）与本题直接相关。第 64 题（UDP 特点）和第 72 题（TCP/UDP 端口号关系）是传输层基础知识。
• 紧急数据（Urgent Data）的应用：URG 标志位和紧急指针用于带外数据（Out-of-Band Data）传输。例如 Telnet 中用户按下 Ctrl+C 中断正在运行的命令时，这个中断信号作为紧急数据优先传输，不必排队等待。
• 数据偏移字段：4 位，以 4 字节为单位，取值范围 5~15，对应首部长度 20~60 字节。数据偏移 = 5 → 首部 20 字节（无选项）；数据偏移 = 15 → 首部 60 字节（最大选项）。
• TCP 选项字段：常见的 TCP 选项包括 MSS（最大报文段长度）、窗口缩放（Window Scale）、SACK（选择性确认）、时间戳等。
• 完整验算（TCP 首部长度）：
  • 固定部分：源端口(2) + 目的端口(2) + 序号(4) + 确认号(4) + 数据偏移/保留/标志(2) + 窗口(2) + 校验和(2) + 紧急指针(2) = 20 字节
  • 数据偏移字段：4 位，以 4 字节为单位，最小值 5 → 5×4 = 20 字节
  • 最大首部：20 + 40（选项）= 60 字节，此时数据偏移 = 15 → 15×4 = 60 字节
• 工程场景：用 Wireshark 抓包时，TCP 首部的 flags 字段显示为 "······AP···" 等形式（每字母对应一个标志位）。排查“连接被重置”问题时，关注 RST 标志；排查“数据延迟交付”问题时，关注 PSH 标志。
• 常见面试追问：
  1. “TCP 首部最小多少字节？”——20 字节（无选项时）。
  2. “URG 和 PSH 有什么区别？”——URG 配合紧急指针标记紧急数据；PSH 要求立即交付应用层。
  3. “TCP 首部中哪个字段决定了首部长度？”——数据偏移（4 位，以 4 字节为单位）。
  4. “为什么 TCP 首部有紧急指针字段但很少用？”——现代应用层协议（如 SSH）自带优先级机制，不需要 TCP 层的紧急数据。

⑦ 真题变式

变式题：TCP 连接建立后，以下哪个标志位一直保持为 1？ A. SYN B. FIN C. ACK D. URG

答案：C解析：建立连接后，ACK 一直为 1（除初始 SYN 报文外，所有报文的 ACK 都为 1）。SYN 和 FIN 只在建立和释放连接时使用，URG 仅在有紧急数据时置 1。

⑧ 记忆锚点

六位口诀："UAP RSF" — URG（紧急） ACK（确认） PSH（推送） RST（重置） SYN（同步） FIN（结束）。TCP 首部最小 20 字节，UDP 首部固定 8 字节。记忆：“URG 配紧急指针，ACK 管确认号，PSH 推得快，RST 连接断，SYN 建连 FIN 断连”。

补-12

TCP 建立连接采用三次握手而不是两次握手，其最主要的原因是（ ）。 A. 三次握手可以加密握手过程，提高安全性 B. 防止已失效的连接请求报文段突然传到服务器，使服务器误建连接、浪费资源 C. 三次握手能把 TCP 首部压缩到 20 字节 D. 两次握手无法确定双方 IP 地址

答案：B

① 考点定位：传输层 — TCP 连接管理 — 三次握手必要性分析。

② 知识精讲

TCP 三次握手过程：

1. 第一次握手：客户端发送 SYN=1, seq=x 的报文段给服务器，进入 SYN_SENT 状态。
2. 第二次握手：服务器收到 SYN 后，回复 SYN=1, ACK=1, seq=y, ack=x+1 的报文段，进入 SYN_RCVD 状态。
3. 第三次握手：客户端收到 SYN+ACK 后，发送 ACK=1, seq=x+1, ack=y+1 的报文段，双方进入 ESTABLISHED 状态。

为什么需要三次而不是两次？

核心原因：防止已失效的连接请求报文段突然传到服务器，使服务器误建连接、浪费资源。

具体场景：

1. 客户端发送了 SYN 请求 A，但由于网络拥塞延迟。
2. 超时后客户端重发 SYN 请求 B，完成连接建立、数据传输并关闭。
3. 延迟的请求 A 到达服务器，服务器误以为是新的连接请求，回复 SYN+ACK 并分配资源等待。
4. 如果是两次握手，服务器此时已经建立连接并等待数据，将长期占用资源（资源浪费/半连接泄漏）。
5. 如果是三次握手，客户端收到 SYN+ACK 后发现这不是自己发起的连接，会发送 RST 终止，避免资源浪费。

三次握手的本质：确认双方都具备发送和接收能力。

• 第一次：服务器确认客户端能发送
• 第二次：客户端确认服务器能接收和发送
• 第三次：服务器确认客户端能接收

③ 本题解析

两次握手无法防止失效的连接请求到达服务器后导致误建连接。三次握手的第三次让客户端能确认并拒绝无效连接。对应选项 B。

④ 选项逐项辨析

• A. 三次握手可以加密握手过程，提高安全性 ❌：TCP 三次握手不涉及加密。加密由 TLS/SSL 等在应用层或传输层之上完成。 误解来源：把 HTTPS 的 TLS 握手（在 TCP 握手之后）与 TCP 三次握手混淆。TCP 本身是明文协议，不提供任何加密功能。TLS 握手确实发生在 TCP 连接建立之后，但那是应用层/表示层的行为。
• B. 防止已失效的连接请求报文段突然传到服务器，使服务器误建连接、浪费资源 ✅：这是三次握手最核心的原因，防止旧的失效连接请求导致资源浪费。
• C. 三次握手能把 TCP 首部压缩到 20 字节 ❌：握手与首部长度无关，TCP 首部最小就是 20 字节，无论握手几次。 误解来源：无中生有。TCP 首部长度由“数据偏移”字段决定，与握手次数完全无关。20 字节是无选项时的固定首部长度，三次握手并不改变这个事实。
• D. 两次握手无法确定双方 IP 地址 ❌：IP 地址在 IP 层确定，不需要握手来确定。TCP 连接通过 IP+端口号的四元组标识，但这些信息在 IP 头和 TCP 头中已经存在。 误解来源：混淆了网络层和传输层的职责。IP 地址由 IP 协议负责，TCP 只关心端口号。三次握手交换的是序号（seq）和确认号（ack），不是 IP 地址。TCP 四元组（源IP、目的IP、源端口、目的端口）中的 IP 部分由 IP 层提供。

⑤ 易混对比

方面	两次握手	三次握手	四次挥手
能否防止失效连接请求	❌	✅	—
服务器资源浪费风险	高（半连接泄漏）	低	—
确认双方收发能力	不完全	完全	完全
建连/断连速度	1 RTT（服务器在收到 SYN 时即认为建立）	1 RTT（客户端在收到 SYN+ACK 后即认为建立，第三次 ACK 可捎带数据，并不多花一个 RTT）	2 RTT（FIN→ACK→FIN→ACK）
安全性	无差别	无差别	无差别
核心价值	—	防止失效连接请求	确保双方数据都发完

相近概念辨析：三次握手 vs TLS 握手——TCP 三次握手建立传输层连接（交换序号）；TLS 握手在 TCP 连接之上建立加密通道（协商算法、交换证书、生成会话密钥）。HTTPS = TCP 三次握手 + TLS 握手 + HTTP 请求/响应。

⑥ 拓展延伸

• 与主库相关题号：主库第 60 题（TCP 建立/释放连接次数）、第 61 题（三次握手第二步 SYN 与 ACK 的值）、第 62 题（四次挥手最后一个报文）、第 63 题（TIME_WAIT 状态持续时间）、第 117 题（SYN Flood 攻击）与本题直接相关。第 59 题（端到端可靠传输）是 TCP 的设计目标。
• SYN Flood 攻击：攻击者大量发送 SYN 请求但不完成第三次握手，耗尽服务器半连接队列资源。防御措施包括 SYN Cookies（不分配资源直到第三次握手完成）、SYN Proxy 等。
• 半连接队列与全连接队列：服务器收到 SYN 后将连接放入半连接队列（SYN Queue），收到第三次握手的 ACK 后移入全连接队列（Accept Queue）。
• 四次挥手为什么是四次：TCP 是全双工的，每个方向的关闭需要独立的 FIN + ACK。FIN → ACK 是一个方向的关闭，另一个方向还需 FIN → ACK。
• 完整验算（三次握手时序）：
  1. 客户端 → 服务器：SYN=1, seq=x（客户端随机选 x）
  2. 服务器 → 客户端：SYN=1, ACK=1, seq=y, ack=x+1（服务器随机选 y，确认收到 x）
  3. 客户端 → 服务器：ACK=1, seq=x+1, ack=y+1（确认收到 y）
  • 客户端在第 3 步发送后进入 ESTABLISHED
  • 服务器在第 3 步收到后进入 ESTABLISHED
  • 若第 3 步丢失：服务器重传第 2 步，客户端重传第 3 步
• 工程场景：网络工程师排查“连接超时”时，用 netstat 或 ss 查看连接状态。大量 SYN_RCVD 状态说明可能遭受 SYN Flood；大量 CLOSE_WAIT 说明应用层没调 close()；大量 TIME_WAIT 说明短连接过多。
• 常见面试追问：
  1. “为什么不是两次握手？”——防止失效 SYN 导致服务器误建连接、浪费资源。
  2. “为什么不是四次握手？”——三次已足够确认双方收发能力，四次多余。
  3. “第三次握手可以携带数据吗？”——可以。第三次握手的 ACK 报文可以捎带数据，不浪费一个 RTT。
  4. “SYN Flood 怎么防御？”——SYN Cookies（不提前分配资源）。
  5. “TIME_WAIT 为什么等 2MSL？”——确保最后一个 ACK 能到达对方；确保旧连接的报文在网络中消失。

⑦ 真题变式

变式题：TCP 释放连接采用四次挥手而不是三次，其原因是（ ）。 A. 四次挥手更安全 B. TCP 是全双工通信，每个方向需要独立关闭 C. 四次挥手能减少网络流量 D. 三次挥手无法确定数据已全部传输

答案：B解析：TCP 全双工通信，每端都需要发送 FIN 并收到 ACK 来独立关闭各自方向的连接。当 A 发 FIN 后，B 可以回 ACK 但 B 可能还有数据要发，所以不能把 ACK 和 FIN 合并为三次。

⑧ 记忆锚点

三次握手核心 = 防止失效连接请求造成资源浪费。记忆场景：“旧 SYN 迟迟到，服务器以为新请求，两次握手就建连→浪费；三次握手客户端发 RST→阻止”。本质：三次握手 = 双方都确认了对方的收发能力。

补-13

下列关于 UDP 的叙述，错误的是（ ）。 A. UDP 首部固定 8 字节，含源端口、目的端口、长度、校验和四个字段 B. UDP 长度字段的最小值为 8（即首部本身） C. UDP 计算校验和时需要加上 12 字节的伪首部（含源 IP、目的 IP、协议号与 UDP 长度） D. UDP 校验和字段为 0 时表示数据出错，接收方应立即丢弃

答案：D

① 考点定位：传输层 — UDP 协议 — 首部结构、伪首部与校验和机制。

② 知识精讲

UDP（User Datagram Protocol，用户数据报协议）是传输层无连接协议。

UDP 首部（固定 8 字节）：

字段	长度	说明
源端口	2字节	发送方端口（可选，全0表示不需要回复）
目的端口	2字节	接收方端口
长度	2字节	UDP数据报总长度（首部+数据），最小值8
校验和	2字节	差错检测（含伪首部计算）

UDP 伪首部（12 字节，不实际传输，仅用于校验和计算）：

字段	长度	来源
源IP地址	4字节	IP首部
目的IP地址	4字节	IP首部
零（填充）	1字节	全0
协议号	1字节	IP首部（UDP=17）
UDP长度	2字节	UDP长度字段值

伪首部的作用：将 IP 层信息纳入 UDP 校验和计算，确保数据到达正确的目的 IP 和正确的协议。如果校验和正确，说明数据在 IP 层和 UDP 层都未被损坏。

校验和计算：将伪首部 + UDP 首部 + UDP 数据按 16 位字相加，取反码得到校验和。

校验和 = 0 的含义：在 IPv4 中，UDP 校验和为 0 表示发送方没有计算校验和（即不进行差错检测），接收方不应丢弃。这与 TCP 不同——TCP 校验和必填。在 IPv6 中，UDP 校验和为必填，不允许为 0。

③ 本题解析

题目问“错误”的叙述。选项 D 说“UDP 校验和字段为 0 时表示数据出错，接收方应立即丢弃”——这是错误的。校验和为 0 在 IPv4 中表示发送方没有计算校验和，不是数据出错。对应选项 D。

④ 选项逐项辨析

• A. UDP 首部固定 8 字节，含源端口、目的端口、长度、校验和四个字段 ✅：完全正确，UDP 首部就这四个 2 字节字段。
• B. UDP 长度字段的最小值为 8（即首部本身） ✅：当 UDP 无数据时，长度 = 首部 = 8 字节，这是最小值。
• C. UDP 计算校验和时需要加上 12 字节的伪首部（含源 IP、目的 IP、协议号与 UDP 长度） ✅：伪首部 12 字节 = 源IP(4) + 目的IP(4) + 零(1) + 协议(1) + UDP长度(2)，正确。
• D. UDP 校验和字段为 0 时表示数据出错，接收方应立即丢弃 ❌（本题答案）：错误。校验和为 0 在 IPv4 中表示发送方没有计算校验和，不是数据出错。接收方不应丢弃。 误解来源：把“校验和为 0”误解为“校验失败”。实际上 UDP 校验和的语义是：0 = 不计算校验和（发送方放弃检错），非 0 = 已计算，接收方需验证。这与 TCP 不同——TCP 校验和必填，不允许为 0。IPv6 中 UDP 校验和也必填（因为 IPv6 取消了首部校验和）。

⑤ 易混对比

特性	UDP	TCP
首部长度	固定 8 字节	20~60 字节
首部字段数	4	10+
校验和是否必填	IPv4可选（可为0），IPv6必填	必填（不可为0）
伪首部	有（12字节）	有（12字节）
可靠性	不可靠	可靠
连接性	无连接	面向连接
流量控制	无	有（滑动窗口）
拥塞控制	无	有
首部开销	小（8B）	大（20B+）

校验和含义对比：

• UDP 校验和 = 0 → 不计算校验和（IPv4 中合法）
• TCP 校验和 = 0 → 非法（TCP 校验和必填）
• 校验和 ≠ 0 且验证不通过 → 数据出错，丢弃
• 校验和 ≠ 0 且验证通过 → 数据正确

相近概念辨析：UDP 校验和 vs IP 首部校验和——IP 首部校验和只校验 IP 首部（20 字节），不校验数据部分；UDP 校验和校验伪首部+UDP 首部+UDP 数据（即整个 UDP 数据报 + IP 层关键信息）。两者互补，共同保证端到端数据完整性。

⑥ 拓展延伸

• 与主库相关题号：主库第 64 题（UDP 协议的特点）、第 65 题（使用 UDP 的应用层协议）、第 72 题（TCP 和 UDP 的端口号关系）、第 121 题（TCP 与 UDP 对比）与本题直接相关。第 59 题（端到端可靠传输）解释了为什么 TCP 需要而 UDP 不需要可靠性。
• 伪首部为何重要：伪首部使 UDP/TCP 校验和能检测数据是否到达了正确的 IP 和正确的协议。如果 IP 层将数据交付给错误的协议（如本应给 UDP 却给了 TCP），伪首部中的协议号字段会使校验和验证失败。
• IPv6 中的 UDP 校验和：IPv6 强制要求 UDP 校验和不为 0，因为 IPv6 首部取消了校验和字段（IPv4 首部有首部校验和），需要传输层来保证数据完整性。
• UDP 的优势：无连接开销、首部开销小（8字节 vs TCP的20+字节）、实时性好（不等待重传），适合 DNS、DHCP、SNMP、流媒体等场景。
• 完整验算（伪首部结构）：
  • 源 IP：4 字节
  • 目的 IP：4 字节
  • 零（填充）：1 字节
  • 协议号：1 字节（UDP = 17）
  • UDP 长度：2 字节
  • 合计：4+4+1+1+2 = 12 字节 ✅
• 工程场景：用 Wireshark 抓 UDP 包时，若校验和显示为 0x0000，说明发送方未计算校验和（IPv4 中合法）。若显示为 "incorrect"，说明数据在传输中被损坏。DNS 查询通常使用 UDP（端口 53），大响应或区域传送使用 TCP。
• 常见面试追问：
  1. “UDP 校验和为 0 是什么意思？”——IPv4 中表示发送方未计算校验和，不是数据出错。
  2. “伪首部是真实传输的吗？”——不是。伪首部只在校验和计算时临时拼接，不实际传输。
  3. “IPv6 为什么强制 UDP 校验和？”——IPv6 取消了首部校验和，需要传输层保证完整性。
  4. “哪些应用用 UDP？”——DNS、DHCP、SNMP、RIP、视频流、游戏、VoIP。

⑦ 真题变式

变式题：UDP 计算校验和时，伪首部中的“协议号”字段的值应为（ ）。 A. 6 B. 17 C. 0 D. 1

答案：B解析：IP 首部中协议号字段值：TCP=6，UDP=17，ICMP=1。UDP 伪首部中协议号 = 17。

⑧ 记忆锚点

UDP 首部 8 字节 = 4 个 2 字节字段。伪首部 12 字节 = 源IP(4) + 目的IP(4) + 零(1) + 协议(1) + UDP长度(2)。校验和 = 0（IPv4）表示“不算不检”，不是“数据出错”。协议号记忆：“TCP 是 6，UDP 是 17，ICMP 是 1”。