四、传输层（第59-78题）
59. 在OSI模型中，提供端到端可靠传输的是（ ）。
A. 物理层 B. 数据链路层 C. 网络层 D. 传输层
答案：D解析：① 考点定位 传输层在 OSI 模型中的服务定位——“端到端可靠传输”由哪一层提供。
② 知识精讲 OSI 七层模型各层提供的服务粒度不同，形成“点到点→主机到主机→进程到进程”的递进链：
- 物理层：传输原始比特流，关注电气/光学特性，不涉及寻址与可靠。
- 数据链路层：在相邻节点（如两台直连设备之间）提供点到点通信，通过帧封装、MAC 寻址、CRC 校验等保证单跳链路的可靠传输，但只覆盖一跳。
- 网络层：在端系统（主机）之间提供主机到主机通信，通过 IP 寻址和路由选择使数据报跨越多个网络到达目的主机，但不区分主机上的具体应用进程。
- 传输层：在应用进程之间提供端到端（进程到进程）的通信服务，用端口号标识具体进程，可实现可靠交付（TCP）或不可靠交付（UDP），是唯一做到“端到端”可靠传输的层次。
关键词：“端到端”指端系统上的进程到进程，而非主机到主机。只有传输层具备端口号复用/分用、流量控制、可靠传输等机制。
③ 本题解析 题干问“提供端到端可靠传输”的层次。物理层传比特、数据链路层管相邻节点、网络层管主机间转发，都不到“进程”粒度；只有传输层（D）以端口号为标识，在发送进程与接收进程之间提供端到端的可靠传输服务（TCP）。
④ 选项逐项辨析
- A 物理层：只传比特流，无寻址无可靠，错误。
- B 数据链路层：点到点（相邻节点），不是端到端，错误。
- C 网络层：主机到主机，不区分进程，不到端到端粒度，错误。
- D 传输层：进程到进程（端到端）可靠传输，正确。
常见误解来源： 把可靠传输归网络层（IP 尽最大努力）或会话层。端到端可靠在传输层（TCP）。
⑤ 易混对比 “点到点”与“端到端”是笔试最高频混淆对：
| 概念 | 覆盖层次 | 通信范围 | 典型层 |
|---|---|---|---|
| 点到点 | 链路层 | 相邻两节点之间 | 数据链路层 |
| 端到端 | 传输层 | 发送进程↔接收进程 | 传输层（TCP/UDP） |
网络层虽是“端系统到端系统”，但“端到端”在本语境中特指进程级通信，是传输层的标志性服务。
⑥ 拓展延伸 传输层之所以能在端到端提供可靠传输，依赖于四大核心机制：①序号与确认（保证有序、检测丢失）；②重传（超时或重复ACK触发）；③流量控制（滑动窗口匹配接收方能力）；④拥塞控制（探测网络承载能力）。这些机制是 TCP 的标志，UDP 不提供任何一条。
⑦ 真题变式 “OSI 模型中，提供进程到进程通信的是哪一层？“→答案同样是传输层。变式可能改问”主机到主机“→网络层，或”点到点“→数据链路层。
⑧ 记忆锚点 口诀”链路点到点、网络主机间、传输端到端“。三层粒度递进——记住每层多一个维度（链路层→节点，网络层→主机，传输层→进程），就能准确对应。
⑨ 知识关联： 主库题群：与第60-63题（TCP 握手挥手）、第66-71题（流量/拥塞控制）、第121题（TCP/UDP 对比）构成「传输层 TCP」大题群。与补题：补-03/04（GBN/SR 窗口）是滑动窗口理论基础；补-11/12/13（TCP 首部/握手/UDP 首部）是传输层细节。与面试20题：面试第1题（三次握手）、第2题（四次挥手）、第3题（TCP/UDP）、第4题（可靠传输）、第5题（流控拥塞）、第6题（拥塞四算法）全部对应本题知识点。面试追问：①「传输层为什么是第一个实现端到端的层？」——网络层只到主机，传输层用端口号区分进程，实现进程到进程的通信。②「UDP 也提供端到端通信，为什么不叫可靠？」——UDP 提供进程到进程的交付（端到端通信），但不保证可靠；「端到端可靠传输」特指 TCP。
60. TCP建立连接需要（ ）次握手，释放连接需要（ ）次挥手。
A. 2，3 B. 3，3 C. 4，3 D. 3，4
答案：D解析：① 考点定位 TCP 连接建立（三次握手）与连接释放（四次挥手）的次数。
② 知识精讲 TCP 是面向连接的协议，通信前必须建立连接、通信后必须释放连接：
- 三次握手（建立连接）：
- 客户端→服务器：SYN=1, seq=x（我要建立连接，初始序号 x）
- 服务器→客户端：SYN=1, ACK=1, seq=y, ack=x+1（同意，我的序号 y，确认你的 x）
- 客户端→服务器：ACK=1, seq=x+1, ack=y+1（确认你的 y，连接建立）
- 四次挥手（释放连接）：
- 主动关闭方→被动方：FIN=1（我没有数据要发了）
- 被动方→主动方：ACK=1（收到了，但我可能还有数据）
- 被动方→主动方：FIN=1（我也没数据了）
- 主动方→被动方：ACK=1（确认，进入TIME_WAIT）
为什么建立用 3 次而释放用 4 次？建立连接时，服务器的 SYN 和 ACK 可以合并到同一个报文中（第 2 步同时确认对方并发出自己的 SYN），所以少一次。释放连接时，被动方收到 FIN 后可能还有数据要发送，不能立即发 FIN，必须先单独回 ACK，等数据发完再发 FIN，因此 ACK 和 FIN 分开发送，多一次。
③ 本题解析 TCP 建立连接需要三次握手，释放连接需要四次挥手。题干选项中”3，4“对应”建立 3 次握手、释放 4 次挥手“，即选项 D。
④ 选项逐项辨析
- A 2，3：握手不可能只用 2 次（无法防止失效请求），挥手也不是 3 次，错误。
- B 3，3：握手 3 次正确，但挥手不是 3 次而是 4 次，错误。
- C 4，3：握手 4 次错误、挥手 3 次错误，均与 TCP 实际不符。
- D 3，4：握手 3 次、挥手 4 次，正确。
常见误解来源： 记成「三次挥手、四次握手」说反；或以为释放比建立更简单所以次数更少。
⑤ 易混对比 ”三次握手“与”四次挥手“的次数差异是经典考点。关键区别：连接建立时服务器可以将 SYN+ACK 合并；连接释放时被动方必须先回 ACK 再发 FIN，不能合并（因为中间可能有残留数据要发）。如果被动方无残留数据，某些实现中第 2、3 步也可合并（称为”三次挥手“），但标准描述为四次。
⑥ 拓展延伸 三次握手的核心目的有二：①同步双方初始序号（ISN）；②防止已失效的连接请求突然到达服务器造成错误连接（若用两次握手，失效的 SYN 延迟到达后服务器会误开连接浪费资源）。四次挥手的 TIME_WAIT 状态（持续 2MSL）保证最后一个 ACK 若丢失对方还能重传 FIN。
⑦ 真题变式 ”为什么 TCP 建立连接用三次握手而不是两次？“→答案：防止已失效的连接请求到达服务器造成资源浪费。”为什么释放连接需要四次而非三次？“→因为 TCP 全双工，两个方向需独立关闭，被动方收到 FIN 后可能还有数据要发。
⑧ 记忆锚点 口诀”建三释四“——建立连接 3 次握手（SYN+ACK 可合并→少一次），释放连接 4 次挥手（ACK 和 FIN 必须分开→多一次）。
⑨ 知识关联： 主库题群：与第61题（第二次握手标志位）、第62题（挥手最后一个报文）、第63题（TIME_WAIT 时长）、第117题（SYN Flood）构成「TCP 连接管理」核心簇。与补题：补-12（三次握手必要性）。与面试20题：面试第1题（三次握手，热度 654）、第2题（四次挥手与 TIME_WAIT，热度 654）是互联网面试最高频网络题。面试追问：①「为什么握手 3 次挥手 4 次？」——握手时服务器 SYN+ACK 可合并；挥手时被动方 ACK 和 FIN 必须分开（可能还有数据要发）。②「TIME_WAIT 为什么要等 2MSL？」——①保证最后一个 ACK 能到达（若丢，对方重传 FIN 时己方还在）；②让本次连接的旧报文在网络中消亡。
61. TCP三次握手第二步，服务器报文中SYN与ACK的值分别是（ ）。
A. SYN=1, ACK=0 B. SYN=0, ACK=1 C. SYN=1, ACK=1 D. SYN=0, ACK=0
答案：C解析：① 考点定位 三次握手第二步（服务器→客户端）报文中 SYN 与 ACK 标志位的值。
② 知识精讲 三次握手完整三步的标志位：
| 步骤 | 方向 | SYN | ACK | seq | ack | 含义 |
|---|---|---|---|---|---|---|
| 第 1 步 | 客户端→服务器 | 1 | 0 | x | — | 请求建立连接，序号 x |
| 第 2 步 | 服务器→客户端 | 1 | 1 | y | x+1 | 同意建立 + 确认收到你的 SYN |
| 第 3 步 | 客户端→服务器 | 0 | 1 | x+1 | y+1 | 确认收到你的 SYN，连接建立 |
第 2 步报文同时携带 SYN=1 和 ACK=1：
- SYN=1：服务器也在发起自己的同步（告知自己的初始序号 y）；
- ACK=1：确认收到了客户端的 SYN（确认号 ack=x+1，表示”期望下一个收到 x+1”）。
序号计算规律：确认号 = 对方序号 + 对方数据长度。SYN 和 FIN 各消耗 1 个序号，所以 ack=x+1（客户端只发了 SYN，占 1 个序号）。
设计动机： 为何第二步必须 SYN=1 且 ACK=1？服务器既要同意建立连接并同步自己的初始序号 y（故 SYN=1），又要确认客户端的 SYN 与序号 x（故 ACK=1，ack=x+1）。若只发 SYN 不发 ACK，服务器无法向客户端证明「我已收到你的请求」；若只发 ACK 不发 SYN，服务器未同步自身序号，后续无法可靠传输。把两件事合并在一个报文，正是三次握手只需三步而不是四步的原因。
③ 本题解析 三次握手第二步，服务器报文中 SYN=1 且 ACK=1（两者同时为 1），对应选项 C。
④ 选项逐项辨析
- A SYN=1, ACK=0：这是第一步（客户端的纯 SYN 报文），错误。
- B SYN=0, ACK=1：这是第三步（客户端的纯 ACK 报文），错误。
- C SYN=1, ACK=1：第二步，服务器既同步又确认，正确。
- D SYN=0, ACK=0：既不建立连接也不确认，无意义，错误。
常见误解来源： 第二次握手只填 SYN=1 或只填 ACK=1；正确是 SYN=1 且 ACK=1。
⑤ 易混对比
| 握手步骤 | SYN | ACK | 报文名 | 序号字段 | 确认号 | 状态迁移 |
|---|---|---|---|---|---|---|
| 第1步 C→S | 1 | 0 | SYN | seq=x | — | C: SYN-SENT |
| 第2步 S→C | 1 | 1 | SYN+ACK | seq=y | ack=x+1 | S: SYN-RCVD |
| 第3步 C→S | 0 | 1 | ACK | seq=x+1 | ack=y+1 | 双方 ESTABLISHED |
| 标志位递变口诀：1-0 → 1-1 → 0-1。第2步是唯一「双标志同时置 1」的报文。 |
⑥ 拓展延伸工程实践： Wireshark 过滤 tcp.flags.syn==1 and tcp.flags.ack==1 可单独看 SYN+ACK；若只见 SYN 不见 SYN+ACK，常见原因是目标端口未监听、防火墙丢弃或半连接队列打满（SYN Flood）。面试追问： ①「为什么 ack=x+1 而不是 x？」——SYN 虽不携带数据但消耗一个序号，确认号表示「期望下一个收到的字节」。②「若 SYN+ACK 丢失会怎样？」——客户端超时重传 SYN，服务器重传 SYN+ACK；tcp_synack_retries 控制放弃次数。
⑦ 真题变式 “三次握手第三步报文的标志位？”→SYN=0, ACK=1。“三次握手中哪一步同时携带 SYN 和 ACK？”→第二步。
⑧ 记忆锚点 三步标志位递变“1-0 → 1-1 → 0-1”，第二步两者都为 1。口诀“一头一尾一个 1，中间两个 1”。
⑨ 知识关联：主库题群：第60题（握手/挥手次数）、第61题（本题 SYN/ACK 取值）、第62题（挥手末报文）、第63题（TIME_WAIT）、第117题（SYN Flood）构成「TCP 连接管理」核心簇；与第64/121（TCP 特性）、第72（端口五元组）同属传输层。与补题：补-11（TCP 首部标志位 URG/ACK/PSH/RST/SYN/FIN 与最小首部 20 字节）、补-12（为何三次而不是两次）。与面试20题：面试第1题（三次握手完整过程与动机）。面试追问：①「第二次握手 SYN/ACK 取值？」——均为 1。②「三次握手能否并成两次？」——不能，否则服务器无法确认客户端已收到自己的 SYN+ACK，且无法防历史连接。
62. TCP四次挥手中，主动关闭方发送的最后一个报文是（ ）。
A. SYN=1 B. FIN=1 C. ACK=1 D. RST=1
答案：C解析：① 考点定位 四次挥手中主动关闭方发送的最后一个报文及其标志位。
② 知识精讲 四次挥手完整流程：
| 步骤 | 方向 | 标志 | 主动方状态变化 | 被动方状态变化 |
|---|---|---|---|---|
| 第 1 步 | 主动方→被动方 | FIN=1 | ESTABLISHED→FIN_WAIT_1 | — |
| 第 2 步 | 被动方→主动方 | ACK=1 | FIN_WAIT_1→FIN_WAIT_2 | ESTABLISHED→CLOSE_WAIT |
| 第 3 步 | 被动方→主动方 | FIN=1 | 仍处 FIN_WAIT_2（收到对方 FIN） | CLOSE_WAIT→LAST_ACK |
| 第 4 步 | 主动方→被动方 | ACK=1 | FIN_WAIT_2→TIME_WAIT（再等 2MSL 后 CLOSED） | LAST_ACK→CLOSED |
主动关闭方发送的最后一个报文是第 4 步的 ACK=1，用于确认收到了被动方的 FIN。发送后进入 TIME_WAIT 状态，持续 2MSL 后才真正关闭。
理解要点： 四次挥手的本质是 TCP 全双工带来的半关闭（half-close）语义——每个方向必须单独关闭。主动方发 FIN 只表示我没有数据要发了，仍可接收；被动方回 ACK 后进入 CLOSE_WAIT，此时应用层可能还在写数据，因此 ACK 与 FIN 往往不能合并，这才比握手多出一次。若被动方恰好也无数据可发，可把 ACK+FIN 合并（称为三次挥手的特殊情况），但协议状态机仍是四次迁移。TIME_WAIT 只出现在主动关闭方：一是保证最后一个 ACK 丢失时能重传，二是让本连接残留报文在 2MSL 内消亡，避免干扰相同四元组的新连接。工程上大量 CLOSE_WAIT 是应用未 close 的 bug；大量 TIME_WAIT 多为短连接正常现象，优先用 keep-alive/连接池而非关闭 TIME_WAIT。
③ 本题解析 四次挥手中主动关闭方先发 FIN（第 1 步），最后发 ACK（第 4 步），答案是 ACK=1，即选项 C。
④ 选项逐项辨析
- A SYN=1：SYN 是建立连接用的标志位，挥手不涉及，错误。
- B FIN=1：FIN 是主动方第 1 步和被动方第 3 步发的，不是最后一个报文，错误。
- C ACK=1：第 4 步主动方回 ACK 确认被动方的 FIN，是最后一个报文，正确。
- D RST=1：RST 用于异常时强制复位连接，不属于正常挥手流程，错误。
常见误解来源： 以为主动关闭方最后报文是 FIN；最后是 ACK（确认对方 FIN）。
⑤ 易混对比 FIN 和 ACK 在挥手中的角色：FIN 表示”我没有数据要发了“（单向关闭），ACK 表示”收到了你的 FIN”。主动方发 FIN（第 1 步）→被动方回 ACK（第 2 步）→被动方发 FIN（第 3 步）→主动方回 ACK（第 4 步，最后一击）。
⑥ 拓展延伸 为什么第 2、3 步不能合并？因为被动方收到 FIN 后可能还有数据要发送（半关闭状态），必须先回 ACK 告知对方“收到了你的关闭请求”，等自己的数据发完再发 FIN。这种“先确认、后关闭”的设计保证了数据不会丢失。
⑦ 真题变式 “四次挥手中被动方发送的第一个报文是什么？”→ACK=1（第 2 步）。“四次挥手中主动方进入 TIME_WAIT 是在第几步之后？”→第 4 步（发送最后一个 ACK 之后）。
⑧ 记忆锚点 口诀“挥四手：FIN→ACK→FIN→ACK”，主动方”先 FIN 后 ACK，首尾呼应“，最后一击是 ACK。
⑨ 知识关联： 主库题群：与第60题（握手挥手次数）、第61题（握手标志位）、第63题（TIME_WAIT）、第138题（CLOSE_WAIT）构成 TCP 连接管理簇。与补题：无直接补题。与面试20题：面试第2题（四次挥手与 TIME_WAIT）详细描述了四步报文。面试追问：①「主动关闭方的最后一个报文是什么？」——ACK（确认对方的 FIN），之后进入 TIME_WAIT。②「被动关闭方最后一个报文是什么？」——FIN（数据发完后发出），之后进入 LAST_ACK。
63. TCP中TIME_WAIT状态持续（ ）。
A. 1MSL B. 2MSL C. 4MSL D. 8MSL
答案：B解析：① 考点定位 TCP TIME_WAIT 状态的持续时间。
② 知识精讲 TIME_WAIT 是主动关闭方发送最后一个 ACK 后进入的状态，持续 2MSL（Maximum Segment Lifetime，报文段最长生存时间）。
- MSL：报文段在网络中最长存活时间，RFC 793 取 2 分钟，据此 2MSL = 4 分钟（理论值）。Linux 并没有 MSL 这个可配置参数（
sysctl -a查不到），TIME_WAIT 的时长由内核常量TCP_TIMEWAIT_LEN = 60 s（定义在include/net/tcp.h，硬编码、不可经 sysctl 调整）直接给出；60 s 是工程折中，不能反推成「Linux 的 MSL = 30 秒」再乘 2，两套数字不要焊成一条推导链。 - 两大目的：
- 保证最后一个 ACK 可达：若主动方的 ACK 丢失，被动方会超时重传 FIN，主动方在 TIME_WAIT 期间还能收到并重发 ACK，确保连接正常关闭。若提前关闭则无法响应重传，被动方将永远停留在 LAST_ACK。
- 让残留报文消失：2MSL 的时间足以让本次连接的所有残留报文（可能因路由环路而延迟到达）在网络中消亡，避免它们被误认为是新连接的报文（四元组复用问题）。
设计动机（为何是 2MSL 而不是立刻关闭）： TIME_WAIT 持续 2MSL 有两个不可省略的目的：其一，若主动方最后的 ACK 丢失，被动方会重传 FIN，主动方在 TIME_WAIT 期间仍能响应并再次 ACK，保证连接可靠关闭；其二，等待 2MSL 使本连接残留的报文在网络中消亡，避免旧连接的迟到报文被误当作新连接的数据（新连接四元组可能复用）。MSL 是报文段在网络中的最长生存时间，教材按 RFC 793 取 2 分钟，故 2MSL 的理论值是 4 分钟；Linux 不实现 MSL 参数，TIME_WAIT 实际由内核常量 TCP_TIMEWAIT_LEN = 60 s 硬编码决定（规范口径与实现口径各说各话，别写成「30 秒×2=60 秒」的推导链）。
③ 本题解析 TIME_WAIT 持续 2MSL，对应选项 B。
④ 选项逐项辨析
- A 1MSL：不足以保证残留报文全部消失（一个 MSL 只能保证一个方向的报文消失），错误。
- B 2MSL：标准答案，保证 ACK 可重传且残留报文消失，正确。
- C 4MSL：过于保守，标准协议定义为 2MSL，错误。
- D 8MSL：完全没有依据，错误。
常见误解来源： 答 1MSL 或 3MSL；标准是 2MSL。或与 CLOSE_WAIT 持续时间混淆。
⑤ 易混对比
| 状态 | 进入方 | 触发动作 | 持续时长 | 离开条件 | 排障含义 |
|---|---|---|---|---|---|
| TIME_WAIT | 主动关闭方 | 发完最后一个 ACK | 2MSL | 定时器到 | 高并发短连接正常现象，过多耗端口 |
| CLOSE_WAIT | 被动关闭方 | 收到 FIN 并回 ACK | 直到应用 close | 应用层调用关闭 | 应用未关 socket 的代码缺陷 |
| FIN_WAIT_2 | 主动关闭方 | 收到对 FIN 的 ACK | 等对方 FIN | 收到 FIN | 对端迟迟不发 FIN |
| LAST_ACK | 被动关闭方 | 己方发完 FIN | 等最后 ACK | 收到 ACK | 最后 ACK 丢失会重传 FIN |
⑥ 拓展延伸工程实践： 用 ss -tan 统计状态分布。大量 TIME_WAIT 时可启用 tcp_tw_reuse（复用 TIME_WAIT 端口给新出站连接）、限制 tcp_max_tw_buckets；注意 tcp_tw_recycle 在 NAT 环境会导致误杀，Linux 4.12 后已移除。大量 CLOSE_WAIT 则必须查业务代码是否漏关连接/未处理异常路径。面试追问：①「TIME_WAIT 为什么是主动关闭方而不是被动方？」——主动方负责保证最后 ACK 可达。②「服务器出现大量 TIME_WAIT 说明什么？」——短连接多、且由该侧主动关闭；可考虑 keep-alive 复用连接。
⑦ 真题变式 “TIME_WAIT 状态的两个主要目的是什么？”→①保证最后一个 ACK 可达（对方重传 FIN 时能响应）；②让本连接的残留报文在网络中消失。“CLOSE_WAIT 状态说明什么问题？”→应用层未正确关闭 socket。
⑧ 记忆锚点 “TIME_WAIT = 2MSL”——两个目的，两倍 MSL。口诀“主动关方等两倍，残留报文全消内”。
⑨ 知识关联：主库题群：第60题（挥手次数）、第62题（挥手主动方末报文=ACK）、第63题（本题 TIME_WAIT=2MSL）、第138题（CLOSE_WAIT 业务未关连接）构成「TCP 状态机」簇；与第68/69（超时与重传时序）相关。与补题：补-12（三次握手动机，与挥手对比：为何挥手是四次——ACK 与 FIN 常不能合并）。与面试20题：面试第2题（四次挥手与 TIME_WAIT/2MSL，核心必考）。面试追问：①「TIME_WAIT 持续多久？」——规范是 2MSL；教材按 MSL=2 min 推得约 4 分钟（理论值），Linux 实现则用内核常量 TCP_TIMEWAIT_LEN 固定为 60 秒（没有 MSL 参数可配）。②「大量 CLOSE_WAIT 怎么排查？」——被动方应用未调用 close，查代码与连接池泄漏。
64. UDP协议的特点是（ ）。
A. 提供可靠传输 B. 有拥塞控制 C. 首部开销小（8字节） D. 必须先建立连接
答案：C解析：① 考点定位 UDP 协议的核心特点。
② 知识精讲 UDP（用户数据报协议）是无连接、不可靠的传输层协议，核心特点：
| 特性 | UDP | TCP |
|---|---|---|
| 连接 | 无连接 | 面向连接 |
| 可靠性 | 不可靠（尽最大努力） | 可靠（确认、重传） |
| 拥塞控制 | 无 | 有（慢开始、拥塞避免等） |
| 首部开销 | 8 字节（源端口+目的端口+长度+校验和） | 20 字节（最小） |
| 传输效率 | 高（无控制开销） | 较低 |
| 通信方式 | 一对一/一对多/多对多 | 仅一对一 |
UDP 首部仅 8 字节 = 源端口(2) + 目的端口(2) + 长度(2) + 校验和(2)，非常精简。
设计动机与适用边界： UDP 刻意不做可靠传输、排序、去重与流量/拥塞控制，换来的是极低开销、低时延、支持一对多/多对多。它把可靠性责任完全交给应用层——需要可靠就自己在 UDP 之上做确认重传与拥塞控制（如 QUIC、TFTP、WebRTC），不需要就纯发。首部固定 8 字节且无选项，仅源端口、目的端口、长度、校验和四字段；发送前无需握手、无确认，适合查询-应答型（DNS、DHCP）与实时流——这些场景里重传旧包往往已无意义（时过境迁），应用更希望「尽快拿到最新数据，丢一点无所谓」。校验和覆盖伪首部（源/目的 IP 等），伪首部只参与计算、不在网络上传输，用于发现 IP 层「送错主机/送错协议」。考试常见误区是把 UDP 理解成「坏的 TCP」；正确视角是：UDP 是最小传输服务（薄传输层），TCP 是在其上叠加可靠性的重量级协议，QUIC/WebRTC 的存在正说明 UDP 并非「不能可靠」。
③ 本题解析 UDP 的标志性特点之一就是首部开销小（仅 8 字节），对应选项 C。UDP 不提供可靠传输、无拥塞控制、不需要建立连接。
④ 选项逐项辨析
- A 提供可靠传输：这是 TCP 的特性，UDP 不保证可靠，错误。
- B 有拥塞控制：这也是 TCP 的特性，UDP 无拥塞控制（发送速率不受网络状况影响），错误。
- C 首部开销小（8字节）：UDP 首部仅 8 字节，远小于 TCP 最小 20 字节，正确。
- D 必须先建立连接：UDP 无连接，不需要握手，错误。
常见误解来源： 把 UDP 说成有连接但不可靠；UDP 是无连接。或以为首部 20 字节。
⑤ 易混对比
| 对比项 | UDP | TCP |
|---|---|---|
| 连接 | 无连接 | 面向连接（三次握手） |
| 可靠性 | 尽最大努力交付 | 确认、排序、重传、去重 |
| 首部 | 8 字节 | 最小 20 字节 |
| 拥塞/流控 | 默认无 | rwnd + cwnd |
| 交付方式 | 报文边界保留 | 字节流（可能粘包） |
| 典型应用 | DNS、DHCP、SNMP、直播、QUIC | HTTP/1.1、SMTP、SSH、文件传输 |
| 一对多 | 天然支持广播/多播 | 仅单播 |
⑥ 拓展延伸工程实践： 抓包过滤 udp.port==53 可看 DNS；游戏/直播弱网调优常在应用层加 FEC 与选择性重传，而非改用 TCP。丢包率高时 TCP 会全局降窗拖累延迟，UDP 应用可自控发送节奏。面试追问：①「UDP 都不可靠吗？」——UDP 本身不可靠，但 QUIC 在 UDP 上实现了可靠传输与 TLS。②「为何 DNS 默认 UDP？」——查询短、一问一答，握手开销不划算；大响应或区域传送改 TCP。③「UDP 校验和伪首部作用？」——防止 IP 层交付到错误主机/协议。
⑦ 真题变式 “以下哪个不是 UDP 的特点？A. 无连接 B. 不可靠 C. 首部20字节 D. 支持广播”→C（UDP 首部 8 字节，20 字节是 TCP）。“UDP 首部包含哪些字段？”→源端口、目的端口、长度、校验和。
⑧ 记忆锚点 UDP 首部“四字段八字节”——源端口(2)+目的端口(2)+长度(2)+校验和(2)=8。对比 TCP 最少 20 字节。口诀“UDP 八字节真轻巧，不连不拥不可靠”。
⑨ 知识关联：主库题群：第64题（本题 UDP 特点）、第65题（哪些应用用 UDP）、第72题（TCP/UDP 端口独立命名空间）、第121题（TCP 与 UDP 对比）构成「传输层协议选型」簇。与补题：补-13（UDP 叙述辨析、首部与伪首部）。与面试20题：面试第3题（TCP/UDP 区别及适用场景）、面试第20题（应用层端口与承载协议）。面试追问：①「什么场景选 UDP？」——实时音视频、DNS、物联网遥测、QUIC。②「UDP 如何做拥塞控制？」——在应用层或 QUIC 中实现，不能假设网络无限。
65. 下列应用层协议中，使用UDP的是（ ）。
A. HTTP B. FTP C. DNS（查询） D. SMTP
答案：C解析：① 考点定位 应用层协议与传输层协议的对应关系——哪些协议使用 UDP。
② 知识精讲 常见应用层协议按传输层分类：
| 协议 | 端口 | 传输层 | 说明 |
|---|---|---|---|
| DNS（查询） | 53 | UDP | 查询报文小，要求快速 |
| DHCP | 67/68 | UDP | 广播发现，无连接 |
| SNMP | 161/162 | UDP | 网络管理，简单轻量 |
| TFTP | 69 | UDP | 简单文件传输 |
| NTP | 123 | UDP | 时间同步 |
| HTTP | 80 | TCP | 网页传输 |
| HTTPS | 443 | TCP | 加密网页 |
| FTP | 20/21 | TCP | 文件传输 |
| SMTP | 25 | TCP | 邮件发送 |
| POP3 | 110 | TCP | 邮件接收 |
| SSH | 22 | TCP | 安全远程登录 |
| Telnet | 23 | TCP | 远程登录 |
注意：DNS 区域传送（zone transfer）使用 TCP，因为数据量大需要可靠传输；日常 DNS 查询用 UDP。HTTP/3 基于 QUIC（UDP 之上），是近年趋势。
选型规律（背结论不如背理由）： 用 UDP 的应用通常满足以下至少一条——1)请求-响应、报文小（DNS 查询、SNMP Get）；2)能容忍丢失、重传反而更糟（实时音视频、游戏状态）；3)需要广播/多播（DHCP Discover、RIP、mDNS）；4)实现要极简（TFTP、NTP）。用 TCP 的应用则要求字节流完整、有序、不丢（文件、邮件、网页、登录会话）。注意边界情况：DNS 区域传送与 DNSSEC 用 TCP；HTTP/3 与 QUIC 跑在 UDP 上但内部自建可靠与加密，不能因此说 HTTP 用 UDP。笔试若问下列哪个协议使用 UDP，先排除明显需要可靠传输的文件/会话类，再在 DNS/DHCP/SNMP/TFTP/NTP 中选。
③ 本题解析 题干问“使用 UDP 的应用层协议”。HTTP、FTP、SMTP 都基于 TCP，只有 DNS（查询） 基于 UDP，对应选项 C。
④ 选项逐项辨析
- A HTTP：基于 TCP（80 端口），可靠传输网页数据，错误。
- B FTP：基于 TCP（20/21 端口），可靠传输文件，错误。
- C DNS（查询）：日常 DNS 查询基于 UDP（53 端口），快速高效，正确。
- D SMTP：基于 TCP（25 端口），可靠传输邮件，错误。
常见误解来源： 选 HTTP/FTP/SMTP 当 UDP 应用；这些是 TCP。UDP 代表：DNS 查询、DHCP、SNMP、TFTP、NTP。
⑤ 易混对比 DNS 的双重身份是最高频考点：“DNS 查询用 UDP（日常解析），DNS 区域传送用 TCP（大数据量同步）”。这是因为查询报文通常很小（一个请求一个响应），UDP 即可；区域传送涉及大量记录数据，需要 TCP 的可靠性。
⑥ 拓展延伸 HTTP/3 是重要新考点：HTTP/3 放弃 TCP，改用基于 UDP 的 QUIC 协议，解决了 TCP 队头阻塞问题（一个流丢包不影响其他流）。但 HTTP/1.1 和 HTTP/2 仍然基于 TCP。注意题干问“DNS（查询）”时明确是 UDP。
⑦ 真题变式 “以下协议中，使用 TCP 的是？A. DNS B. DHCP C. FTP D. SNMP”→C（FTP 用 TCP）。”DNS 区域传送使用什么传输层协议？“→TCP（非 UDP）。
⑧ 记忆锚点 口诀”DNS 平时 UDP 快，区域传送 TCP 来“。TCP 阵营：HTTP、HTTPS、FTP、SMTP、POP3、SSH、Telnet；UDP 阵营：DNS、DHCP、SNMP、TFTP、NTP。
⑨ 知识关联： 主库题群：与第64题（UDP 特点）、第74-76题（应用层端口）构成「传输层与应用」题群。与补题：补-14（SMTP/POP3/IMAP 用 TCP）。与面试20题：面试第3题（TCP/UDP 适用场景）、第20题（应用层协议端口表）。面试追问：①「DNS 为什么用 UDP？」——查询报文小、一问一答、要低延迟；丢包由应用层超时重传兜底；大响应或区域传送改用 TCP。②「HTTP/3 为什么用 UDP？」——QUIC 在 UDP 上自行实现可靠传输与多路复用，解决 TCP 层队头阻塞。
66. TCP流量控制的目的是（ ）。
A. 防止发送方发送过快使接收方缓冲区溢出 B. 防止网络拥塞 C. 防止路由环路 D. 提高加密强度
答案：A解析：① 考点定位 TCP 流量控制的目的，及与拥塞控制的区分。
② 知识精讲 传输层两大控制机制常被混淆：
- 流量控制（Flow Control）：防止发送方发送过快导致接收方缓冲区溢出。匹配的是”发送速率 vs 接收方处理能力“，由接收窗口（rwnd） 控制——接收方在 TCP 首部窗口字段中告知发送方自己还能接收多少数据，发送方据此调整发送窗口。是”接收方说了算“。
- 拥塞控制（Congestion Control）：防止发送方发送过快导致网络拥塞（丢包/延迟增大）。匹配的是”发送速率 vs 网络承载能力“，由拥塞窗口（cwnd） 控制——发送方通过慢开始、拥塞避免、快重传、快恢复等算法探测网络容量。是”发送方自己推断的“。
设计动机： 流量控制要解决的是「快发送方压垮慢接收方」。TCP 接收方有有限缓冲区；若发送方持续高速注入，缓冲区溢出只能丢弃，造成无谓重传。接收方在每个 ACK 中通告接收窗口 rwnd（自己还能收多少字节），发送方发送窗口不得超过 rwnd。这与拥塞控制不同：拥塞控制防止压垮网络中间设备，依据是发送方自己估计的 cwnd。最终发送窗口 = min(rwnd, cwnd)。当 rwnd=0 时发送方启动持续定时器，周期发送零窗口探测段，避免互相等待死锁。
③ 本题解析 流量控制的目的是防止发送方发送过快使接收方缓冲区溢出，对应选项 A。
④ 选项逐项辨析
- A 防止发送方发送过快使接收方缓冲区溢出：这是流量控制的精确定义，正确。
- B 防止网络拥塞：这是拥塞控制的目的，混淆了两个概念，错误。
- C 防止路由环路：这是网络层 TTL 或路由协议防环机制的事，与传输层无关，错误。
- D 提高加密强度：与流量控制完全无关，错误。
常见误解来源： 把流量控制说成防止网络拥塞（那是拥塞控制）。流量控制对端到端接收能力。
⑤ 易混对比
| 对比项 | 流量控制 | 拥塞控制 |
|---|---|---|
| 保护对象 | 接收方缓冲区 | 网络（路由器/链路） |
| 依据窗口 | rwnd（接收方通告） | cwnd（发送方估计） |
| 驱动方 | 接收方反馈 | 发送方观察丢包/时延 |
| 典型信号 | 窗口字段变小/为 0 | 超时、3 个重复 ACK |
| 算法 | 窗口通告、零窗口探测 | 慢开始、拥塞避免、快重传、快恢复 |
| 最终窗口 | 参与 min(rwnd,cwnd) | 参与 min(rwnd,cwnd) |
⑥ 拓展延伸工程实践： 抓包中 Window Update 表示接收方应用读走了数据、rwnd 恢复；持续 rwnd=0 称为零窗口，可能是对端应用阻塞或缓冲设置过小。BDP 较大的链路需启用 Window Scale，否则 rwnd 上限 65535 限制吞吐。面试追问：①「流量控制和拥塞控制能否只留一个？」——不能，二者约束不同，必须同时满足。②「rwnd 为 0 后如何恢复？」——接收方发送窗口更新报文；发送方靠持续定时器探测。
⑦ 真题变式 “TCP 拥塞控制的目的是什么？“→防止网络拥塞（B 选项的描述）。”流量控制由什么窗口控制？“→接收窗口（rwnd）。”发送窗口取决于什么？“→min(rwnd, cwnd)。
⑧ 记忆锚点 口诀”流量控收方、拥塞控网络“。rwnd=r(eceive) window 管接收方，cwnd=c(ongestion) window 管网络。
⑨ 知识关联：主库题群：第66题（本题流控目的）、第67题（发送窗口取决于 min(rwnd,cwnd)）、第68-71题（拥塞控制四算法）、第127题（带宽时延积与窗口）构成「TCP 窗口与控制」大簇。与补题：补-03（GBN 发送窗口上限）、补-04（SR 收发窗口），滑动窗口理论同源。与面试20题：面试第5题（流控 vs 拥塞控制）、面试第4题（可靠传输机制）。面试追问：①「发送窗口公式？」——min(rwnd, cwnd)。②「零窗口死锁如何避免？」——持续定时器 + 1 字节探测。
67. TCP发送窗口的大小取决于（ ）。
A. 仅接收窗口 B. 仅拥塞窗口 C. 接收窗口与拥塞窗口中的较小值 D. 接收窗口与拥塞窗口中的较大值
答案：C解析：① 考点定位 TCP 发送窗口大小的确定依据——接收窗口与拥塞窗口的关系。
② 知识精讲 TCP 发送方的实际发送窗口由两个窗口共同约束：
- 接收窗口 rwnd：接收方通告的可用缓冲区大小（流量控制约束，防止接收方溢出）。
- 拥塞窗口 cwnd：发送方根据网络拥塞状况推断出的窗口大小（拥塞控制约束，防止网络过载）。
发送窗口 = min(rwnd, cwnd)——取两者中的较小值。这体现了”双重保险、保守原则“：
- 若 rwnd < cwnd：接收方是瓶颈（接收方处理慢），发送速率受 rwnd 限制。
- 若 cwnd < rwnd：网络是瓶颈（网络可能拥塞），发送速率受 cwnd 限制。
- 两者谁小听谁的，同时不超过接收方能力和网络承载能力。
设计动机： 发送窗口取 min(rwnd, cwnd) 而不是任取其一，体现了「同时满足两类约束」的保守原则：rwnd 是接收方处理能力的上限，cwnd 是当前网络可承受的上限。若只按 cwnd 发送，可能压垮接收方；若只按 rwnd 发送，可能拥塞网络。类比水桶短板：流量取决于最窄处。rwnd 在 TCP 首部 16 位窗口字段通告，cwnd 由发送方根据丢包/ACK 行为本地维护。高带宽长肥管道还需 Window Scale 选项放大窗口，否则吞吐被 64KB 窗口锁死。
③ 本题解析 发送窗口取接收窗口与拥塞窗口中的较小值，对应选项 C。
④ 选项逐项辨析
- A 仅接收窗口：忽略了网络拥塞因素，可能加剧网络拥塞，错误。
- B 仅拥塞窗口：忽略了接收方缓冲能力，可能使接收方溢出，错误。
- C 接收窗口与拥塞窗口中的较小值：min(rwnd, cwnd)，双重约束取小，正确。
- D 接收窗口与拥塞窗口中的较大值：取大值会导致超过某一方的限制，违背保守原则，错误。
常见误解来源： 以为发送窗口只由接收方决定；实际发送窗口=min(rwnd, cwnd)。
⑤ 易混对比
| 窗口 | 维护方 | 反映什么 | 变化来源 |
|---|---|---|---|
| rwnd | 接收方 | 接收缓冲可用空间 | 应用读取速度、缓冲大小 |
| cwnd | 发送方 | 网络可用容量估计 | 慢开始/拥塞避免/超时/快恢复 |
| 发送窗口 | 发送方执行 | 实际允许在途数据 | min(rwnd, cwnd) |
| 建议缓存（BDP） | 规划 | 窗口理想下限 | 带宽 × RTT |
⑥ 拓展延伸工程实践： Linux ss -ti 可看 cwnd/rwnd/ssthresh；性能差时若 rwnd 一直很小，查接收方应用消费速度；若 cwnd 反复塌陷，查网络丢包/缓冲膨胀。长肥网络必须开启窗口缩放与合理 socket 缓冲。面试追问：①「为什么不是 rwnd+cwnd？」——两约束需同时满足，应取交集即最小值。②「BDP 和窗口什么关系？」——窗口应不小于带宽×RTT，否则管道填不满。
⑦ 真题变式 ”若 rwnd=10KB, cwnd=8KB，发送窗口是多少？“→8KB（取小）。”若 rwnd=0，发送方会怎样？“→发送窗口为 0，停止发送数据，但定期发零窗口探测报文。
⑧ 记忆锚点 ”发送窗口=min(rwnd,cwnd)”——水桶效应，短板决定流量。口诀“两窗取小方安全，谁小听谁管得严”。
⑨ 知识关联：主库题群：第66题（流控）、第67题（本题 min(rwnd,cwnd)）、第68-71题（拥塞）、第127题（BDP 计算）构成窗口题群。与补题：补-03/补-04（GBN/SR 窗口与序号位关系）。与面试20题：面试第5题（流控与拥塞）。面试追问：①「发送窗口由谁决定？」——接收方 rwnd 与发送方 cwnd 取小。②「窗口为 0 还能发数据吗？」——不能发新数据，只能发探测段。
68. TCP发送方连续收到3个重复ACK，通常会（ ）。
A. 慢开始 B. 仅拥塞避免 C. 快重传 D. 关闭连接
答案：C解析：① 考点定位 TCP 快重传机制——连续收到 3 个重复 ACK 时的响应。
② 知识精讲 TCP 拥塞控制的四个经典算法：慢开始、拥塞避免、快重传、快恢复。
- 快重传触发条件：发送方连续收到 3 个重复 ACK（即收到 4 个相同的 ACK）。
- 机制：重复 ACK 说明接收方已收到后续报文（序号大于丢失段），只有中间某段丢失。此时发送方不等超时计时器，立即重传丢失的报文段——这就是“快”重传。
- 后续动作：进入快恢复——ssthresh 设为当前 cwnd 的一半，cwnd 设为 ssthresh（而非降为 1），从 ssthresh 开始线性增长。
- 对比：超时重传时 cwnd 降为 1 进慢开始（惩罚更重）；快重传只减半进快恢复（惩罚较轻），因为重复 ACK 说明网络还能传数据（不算严重拥塞）。
设计动机： 为何「3 个重复 ACK」触发快重传？重复 ACK 表明：接收方仍在收后续数据（否则不会一直确认同一缺口），但中间缺了一段。这很可能是个别丢包而非全网瘫痪，若傻等 RTO（往往几百毫秒），吞吐骤降。因此发送方不等超时，立即重传丢失段，随后进入快恢复（cwnd 减半而非归 1）。为何不是 1 个重复 ACK？IP 网络允许乱序，1–2 个重复 ACK 可能只是包序颠倒；RFC 5681 将阈值定为 3，是误判率与响应速度的工程折中。快重传把丢包信号从时间域（超时）提前到反馈域（重复 ACK），是 TCP 性能的关键跃升。
③ 本题解析 连续收到 3 个重复 ACK 通常触发快重传，对应选项 C。
④ 选项逐项辨析
- A 慢开始：这是超时后的策略（cwnd 降为 1），重复 ACK 不需要如此激进，错误。
- B 仅拥塞避免：拥塞避免是线性增长阶段，不是对重复 ACK 的直接响应，错误。
- C 快重传：立即重传丢失段不必等待超时，正是对 3 个重复 ACK 的标准响应，正确。
- D 关闭连接：重复 ACK 只是提示丢包，不应关闭连接，错误。
常见误解来源： 3 个重复 ACK 时答「进入慢开始」或「等待超时」；应是快重传（及快恢复）。
⑤ 易混对比
| 事件 | 网络判断 | cwnd | ssthresh | 下一阶段 |
|---|---|---|---|---|
| 超时（RTO） | 严重拥塞 | 降为 1 | 旧 cwnd/2 | 慢开始 |
| 3 个重复 ACK | 个别丢包 | 减半或=ssthresh | 旧 cwnd/2 | 快恢复→拥塞避免 |
| 1–2 个重复 ACK | 可能乱序 | 不变 | 不变 | 继续等待 |
⑥ 拓展延伸工程实践： Wireshark 中连续多条 TCP Dup ACK 后紧跟 TCP Retransmission 是快重传典型痕迹；若大量出现，用专家信息看丢包位置。数据中心交换机缓冲过小或 ECN 未开时，重复 ACK 会显著增多。面试追问：①「快重传之后 cwnd 怎么变？」——进入快恢复，先设 ssthresh≈cwnd/2，cwnd=ssthresh，再线性增。②「和超时重传谁更乐观？」——快重传更乐观，因为仍有数据在到达。
⑦ 真题变式 “TCP 超时重传时 cwnd 怎么变化？“→cwnd=1 进慢开始。”快重传后进入什么阶段？“→快恢复（cwnd=ssthresh=cwnd/2）。”为什么快重传不像超时那样将 cwnd 降为 1？“→因为收到重复 ACK 说明后续报文仍能到达，网络并非严重拥塞。
⑧ 记忆锚点 “3 重复 ACK → 快重传 → 快恢复（减半）”。对比“超时 → 慢开始（归 1）”。口诀“三连重复快重传，只减半来不归零”。
⑨ 知识关联：主库题群：第66-67（窗口）、第68题（本题快重传）、第69题（超时后 cwnd=1）、第70题（拥塞辨析）、第71题（快恢复后进入拥塞避免）、第78题（乱序触发重复 ACK）构成「TCP 拥塞控制」核心簇。与补题：补-03（GBN）/补-04（SR）——链路层可靠传输思想与重复 ACK/SACK 相关。与面试20题：面试第6题（拥塞控制四算法）、面试第4题（可靠传输与快速重传）。面试追问：①「连续 3 个重复 ACK 后发送方做什么？」——立即快重传丢失段，不必等 RTO。②「为什么阈值是 3？」——过滤乱序噪声，RFC 5681 经验值。
69. TCP发生超时重传时，拥塞窗口通常会（ ）。
A. 保持不变 B. 增大一倍 C. 降为0并永久停止 D. 降为1并进入慢开始
答案：D解析：① 考点定位 TCP 超时重传时拥塞窗口的变化策略。
② 知识精讲 超时意味着报文长时间未被确认，网络可能严重拥塞。发送方采取最保守策略：
- cwnd 降为 1（一个 MSS），从最小窗口重新探测网络容量。
- ssthresh 设为当前 cwnd 的一半（更新慢开始阈值）。
- 重新进入慢开始阶段——cwnd 每 RTT 翻倍（指数增长），直到达到 ssthresh 后切换到拥塞避免（线性增长）。
这与快重传（收到 3 个重复 ACK）的温和处理形成对比：快重传只将 cwnd 减半并进入快恢复，不降为 1。
为什么超时要推倒重来： 超时定时器溢出说明较长时间没有任何确认到达，网络可能已严重拥塞甚至接近不可用。此时若仍维持较大窗口继续注入，只会加剧拥塞、导致全局同步与吞吐崩塌。因此 TCP 采取最保守策略：cwnd 直接降为 1 MSS，从最小窗口重新慢开始探测当前可用容量；同时把 ssthresh 记为超时前 cwnd 的一半，作为后续从指数增长切换到线性增长的阈值。对比：3 个重复 ACK 表明路径上至少还有一个 ACK 能回来，拥塞程度较轻，故只减半并进入快恢复，不降为 1。记住口诀：超时回 1，快重传减半。
设计动机： 超时意味着长时间完全收不到有效确认，发送方无法再从 ACK 流里获得「网络尚可」的旁证，只能假设拥塞已非常严重。此时采取最保守策略：cwnd=1（一个 MSS）、ssthresh=当前 cwnd 的一半，回到慢开始重新从最小窗口探测容量。这避免了在拥塞中继续注入大量数据造成更大崩溃。对比快重传路径（仍有重复 ACK 说明后续数据可达，仅需减半），超时路径的悬崖式下降是必要的安全阀。慢开始阶段 cwnd 每 RTT 约翻倍，到 ssthresh 后改为拥塞避免（每 RTT +1 MSS），整体呈锯齿波形。
③ 本题解析 超时重传时 cwnd 降为 1 并进入慢开始，对应选项 D。
④ 选项逐项辨析
- A 保持不变：超时说明网络出了严重问题，必须大幅收缩窗口，错误。
- B 增大一倍：与拥塞应对方向完全相反（应该减小不是增大），错误。
- C 降为 0 并永久停止：TCP 不会永久停止，只是降为 1 重新探测，错误。
- D 降为 1 并进入慢开始：标准策略——最保守地从 1 重新开始指数增长，正确。
常见误解来源： 超时后以为 cwnd 只减半；超时是降为 1（比快重传更狠）。
⑤ 易混对比
| 对比项 | 超时重传 | 快重传 |
|---|---|---|
| 触发 | RTO 到期 | 连续 3 个重复 ACK |
| 对网络的判断 | 严重拥塞 | 个别丢包 |
| cwnd | 1 | 减半（≈ssthresh） |
| ssthresh | 旧 cwnd/2 | 旧 cwnd/2 |
| 后续算法 | 慢开始 | 快恢复→拥塞避免 |
| 吞吐影响 | 剧烈下降 | 相对温和 |
⑥ 拓展延伸工程实践： 抓包见重传时间间隔指数退避（RTO 越来越大）通常对应超时而非快重传；跨国链路丢包时，超时导致的 cwnd=1 会让长连接吞吐极不稳定，需优化路由/开启 ECN/评估 BBR 等新型拥塞控制。面试追问：①「超时后为什么要从 1 开始？」——网络状态完全未知，必须最小化注入。②「ssthresh 为何是 cwnd/2？」——经验估计「拥塞前窗口的一半」仍可能可承受。
⑦ 真题变式 “超时后 ssthresh 怎么变化？”→ssthresh = 超时前 cwnd 的一半。“超时后进入什么阶段？”→慢开始（指数增长到 ssthresh 后转拥塞避免）。“快重传后 cwnd 降为 1 吗？”→不降为 1，只减半进入快恢复。
⑧ 记忆锚点 “超时归一慢开始，重复减半快恢复”。超时 = 重启指数增长，快重传 = 减半线性增长。
⑨ 知识关联：主库题群：第68题（快重传）、第69题（本题超时 cwnd→1）、第70-71题（拥塞控制辨析与快恢复去向）构成拥塞控制簇；与第62-63（超时与连接状态）呼应。与补题：无直接补题；可对照补-03/04 的窗口恢复思想。与面试20题：面试第6题（四算法中超时路径：慢开始）。面试追问：①「超时 vs 3 个重复 ACK 的窗口策略？」——前者 cwnd=1 进慢开始，后者减半进快恢复。②「cwnd=1 是否太狠？」——严重拥塞时保守优于激进，防止死锁式丢包。
70. 关于TCP拥塞控制，错误的是（ ）。
A. 慢开始阶段cwnd呈指数增长 B. 拥塞避免阶段cwnd呈线性增长 C. 超时时ssthresh调整为当前cwnd的一半 D. ssthresh的值永远不会变化
答案：D解析：① 考点定位 TCP 拥塞控制四个算法的细节——找出描述错误的选项。
② 知识精讲 TCP 拥塞控制四个经典算法及 ssthresh 的动态变化：
| 算法 | cwnd 变化 | 触发 |
|---|---|---|
| 慢开始 | 每 RTT 翻倍（指数增长） | cwnd < ssthresh |
| 拥塞避免 | 每 RTT 加 1 MSS（线性增长） | cwnd ≥ ssthresh |
| 快重传 | 立即重传丢失段 | 3 个重复 ACK |
| 快恢复 | cwnd=ssthresh=cwnd/2，线性增长 | 快重传后 |
ssthresh（慢开始阈值）是动态变化的：
- 初始值通常设为较高值（如 65535 或更大）。
- 每次发生拥塞（超时或快重传），ssthresh 更新为当前 cwnd 的一半。
- 它不是固定的——随着网络状况变化而不断调整。
ssthresh 的角色与常见误解： ssthresh（slow start threshold）不是静态配置，而是运行时根据拥塞信号不断下调的天花板。初始可以很大（等于接收窗口或实现定义值），一旦发生超时或快重传，就更新为当时 cwnd 的一半（实现会保证至少 2 MSS）。cwnd 从 1 指数增长碰到 ssthresh 后改为线性加 1，这就是慢开始与拥塞避免的切换点。常见错误说法包括：ssthresh 固定不变；慢开始阶段 cwnd 线性增长；快恢复结束后回到慢开始。正确记忆：指数到阈值，之后线性加；超时阈值减半且回到 1，快重传阈值减半但不回 1。
③ 本题解析 选项 D 说“ssthresh 的值永远不会变化”——这与算法矛盾，ssthresh 每次拥塞时都按 cwnd 的一半更新。D 是错误项，本题选 D。
④ 选项逐项辨析
- A 慢开始阶段 cwnd 呈指数增长：每 RTT 翻倍 = 指数增长，正确。
- B 拥塞避免阶段 cwnd 呈线性增长：每 RTT 加 1 = 线性增长，正确。
- C 超时时 ssthresh 调整为当前 cwnd 的一半：标准算法行为，正确。
- D ssthresh 的值永远不会变化：错误——每次拥塞 ssthresh 都会更新，是动态值。
常见误解来源： 以为 ssthresh 固定不变，或把「慢开始」理解成窗口线性爬升。
⑤ 易混对比 容易混淆“ssthresh 变不变”：ssthresh 在正常传输阶段不变，但每次拥塞事件（超时/快重传）时都会更新为 cwnd/2。因此“永远不会变化”是绝对错误的。记忆：ssthresh 是“动态阈值”，拥塞就变。
⑥ 拓展延伸 cwnd 的完整生命周期示例：初始 cwnd=1 → 慢开始指数增长到 ssthresh=8 → 拥塞避免线性增长到 cwnd=12 → 超时！ssthresh=12/2=6, cwnd=1 → 慢开始指数增长到 6 → 拥塞避免线性增长... 形成“锯齿”波形。这个锯齿是 TCP 拥塞控制的典型特征。
⑦ 真题变式 “慢开始阶段 cwnd 的增长方式？”→指数增长（每 RTT 翻倍）。“拥塞避免阶段 cwnd 的增长方式？”→线性增长（每 RTT 加 1 MSS）。“ssthresh 在什么情况下会变化？”→每次发生拥塞（超时或快重传）时更新为 cwnd 的一半。
⑧ 记忆锚点 “慢指数、避线性、超时归一、ssthresh 动态减半”。四算法 + 动态阈值，ssthresh 不是常量。
⑨ 知识关联： 主库题群：与第66-69、71题构成拥塞控制题群。与补题：无直接补题。与面试20题：面试第6题（拥塞四算法）完整覆盖。面试追问：①「慢开始为什么叫『慢』？」——起点低（1 MSS），不是增长慢；实际是指数增长。②「Linux 默认拥塞算法是什么？」——CUBIC（用三次函数做窗口增长）；手机/WebRTC 常用 BBR。
71. TCP快恢复阶段结束后，进入（ ）。
A. 慢开始 B. 拥塞避免 C. 快重传 D. 继续快恢复
答案：B解析：① 考点定位 TCP 快恢复阶段结束后的状态转换。
② 知识精讲 TCP 拥塞控制完整状态机两条路径：
- 路径一（超时）：超时 → ssthresh=旧cwnd/2、cwnd=1 → 慢开始（指数增长）→ 达到 ssthresh → 拥塞避免（线性增长）
- 路径二（快重传）：3 个重复 ACK → 快重传（立即重传丢失段）→ 快恢复（ssthresh=cwnd/2, cwnd=ssthresh）→ 拥塞避免（线性增长）
两条路径的终点都是拥塞避免。快恢复结束后不回到慢开始（因为 cwnd 没有降为 1，只减半），而是直接从 ssthresh 开始线性增长，即进入拥塞避免。
两条路径的直觉解释： 超时路径把网络视为可能已经堵死，所以窗口回到 1，用最小代价重新探测；快重传路径把网络视为还能收到后续 ACK，只是丢了个别段，所以只减半，避免吞吐跌得太狠。快恢复结束后进入的是拥塞避免而不是慢开始，因为 cwnd 仍停在新的 ssthresh 附近，若再回 1 会白白浪费已探测到的容量。实现细节上，Reno 在快恢复中收到重复 ACK 会让 cwnd 线性回升、收到新 ACK 则退出快恢复；NewReno 进一步处理一次窗口内多个丢失段，减少退回超时的概率。面试可补一句：CUBIC 等现代算法改了窗口增长曲线，但超时重置、快速减半的思想仍在。
设计动机： 快恢复结束后进入拥塞避免而非慢开始，关键在于「网络证据等级不同」。快恢复由 3 个重复 ACK 进入，说明接收方仍在持续收包，网络只是局部丢包，没有崩溃；若再降到 cwnd=1 做慢开始，会不必要地浪费已探明的容量。因此在快恢复中把 cwnd 设到 ssthresh（≈原 cwnd/2）后，采用线性增长（每 RTT +1 MSS）——这就是拥塞避免。两条路径殊途同归：最终都要在拥塞避免阶段小心翼翼加窗，直到再次超时或出现重复 ACK。记忆：超时→慢开始→拥塞避免；快重传→快恢复→拥塞避免。
③ 本题解析 快恢复阶段结束后进入拥塞避免，对应选项 B。
④ 选项逐项辨析
- A 慢开始：慢开始只在超时后进入（cwnd 降为 1），快恢复后 cwnd=ssthresh 不为 1，不回慢开始，错误。
- B 拥塞避免：快恢复后 cwnd 从 ssthresh 开始线性增长，即拥塞避免，正确。
- C 快重传：快重传是触发动作（重传丢失段），不是后续阶段，错误。
- D 继续快恢复：快恢复本身是短暂过渡阶段，不会“继续”在此阶段，错误。
常见误解来源： 快恢复结束后答回慢开始；应回到拥塞避免（从减半后的 ssthresh 线性涨）。
⑤ 易混对比
| 路径 | 进入条件 | cwnd 起点 | 中间算法 | 终点阶段 |
|---|---|---|---|---|
| 超时路径 | RTO | 1 | 慢开始（指数） | 拥塞避免（线性） |
| 快重传路径 | 3 重复 ACK | ssthresh≈cwnd/2 | 快恢复 | 拥塞避免（线性） |
| 正常探测 | 无丢包 | 继续当前 cwnd | 拥塞避免 | 直至出现信号 |
⑥ 拓展延伸工程实践： 用 ss -ti 观察 cwnd 锯齿：慢开始陡升→拥塞避免缓升→信号后下降。BBR 等算法不再严格遵循该状态机，但面试仍以经典 Reno/NewReno 四算法为准。面试追问：①「快恢复和慢开始有何本质不同？」——快恢复不把 cwnd 打到 1，保留已知可用容量。②「拥塞避免阶段增长多快？」——每 RTT 增加约 1 个 MSS（线性），避免再次撞墙。
⑦ 真题变式 “超时后进入什么阶段？”→慢开始。“慢开始达到 ssthresh 后进入什么？”→拥塞避免。“快重传后进入什么阶段？”→快恢复。“快恢复后进入什么？”→拥塞避免。
⑧ 记忆锚点 “两条路径终归拥塞避免”——超时走慢开始→拥塞避免，快重传走快恢复→拥塞避免。口诀“超时走慢路，快传走快路，殊途同归避拥塞”。
⑨ 知识关联：主库题群：第68题（快重传）、第69题（超时→慢开始）、第70题（拥塞控制错误项）、第71题（本题：快恢复后→拥塞避免）构成闭环。与补题：无直接补题。与面试20题：面试第6题（拥塞控制四算法完整状态机）。面试追问：①「快恢复结束后进入什么阶段？」——拥塞避免。②「四算法完整顺序？」——慢开始、拥塞避免、快重传、快恢复（后两者为丢包响应）。
72. TCP和UDP的端口号关系是（ ）。
A. 是两套独立命名空间，可共存于同一主机 B. 不能共存于同一主机 C. 端口完全相同且互相干扰 D. TCP端口包含UDP端口
答案：A解析：① 考点定位 TCP 和 UDP 端口号命名空间的关系。
② 知识精讲 TCP 和 UDP 各自拥有独立的端口号命名空间，互不干扰：
- 同一台主机上，TCP 的 53 端口和 UDP 的 53 端口是两个不同的端口。
- 两者可以同时被同一应用使用——例如 DNS：查询走 UDP:53，区域传送走 TCP:53，两个 53 端口同时服务。
- 一个传输层连接由五元组唯一标识：（协议，源IP，源端口，目的IP，目的端口）。协议不同即使其他四项相同也是不同连接。
端口号范围 0-65535，三个区间：
- 0-1023：知名（Well-known）端口，系统级服务。
- 1024-49151：注册端口，供应用注册使用。
- 49152-65535：动态/私有端口，客户端临时使用。
设计动机： TCP 与 UDP 是两个独立的传输层协议，各自维护 0–65535 的端口命名空间。内核通过 socket 五元组（协议、源IP、源端口、目的IP、目的端口）区分连接；协议字段不同，即使端口数字相同也是两个端点。这就是 DNS 可以同时监听 TCP/53 与 UDP/53 互不冲突的原因。端口分类：0–1023 知名端口（需特权）、1024–49151 注册端口、49152–65535 动态/私有端口。防火墙与负载均衡规则几乎总是显式写「协议+端口」，绝不能只写端口号。
③ 本题解析 TCP 和 UDP 的端口号是两套独立的命名空间，可以共存于同一主机，对应选项 A。
④ 选项逐项辨析
- A 是两套独立命名空间，可共存于同一主机：正确——TCP:53 与 UDP:53 互不干扰。
- B 不能共存于同一主机：错误——两者独立可同时使用。
- C 端口完全相同且互相干扰：错误——虽端口号数值可能相同但属于不同协议空间，不互相干扰。
- D TCP 端口包含 UDP 端口：错误——是并列关系不是包含关系。
常见误解来源： 以为同一数值的 TCP/UDP 端口会互相占用（「53 给了 UDP，TCP 就不能再用」）；实际上两者是各自独立的命名空间，可共存于同一主机，只是常被成对记忆。
⑤ 易混对比
| 说法 | 正误 | 原因 |
|---|---|---|
| TCP 80 与 UDP 80 是同一端口 | ❌ | 协议命名空间独立，五元组含协议 |
| DNS 可同时用 UDP/53 与 TCP/53 | ✅ | 两套端点可并存 |
| 同一时刻两进程可都用 TCP:80（同 IP） | ❌ | 同协议同端口冲突 |
| 五元组相同才是同一 TCP 连接 | ✅ | 协议+四地址 |
⑥ 拓展延伸工程实践： netstat/ss 会分别列出 tcp 与 udp 监听；K8s Service、iptables 中 TCP 与 UDP 同端口必须两条规则。面试追问：①「TCP 53 和 UDP 53 冲突吗？」——不冲突。②「讨论同一连接用四元组还是五元组？」——含协议的五元组更严谨；TCP 场景有时口头说四元组。
⑦ 真题变式 “同一主机上 TCP:53 和 UDP:53 可以同时使用吗？”→可以，是两个不同的端口。“标识一个 TCP 连接需要几个要素？”→五元组：协议、源IP、源端口、目的IP、目的端口。
⑧ 记忆锚点 “TCP UDP 两套号，同号不同道“。五元组中协议字段区分了 TCP/UDP 的端口空间。
⑨ 知识关联：主库题群：第64-65题（UDP）、第72题（本题端口关系）、第73题（知名端口）、第74题（443）、第75题（SMTP/POP3）、第76-77题（FTP）构成「端口与协议」簇。与补题：补-13（UDP）、补-14（邮件协议端口）。与面试20题：面试第20题（应用层协议族与默认端口）、面试第3题（TCP/UDP）。面试追问：①「为什么防火墙规则要写协议？」——端口空间按协议隔离。②「0-1023 端口绑定要注意什么？」——Linux 需特权或 CAP_NET_BIND_SERVICE。
73. TCP端口号中，0-1023称为（ ）。
A. 注册端口 B. 动态/私有端口 C. 组播端口 D. 知名（熟知）端口
答案：D解析：① 考点定位 TCP/UDP 端口号的分类——0-1023 的名称。
② 知识精讲 IANA 将 TCP/UDP 端口号分为三个区间：
| 范围 | 名称 | 用途 | 示例 |
|---|---|---|---|
| 0-1023 | 知名（Well-known）/ 熟知端口 | 系统级服务 | HTTP 80, HTTPS 443, SSH 22, FTP 21, SMTP 25, DNS 53 |
| 1024-49151 | 注册端口 | 用户进程/公司注册使用 | MySQL 3306, Oracle 1521 |
| 49152-65535 | 动态/私有端口 | 客户端临时使用 | 浏览器临时端口 |
端口 0 保留不使用，实际可用范围 1-65535。
知名端口号速查表（笔试必背）：
- HTTP: 80 | HTTPS: 443 | DNS: 53 | FTP: 20/21 | SSH: 22 | Telnet: 23
- SMTP: 25 | POP3: 110 | IMAP: 143 | DHCP: 67/68 | SNMP: 161/162 | TFTP: 69
为什么要分三段以及 0-1023 的特权： 端口号是传输层复用/分用的关键——同一 IP 上靠端口区分进程。IANA 把 0-1023 划为知名端口，是因为这些服务（HTTP、FTP、SMTP、DNS 等）需要全局约定、人人皆知，客户端不用事先配置就能连上服务器的固定端口；历史上绑定这些端口还需要特权（Unix 下 uid 0），防止普通用户抢占。1024-49151 为注册端口，供厂商/应用向 IANA 登记（如 MySQL 3306）；49152 以上为动态端口，操作系统给客户端临时分配。注意：客户端源端口通常来自动态段，目的端口才是知名/注册端口。笔试最爱考某协议默认端口是几以及 0-1023 叫什么名字。
③ 本题解析 0-1023 称为知名（熟知）端口，对应选项 D。
④ 选项逐项辨析
- A 注册端口：注册端口的范围是 1024-49151，不是 0-1023，错误。
- B 动态/私有端口：动态端口的范围是 49152-65535，不是 0-1023，错误。
- C 组播端口：不存在”组播端口“这种端口分类，组播是 IP 层概念（D 类地址 224-239），错误。
- D 知名（熟知）端口：0-1023 的标准分类名称，正确。
常见误解来源： 把 0-1023 叫「注册端口」；注册端口是 1024-49151，0-1023 是知名/熟知端口。
⑤ 易混对比 三个区间容易记混，记忆方法——”低段知名、中段注册、高段动态“：
- 0-1023（低段）→ 知名端口（系统服务，需要 root 权限绑定）
- 1024-49151（中段）→ 注册端口（应用注册，普通用户可绑定）
- 49152-65535（高段）→ 动态端口（客户端临时分配）
⑥ 拓展延伸 为什么知名端口需要 root 权限？Unix/Linux 规定绑定 1024 以下端口需要超级用户权限，防止普通用户冒充系统服务（如伪造 HTTP 80 端口的 Web 服务器）。这一安全设计是操作系统网络栈的基础约定。
⑦ 真题变式 “1024-49151 称为什么端口？”→注册端口。“49152-65535 称为什么端口？”→动态/私有端口。“DNS 使用哪个端口？”→53（知名端口）。
⑧ 记忆锚点 “0-1023 知名、1024-49151 注册、49152-65535 动态“。口诀”低知名、中注册、高动态“。
⑨ 知识关联： 主库题群：与第72题（端口关系）、第74-76题（具体端口）构成端口题群。与补题：补-14（邮件端口 25/110/143）。与面试20题：面试第20题（应用层协议端口表）。面试追问：①「注册端口范围是多少？」——1024~49151（IANA 注册）。②「动态/私有端口范围？」——49152~65535，客户端临时使用。
74. 使用TCP端口443的协议是（ ）。
A. HTTP B. HTTPS C. FTP D. SMTP
答案：B解析：① 考点定位 知名端口号——TCP 端口 443 对应的协议。
② 知识精讲 常见知名端口速查表（笔试必背）：
| 协议 | 端口 | 传输层 |
|---|---|---|
| HTTP | 80 | TCP |
| HTTPS | 443 | TCP |
| FTP | 20（数据）/ 21（控制） | TCP |
| SSH | 22 | TCP |
| Telnet | 23 | TCP |
| SMTP | 25 | TCP |
| DNS | 53 | TCP/UDP |
| POP3 | 110 | TCP |
| IMAP | 143 | TCP |
| DHCP | 67/68 | UDP |
| SNMP | 161/162 | UDP |
| TFTP | 69 | UDP |
HTTPS = HTTP over SSL/TLS——在 HTTP 基础上增加加密（对称加密传输数据）和认证（数字证书验证服务器身份）层，端口与 HTTP（80）不同，使用 443。HTTPS 是当前 Web 通信的安全标准，主流浏览器已默认要求 HTTPS。
HTTPS 与 443 的来龙去脉： HTTPS 并不是新协议，而是 HTTP over SSL/TLS——在 TCP 三次握手之后再做 TLS 握手（证书验证、密钥协商），随后用对称加密传输 HTTP 报文。IANA 为 HTTPS 分配了 TCP 443，与 HTTP 的 80 区分，便于防火墙、代理、CDN 做策略。记忆时把安全类端口单独串起来：HTTPS 443、SSH 22（也是加密）、以及邮件加密变体 SMTPS 465/587、IMAPS 993、POP3S 995。考试若出现使用 TCP 443 的协议，几乎就是 HTTPS；若把 80、443 与 FTP 20/21、SMTP 25 混排，用网页加密=443、文件双端口=20/21、邮件发=25 三条锚点秒杀。
③ 本题解析 使用 TCP 端口 443 的是 HTTPS，对应选项 B。
④ 选项逐项辨析
- A HTTP：使用端口 80，不是 443，错误。
- B HTTPS：使用端口 443，HTTP + SSL/TLS 加密，正确。
- C FTP：使用端口 20/21，不是 443，错误。
- D SMTP：使用端口 25，不是 443，错误。
常见误解来源： 把 443 答成 HTTP 或 SSH；HTTPS=443，HTTP=80，SSH=22。
⑤ 易混对比 HTTP（80）vs HTTPS（443）是最常考的端口对比对。HTTPS 不是独立的应用层协议，而是 HTTP 在 SSL/TLS 隧道中的传输方式。HTTPS 握手时先完成 TLS 握手（协商加密套件、验证证书），再在加密通道内传输 HTTP 报文。
⑥ 拓展延伸 HTTPS 握手流程简述：①客户端发 ClientHello（支持的加密套件+随机数）；②服务器回 ServerHello+证书+公钥；③客户端验证证书→生成预主密钥→用服务器公钥加密发送；④双方基于三个随机数生成会话密钥→后续用对称加密通信。TLS 1.3 简化了这个过程（1-RTT 甚至 0-RTT）。
⑦ 真题变式 “HTTP 使用的端口号？”→80。“SSH 使用的端口号？”→22。“FTP 控制连接使用的端口号？”→21。“HTTPS 与 HTTP 的主要区别？”→HTTPS 在 HTTP 基础上增加 SSL/TLS 加密和认证，端口从 80 改为 443。
⑧ 记忆锚点 “443=HTTPS”——必须形成条件反射。口诀“HTTP 八十 HTTPS 四四三”。
⑨ 知识关联： 主库题群：与第75题（SMTP/POP3）、第76题（FTP）、第91题（HTTPS 端口）、第94题（输入 URL 最先动作）构成「应用层协议端口」题群。与补题：补-14（邮件协议）。与面试20题：面试第20题（端口表，HTTPS=443）。面试追问：①「HTTP 默认端口是多少？」——80。②「HTTPS 和 HTTP 的关系？」——HTTPS = HTTP over TLS，端口 443，请求格式基本相同只是 socket 先过 TLS。
75. SMTP和POP3的端口号分别是（ ）。
A. 21 和 25 B. 25 和 110 C. 80 和 110 D. 25 和 143
答案：B解析：① 考点定位 邮件协议 SMTP 和 POP3 的端口号。
② 知识精讲 邮件系统三大协议：
| 协议 | 全称 | 端口 | 传输层 | 功能 | 模式 |
|---|---|---|---|---|---|
| SMTP | 简单邮件传输协议 | 25 | TCP | 发送邮件 | 推（push） |
| POP3 | 邮局协议第3版 | 110 | TCP | 接收邮件 | 拉（pull） |
| IMAP | 互联网消息访问协议 | 143 | TCP | 接收邮件（功能更强） | 拉（pull） |
- SMTP 负责邮件的“推送”——发送方客户端→SMTP 服务器→接收方 SMTP 服务器之间的传输。邮件提交常用端口 587（STARTTLS 加密）。
- POP3 负责邮件的“拉取”——用户从邮件服务器下载邮件到本地客户端。POP3 通常下载后从服务器删除。
- IMAP 也负责接收，但支持服务器端文件夹管理和同步（邮件保留在服务器），功能更强大。
设计动机与协议族： 邮件系统至少需要「推送」与「拉取」两类协议：SMTP 负责把邮件从客户端推到服务器、以及服务器之间中继（默认 TCP 25）；POP3/IMAP 负责用户取信（POP3=110，IMAP=143）。加密变体：SMTPS 465/587（STARTTLS）、POP3S 995、IMAPS 993。POP3 默认「下载后可删服务器副本」，IMAP 默认「邮件留在服务器、多端同步文件夹」，这是企业邮箱选 IMAP 的原因。SMTP 是 ASCII 文本命令协议（HELO/MAIL FROM/RCPT TO/DATA），便于网关互操作。
③ 本题解析 SMTP 端口 25，POP3 端口 110，对应选项 B。
④ 选项逐项辨析
- A 21 和 25：21 是 FTP 控制端口，25 是 SMTP 端口，但题目问 SMTP 和 POP3 两个，这里把 FTP 的 21 混入了，错误。
- B 25 和 110：25=SMTP, 110=POP3，完全匹配，正确。
- C 80 和 110：80 是 HTTP 端口，不是 SMTP，错误。
- D 25 和 143：25=SMTP 正确，但 143 是 IMAP 端口不是 POP3 的 110，错误。
常见误解来源： SMTP 与 POP3 端口写反，或把 IMAP 143 与 POP3 110 混淆。
⑤ 易混对比
| 协议 | 默认端口 | 加密端口 | 方向 | 典型行为 |
|---|---|---|---|---|
| SMTP | 25 | 465/587 | 推（发送/中继） | MAIL FROM → RCPT TO → DATA |
| POP3 | 110 | 995 | 拉（接收） | 认证后下载，可删服务器件 |
| IMAP | 143 | 993 | 拉（接收） | 服务器端文件夹，多端同步 |
| 口诀：发25、收110/143；加密尾数变99x/465。 |
⑥ 拓展延伸工程实践： 邮件投递链：MUA --SMTP--> 本域 MTA --SMTP--> 对端 MTA --POP3/IMAP--> 收件 MUA。反垃圾常见 SPF/DKIM/DMARC 验证发件域。排障时 telnet 邮件服务器 25 端口可看 SMTP 横幅。面试追问：①「SMTP 和 HTTP 都能传文件，为何邮件还要 POP3/IMAP？」——SMTP 解决投递，POP3/IMAP 解决邮箱访问与同步，职责不同。②「为什么现代邮箱几乎不用裸 25/110？」——中间人窃听风险，改用 STARTTLS 或隐式 TLS。
⑦ 真题变式 “IMAP 使用的端口号？“→143。”用于发送邮件的协议？“→SMTP（端口 25）。”用于接收邮件的协议有哪些？“→POP3（110）和 IMAP（143）。
⑧ 记忆锚点 口诀”发 25 收 110，IMAP 换 143”。SMTP 推、POP3/IMAP 拉——发推收拉。
⑨ 知识关联：主库题群：第74题（HTTPS 443）、第75题（本题 SMTP/POP3 端口）、第76-77题（FTP 双端口/主动模式）构成「应用层端口」簇；与第84题（HTTP）同属应用层。与补题：补-14（SMTP/POP3/IMAP 功能与端口）。与面试20题：面试第20题（端口表）。面试追问：①「IMAP 端口？」——143，加密 993。②「SMTP、POP3、IMAP 分工？」——SMTP 发送/中继；POP3/IMAP 接收；IMAP 更适合多端同步。
76. FTP使用的端口号是（ ）。
A. 20 和 21 B. 25 和 110 C. 80 和 443 D. 53 和 67
答案：A解析：① 考点定位 FTP 协议的端口号——双端口设计。
② 知识精讲 FTP 是少数使用两个端口的应用层协议：
| 端口 | 连接类型 | 用途 | 生命周期 |
|---|---|---|---|
| 21 | 控制连接 | 传输命令与响应（USER, PASS, LIST, RETR 等） | 整个会话期间保持 |
| 20 | 数据连接 | 传输文件数据 | 每次传输临时建立 |
FTP 有两种工作模式：
- 主动模式（PORT）：客户端通过 21 端口告知服务器自己的数据端口，服务器从 20 端口主动连接客户端。
- 被动模式（PASV）：客户端发送 PASV 命令，服务器告知自己的临时数据端口，客户端主动连接该端口（通常≥1024）。
无论哪种模式，控制连接始终由客户端发起、连接到服务器 21 端口。现代网络中因 NAT/防火墙问题，被动模式更常用。
设计动机： FTP 是少数使用双端口的应用层协议，体现「带外控制」思想：控制连接 TCP 21 全程在线，传 USER/PASS/LIST/RETR/STOR 等命令与响应；数据连接按需建立传文件内容（主动模式下常用服务器 20 端口）。控制与数据分离的好处是：传输大文件时仍可发 ABOR 中断、看目录；代价是防火墙/NAT 穿越复杂。现代替代：HTTP(S) 下载、SFTP/SCP（SSH 上单连接）。知名端口记忆：FTP 控制 21、数据 20；HTTP 80；HTTPS 443；SSH 22。
③ 本题解析 FTP 使用端口 20 和 21，对应选项 A。
④ 选项逐项辨析
- A 20 和 21：20=数据连接，21=控制连接，FTP 标准端口对，正确。
- B 25 和 110：这是 SMTP 和 POP3 的邮件协议端口，错误。
- C 80 和 443：这是 HTTP 和 HTTPS 的端口，错误。
- D 53 和 67：这是 DNS 和 DHCP 的端口，错误。
常见误解来源： 只记 21 或只记 20；FTP 控制 21、数据 20（主动模式）。
⑤ 易混对比
| 端口 | 连接 | 用途 | 生命周期 |
|---|---|---|---|
| 21 | 控制连接 | 命令与响应 | 整个 FTP 会话 |
| 20 | 数据连接（主动模式） | 文件/列表数据 | 单次传输 |
| 随机高端口 | 数据连接（被动模式） | 文件/列表数据 | 单次传输，客户端发起 |
| 对比 HTTP | 单连接带内 | 头与体同道 | 每请求或 keep-alive |
⑥ 拓展延伸工程实践： 云主机安全组需放行被动模式端口范围（如 50000-51000），仅开 21 往往连不上列表。企业 FTP 常改用 FTPS 或 SFTP 满足合规。面试追问：①「FTP 为何要两个连接？」——控制与数据分离，传输中仍可控制。②「主动模式谁发起数据连接？」——服务器（20 → 客户端 PORT 指定端口）。
⑦ 真题变式 “FTP 控制连接使用哪个端口？”→21。“FTP 数据连接使用哪个端口？”→20（主动模式）或服务器临时分配（被动模式）。“FTP 主动模式和被动模式的区别？”→主动模式服务器从 20 端口主动连客户端；被动模式客户端主动连服务器临时端口。
⑧ 记忆锚点 “FTP 二一控制、二零数据“——21 管命令（整个会话），20 管数据（每次传输）。口诀”二一传命令，二零传文件“。
⑨ 知识关联：主库题群：第75题（邮件端口）、第76题（本题 FTP 端口）、第77题（主动模式发起方）构成 FTP/端口簇；对照第84题（HTTP 带内控制）。与补题：补-14（应用层邮件/文件协议辨析）。与面试20题：面试第20题（FTP 双连接与端口）。面试追问：①「只开 21 端口 FTP 能用吗？」——主动/被动数据连接可能失败。②「带外控制的优缺点？」——灵活但穿越 NAT 难。
77. FTP主动模式下，发起数据连接的是（ ）。
A. 服务器从20端口连接客户端 B. 客户端从任意端口连接服务器21 C. 客户端连接服务器21 D. 双方都用21
答案：A解析：① 考点定位 FTP 主动模式下数据连接的发起方和端口。
② 知识精讲 FTP 主动模式（PORT 模式）的完整连接流程：
- 控制连接：客户端从任意临时端口（如 N）连接到服务器 21 端口，发送 PORT 命令告知自己的数据监听端口（如 M）。
- 数据连接：服务器从自己的 20 端口主动连接到客户端告知的端口 M。
关键点：主动模式下数据连接由服务器发起——服务器 20 端口→客户端端口 M。这与被动模式（PASV）相反——被动模式下数据连接由客户端发起——客户端连接到服务器告知的临时端口。
| 模式 | 控制连接 | 数据连接发起方 | 数据连接方向 |
|---|---|---|---|
| 主动（PORT） | 客户端→服务器：21 | 服务器（从 20 端口） | 服务器：20 → 客户端：M |
| 被动（PASV） | 客户端→服务器：21 | 客户端 | 客户端 → 服务器：临时端口 |
设计动机与模式对比： 主动模式（PORT）由服务器从 20 端口主动连接客户端用 PORT 命令通告的端口，因此「发起数据连接的是服务器」。被动模式（PASV）中客户端连接服务器临时通告的高端口，更利于 NAT/防火墙——所有连接都从内网发起。名称易误导：叫「主动」是因为服务器对数据连接主动；但企业网中客户端往往在 NAT 后，外部主动连入常被丢弃，故现代客户端默认 PASV/EPSV。理解抓包特征：主动模式可见 S:20 → C:高位；被动可见 C:高位 → S:高位。
③ 本题解析 FTP 主动模式下，发起数据连接的是服务器从 20 端口连接客户端，对应选项 A。
④ 选项逐项辨析
- A 服务器从 20 端口连接客户端：主动模式标准流程——服务器 20→客户端数据端口，正确。
- B 客户端从任意端口连接服务器 21：这是控制连接的建立方式，不是数据连接的发起方，错误。
- C 客户端连接服务器 21：同样是控制连接，不是数据连接，错误。
- D 双方都用 21：数据连接不走 21 端口（21 是控制连接专用），错误。
常见误解来源： 以为主动模式下客户端主动连服务器数据端口；主动模式是服务器连客户端。
⑤ 易混对比
| 模式 | 数据连接发起方 | 服务器端口 | 客户端 NAT | 现代可用性 |
|---|---|---|---|---|
| 主动 PORT | 服务器 | 20 → 客户端指定口 | 常失败 | 差 |
| 被动 PASV | 客户端 | 通告临时高端口 | 友好 | 好（默认） |
| 带外控制 | 两种皆是 | 控制恒 21 | — | 与 HTTP 带内对比 |
⑥ 拓展延伸工程实践： 负载均衡后的 FTP 需支持 PASV 端口池并在响应中返回正确外部地址（PASV 公网 IP 问题）。面试追问：①「主动模式在什么环境失败多？」——客户端 NAT/主机防火墙。②「如何一句话区分主动/被动？」——看数据连接 SYN 的源端：服务器 SYN 源=20 则主动；客户端 SYN 目的=高位则被动。
⑦ 真题变式 “FTP 被动模式下，数据连接由谁发起？”→客户端主动连接服务器临时端口。“FTP 控制连接由谁发起？”→客户端（连接到服务器 21 端口，无论主动还是被动模式都如此）。“FTP 主动模式中服务器用哪个端口发起数据连接？”→20 端口。
⑧ 记忆锚点 “主动=服务器 20 主动连客户端；被动=客户端主动连服务器临时口”。口诀“主动模式服务器出，被动模式客户端出”。
⑨ 知识关联：主库题群：第76题（FTP 端口）、第77题（本题：主动模式由服务器发起数据连接）构成 FTP 双连问。与补题：无直接补题（可对照补-14 的「应用层协议辨析」思路）。与面试20题：面试第20题（FTP 主动/被动）。面试追问：①「主动模式发起方是谁？」——服务器。②「为何被动更通用？」——客户端发起，适配 NAT 与默认防火墙策略。
78. 当TCP接收方收到乱序报文段时，通常会（ ）。
A. 丢弃全部数据 B. 发送重复ACK（对最后一个按序字节） C. 发送RST D. 直接进入拥塞避免
答案：B解析：① 考点定位 TCP 接收方收到乱序报文段时的行为——重复 ACK 机制。
② 知识精讲 TCP 接收方的确认机制：
- 正常情况：接收方按序收到报文段，发送 ACK 确认“期望收到的下一个序号”（累积确认）。
- 乱序情况：如收到序号 1、2、4（3 丢失），接收方缓存乱序的 4 号段，但仍对最后一个按序收到的字节发送 ACK——即 ack=3（期望收到 3 号段）。后续收到 5、6 也一样，ack 仍然是 3。于是发送方收到重复的 ACK=3。
- 触发快重传：当发送方连续收到 3 个重复 ACK（即 4 个相同的 ack），判断 3 号段可能丢了，立即快重传 3 号段，不等超时。
这个机制是 TCP 可靠传输的精妙设计——不丢数据（乱序的段被缓存），不浪费（重复 ACK 同时兼作“丢包信号”），快速恢复（3 个重复即可触发重传）。
设计动机： TCP 接收方对乱序段通常「缓存 + 重复 ACK」，而不是丢弃。累积确认只承诺「按序到达的前缀」，因此收到缺口后的段时，ACK 号仍指向下个期望序号，形成重复 ACK。这样做的好处：一是不浪费已经到达的有效载荷（更接近 SR 而非 GBN）；二是重复 ACK 给发送方提供隐式丢包信号，连续 3 个可触发快重传，缩短恢复时间。若接收方直接丢弃乱序段，发送方只能靠超时，性能显著变差。SACK 选项进一步告诉发送方「已收到哪些区间」，实现选择性重传。
③ 本题解析 收到乱序报文段时，接收方缓存数据并发送重复 ACK（对最后一个按序字节），对应选项 B。
④ 选项逐项辨析
- A 丢弃全部数据：TCP 不会丢弃乱序数据——它会缓存等待重组，错误。
- B 发送重复 ACK（对最后一个按序字节）：标准行为——缓存乱序段 + 重复确认最后按序字节，正确。
- C 发送 RST：RST 用于严重异常时复位连接，乱序不是异常，错误。
- D 直接进入拥塞避免：拥塞避免是发送方收到重复 ACK 后的后续阶段（先快重传再快恢复），不是接收方的直接动作，错误。
常见误解来源： 以为 TCP 丢弃所有乱序段（那是 GBN 思想）；TCP 通常缓存乱序段。
⑤ 易混对比
| 机制 | 对乱序段 | ACK 行为 | 发送方反应 | 类比链路层 |
|---|---|---|---|---|
| TCP 默认 | 缓存 | 重复 ACK（累积确认缺口） | 3 次后快重传 | 介于 SR/GBN 之间 |
| GBN | 常丢弃 | 否认/重复 | 重传窗口后继 | 补-03 |
| SR | 缓存并逐帧确认 | 选择确认 | 只重传缺失帧 | 补-04 |
| TCP+SACK | 缓存 | ACK+SACK 块 | 精准重传缺失段 | 增强 SR 思想 |
⑥ 拓展延伸工程实践： Wireshark 显示 Previous segment not captured / TCP Dup ACK / Fast Retransmission 是乱序-缺口-快重传三连。数据中心内 ECMP 多路径易造成短暂乱序，需区分「真丢包」与「乱序」，避免过度降窗。面试追问：①「TCP 乱序会丢弃吗？」——通常不丢，缓存并发重复 ACK。②「SACK 解决什么问题？」——告知已收区间，避免重传已正确到达的数据。
⑦ 真题变式 “TCP 发送方收到 3 个重复 ACK 后做什么？“→快重传（立即重传丢失段，不等超时）。”TCP 接收方对乱序段会丢弃吗？“→不会，会缓存等待后续段到达后重组。”TCP 的确认方式是什么？“→累积确认（ACK 表示”此序号之前的所有数据已收到“）。
⑧ 记忆锚点 ”乱序不丢只缓存，重复 ACK 暗示丢“。重复 ACK 是接收方说”我还在等 3 号段“，3 次重复即触发快重传。口诀”乱序缓存不丢弃，重复确认三触发“。
⑨ 知识关联：主库题群：第66-67（窗口）、第68题（快重传）、第78题（本题乱序处理）构成可靠传输簇；与第122-123（字节流/粘包）对照「报文边界」问题。与补题：补-03（GBN）、补-04（SR），对比链路层如何处理乱序。与面试20题：面试第4题（TCP 可靠传输）、面试第6题（拥塞）。面试追问：①「收到乱序段发送方如何得知？」——接收方重复 ACK。②「TCP 更像 GBN 还是 SR？」——默认更像「缓存乱序+累积确认」，开 SACK 后接近 SR。