深入 RFC 793：TCP 报文头部、MSS 协商与三次握手 / 四次挥手全解析

在计算机网络领域，RFC 文档是公认的 “权威法规”，尤其是定义 TCP 协议的 RFC 793，更是理解 TCP 核心机制的根本依据。很多开发者困惑的 “TCP 为什么三次握手”“为什么四次挥手”“MSS 协商在什么时候进行”，以及 “被动关闭方没收到 ACK 会怎样”，在 RFC 793 及 TCP 报文头部设计中都有明确答案。本文将从 TCP 报文头部格式入手，结合 RFC 793 原文，拆解 MSS 协商逻辑、TCP 连接建立（三次握手）、连接关闭（四次挥手）及 FIN 重传机制，帮你从根源理解 TCP 的可靠设计。

一、前置知识：TCP 报文头部格式与核心字段（RFC 793 定义）

TCP 协议的所有交互（握手、挥手、数据传输）都依赖 “TCP 报文段（Segment）” 实现，而报文头部包含了控制连接状态、保障传输可靠的关键字段。以下是 RFC 793 定义的 TCP 报文头部核心格式（简化版，重点标注与后续机制相关的字段）：

TCP 报文头部核心格式（字节数标注）

字段名称	字节数	核心作用（RFC 793 原文解读）	与后续机制的关联
源端口号/目的端口号	2 / 2	标识通信双方的应用进程（如 HTTP 用 80 端口，HTTPS 用 443 端口）	贯穿整个连接生命周期，是 TCP 连接 “四元组”（源 IP、源端口、目的 IP、目的端口）的核心组成
序列号（Sequence Number）	4	标识本报文段发送的数据在整个字节流中的位置（SYN、FIN 段会占用 1 个序列号）（Page 33）	三次握手时同步初始序列号（ISS），四次挥手时标识 FIN 段位置，是可靠传输的基础
确认号（Acknowledgment Number）	4	若 ACK 控制位为 1，标识本地期望接收的下一个序列号（即 “已收到的最大序列号 + 1”）（Page 33）	三次握手时确认对方 SYN，四次挥手时确认对方 FIN，是 “双向确认” 的关键
数据偏移	4 位	标识 TCP 头部的长度（单位：4 字节），最大为 60 字节（头部选项字段最多 40 字节）（Page 34）	用于定位数据部分的起始位置，头部选项字段是 MSS 协商的载体
保留位	6 位	预留未使用，需设为 0（Page 34）	-
控制位（Flags）	6 位	共 6 个控制位，分别是 URG（紧急指针有效）、ACK（确认号有效）、PSH（推送数据到应用）、RST（重置连接）、SYN（同步序列号）、FIN（结束连接）（Page 34）	三次握手依赖 SYN+ACK，四次挥手依赖 FIN+ACK，是连接状态转换的 “指令信号”
窗口大小（Window Size）	2	标识本地 TCP 接收缓冲区的剩余空间，用于流量控制（Page 34）	贯穿数据传输阶段，决定对方最多能发送多少字节的数据
校验和（Checksum）	2	校验 TCP 头部 + 数据部分的完整性，保障传输不丢错（Page 35）	所有 TCP 报文段都需携带，是数据可靠的基础保障
紧急指针（Urgent Pointer）	2	若 URG 为 1，标识紧急数据在本报文段中的结束位置（Page 35）	仅用于紧急数据传输（如中断信号），日常场景较少使用
头部选项（Options）	可变（0-40 字节）	可选字段，常见选项包括 MSS（最大分段大小）、窗口缩放、SACK（选择性确认）等（Page 35）	MSS 协商的核心载体，仅在三次握手的 SYN/SYN+ACK 段中携带

关键选项：MSS（最大分段大小）的定义与作用（RFC 793）

• MSS 定义（RFC 793 Page 39）：MSS（Maximum Segment Size）是 TCP 报文段中 “数据部分的最大长度”，等于 “IP 数据报最大长度（MTU）- IP 头部长度 - TCP 头部长度”（默认 TCP 头部 20 字节，IP 头部 20 字节，因此默认 MSS=1500-20-20=1460 字节）。
• 核心作用：避免 TCP 报文段因超过 MTU（链路层最大传输单元，以太网默认 1500 字节）而被 IP 层分片——IP 分片会增加重组开销，且任一分片丢失需重传整个数据报，MSS 协商可从源头减少此类问题。
• 协商规则：MSS 仅在 三次握手阶段 协商，且是 “双向协商”——双方在各自的 SYN/SYN+ACK 段中通过 “头部选项” 告知对方自己支持的最大 MSS，最终双方以 “较小的 MSS 值” 作为后续数据传输的分段标准（例：客户端 MSS=1460，服务器因接入网络 MTU=1400，协商后 MSS=1400-20-20=1360 字节）。

二、TCP 三次握手：结合报文头部与 MSS 协商的连接建立逻辑

三次握手的本质是 “同步双方序列号 + 协商 MSS + 确认发送/接收能力”，最终让连接进入 ESTABLISHED 状态。以下结合 TCP 报文头部字段，拆解 RFC 793 原文逻辑：

1. 第一次握手：客户端（主动打开）发送 SYN 段，携带 MSS 选项

• 触发场景：客户端从 CLOSED 状态发起连接（如浏览器访问服务器），生成随机初始序列号（ISS，Initial Sequence Number）。
• TCP 报文头部关键字段：
  • 控制位：SYN=1，ACK=0（仅同步序列号，无需确认）；
  • 序列号：Sequence Number = 客户端 ISS（例：0x1234，实际为随机值，避免序列号冲突）；
  • 头部选项：Kind=2（MSS 选项标识），Length=4，MSS Value=客户端支持的最大分段大小（例：1460 字节）；
  • 其他：源端口为客户端随机端口（如 54321），目的端口为服务器服务端口（如 80）。
• 核心动作：客户端发送该 SYN 段，进入 SYN-SENT 状态，等待服务器响应。
• RFC 793 原文隐含（Page 65）：RFC 793 虽未单独提及 MSS 选项，但明确 “SYN 段用于同步序列号”，而工业实践中 MSS 协商必须随第一次 SYN 发起——若后续协商会导致连接建立后无法立即传输数据，违背 TCP 高效设计原则。

2. 第二次握手：服务器（被动打开）回复 SYN+ACK 段，确认 MSS

• 触发场景：服务器处于 LISTEN 状态（如 Nginx 监听 80 端口），收到客户端的 SYN 段。
• TCP 报文头部关键字段：
  • 控制位：SYN=1，ACK=1（同步自己的序列号 + 确认客户端 SYN）；
  • 序列号：Sequence Number = 服务器 ISS（例：0x5678，独立于客户端序列号）；
  • 确认号：Acknowledgment Number = 客户端 ISS + 1（确认已收到客户端 SYN，期望下一个序列号是 ISS+1，因 SYN 段占用 1 个序列号）；
  • 头部选项：Kind=2，Length=4，MSS Value=服务器支持的最大分段大小（例：若服务器所在网络 MTU=1400，则 MSS=1360 字节）；
  • 其他：源端口为服务器服务端口（80），目的端口为客户端端口（54321）。
• RFC 793 原文逻辑（Page 65-66）：

  状态：LISTEN STATE
  third check for a SYN
  If the SYN bit is set, check the security. If the security/compartment on the incoming segment does not exactly match the security/compartment in the TCB then send a reset and return.
  If the SEG.PRC is greater than the TCB.PRC then if allowed by the user and the system set TCB.PRC<-SEG.PRC, if not allowed send a reset and return.
  If the SEG.PRC is less than the TCB.PRC then continue.
  Set RCV.NXT to SEG.SEQ+1, IRS is set to SEG.SEQ and any other control or text should be queued for processing later. ISS should be selected and a SYN segment sent of the form:
  <SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
  SND.NXT is set to ISS+1 and SND.UNA to ISS. The connection state should be changed to SYN-RECEIVED.

• 通俗解读：
  1. 服务器先校验 SYN 段的安全性（如权限、优先级），校验通过后记录客户端 ISS（IRS=客户端 SEQ），生成自己的 ISS；
  2. 服务器通过 ACK=客户端 ISS+1 明确 “你的 SYN 我已收到”，通过 SYN=1 告知客户端 “我的序列号从 ISS 开始”；
  3. 服务器在头部选项中携带自己的 MSS，与客户端完成双向协商——此时双方已明确 “后续数据传输的最大分段大小”（取两者 MSS 最小值）；
  4. 服务器状态从 LISTEN 转为 SYN-RECEIVED，等待客户端的最终确认。

3. 第三次握手：客户端回复 ACK 段，MSS 协商完成

• 触发场景：客户端处于 SYN-SENT 状态，收到服务器的 SYN+ACK 段。
• TCP 报文头部关键字段：
  • 控制位：SYN=0，ACK=1（仅确认服务器 SYN，无需再同步序列号）；
  • 序列号：Sequence Number = 客户端 ISS + 1（客户端 SYN 已占用 1 个序列号，下一个序列号从 ISS+1 开始）；
  • 确认号：Acknowledgment Number = 服务器 ISS + 1（确认已收到服务器 SYN，期望下一个序列号是 ISS+1）；
  • 头部选项：无需携带 MSS（MSS 协商已在 SYN/SYN+ACK 段完成，后续数据传输直接使用协商结果）；
• RFC 793 原文逻辑（Page 67-68）：

  状态：SYN-SENT STATE
  fourth check the SYN bit
  This step should be reached only if the ACK is ok, or there is no ACK, and it the segment did not contain a RST.
  If the SYN bit is on and the security/compartment and precedence are acceptable then, RCV.NXT is set to SEG.SEQ+1, IRS is set to SEG.SEQ. SND.UNA should be advanced to equal SEG.ACK (if there is an ACK), and any segments on the retransmission queue which are thereby acknowledged should be removed.
  If SND.UNA > ISS (our SYN has been ACKed), change the connection state to ESTABLISHED, form an ACK segment
  <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
  and send it. Data or controls which were queued for transmission may be included.

• 通俗解读：
  1. 客户端校验 SYN+ACK 段后，通过 ACK=服务器 ISS+1 确认 “你的 SYN+ACK 我已收到”，此时双方序列号同步完成（客户端知道服务器的序列号起始，服务器也知道客户端的）；
  2. 客户端根据服务器 SYN+ACK 中的 MSS 值，确定最终数据传输的 MSS（例：客户端 MSS=1460，服务器 MSS=1360，最终以 1360 字节为分段标准）；
  3. 客户端状态从 SYN-SENT 转为 ESTABLISHED，服务器收到该 ACK 后也从 SYN-RECEIVED 转为 ESTABLISHED——连接正式建立，可基于协商后的 MSS 传输应用数据（如 HTTP 请求）。

三、TCP 四次挥手：结合报文头部的连接关闭逻辑

TCP 是 双向通信协议（双方可同时发送数据），连接关闭需双方各自关闭 “发送通道”，因此需要四次交互（四次挥手），核心依赖 FIN+ACK 控制位和序列号/确认号的配合。以下结合 TCP 报文头部拆解 RFC 793 原文逻辑：

1. 第一次挥手：主动关闭方发送 FIN 段，关闭发送通道

• 触发场景：主动关闭方（如客户端完成数据接收后）在 ESTABLISHED 状态下调用 close() 接口，无更多数据发送。
• TCP 报文头部关键字段：
  • 控制位：FIN=1，ACK=1（结束自己的发送通道 + 确认之前收到的服务器数据，即使无未确认数据，ACK 也需设为 1，确保协议兼容性）；
  • 序列号：Sequence Number = 主动关闭方当前 SND.NXT（即已发送数据的最后一个序列号 + 1，FIN 段占用 1 个序列号）；
  • 确认号：Acknowledgment Number = 主动关闭方当前 RCV.NXT（期望接收的下一个序列号，与之前保持一致，因后续不再接收数据，仅作确认用）；
• RFC 793 原文逻辑（Page 60）：

  状态：ESTABLISHED STATE（CLOSE Call 处理）
  Queue this until all preceding SENDs have been segmentized, then form a FIN segment and send it. In any case, enter FIN-WAIT-1 state.

• 通俗解读：
  主动关闭方先确保所有未发送的应用数据都已分段（按协商后的 MSS）并发送，然后发送 FIN 段——本质是告诉对方 “我这边没有数据要发了，关闭我的发送通道”，随后进入 FIN-WAIT-1 状态，等待对方的 ACK 确认。

2. 第二次挥手：被动关闭方回复 ACK 段，确认收到 FIN

• 触发场景：被动关闭方（如服务器）在 ESTABLISHED 状态下收到主动关闭方的 FIN 段。
• TCP 报文头部关键字段：
  • 控制位：FIN=0，ACK=1（仅确认 FIN，暂不关闭自己的发送通道——可能还有未发送的响应数据）；
  • 序列号：Sequence Number = 被动关闭方当前 SND.NXT（无新数据发送，序列号与之前一致）；
  • 确认号：Acknowledgment Number = 主动关闭方 FIN 序列号 + 1（确认收到 FIN 段，期望下一个序列号是 FIN 序列号+1，因 FIN 占用 1 个序列号）；
• RFC 793 原文逻辑（Page 75）：

  状态：ESTABLISHED STATE（SEGMENT ARRIVES 处理）
  eighth, check the FIN bit
  If the FIN bit is set, signal the user “connection closing” and return any pending RECEIVEs with same message, advance RCV.NXT over the FIN, and send an acknowledgment for the FIN. Note that FIN implies PUSH for any segment text not yet delivered to the user.
  Enter the CLOSE-WAIT state.

• 通俗解读：
  1. 被动关闭方收到 FIN 后，立即通知上层应用（如 Nginx）“连接即将关闭”，并将未交付给应用的剩余数据（如 HTTP 响应尾）通过 PUSH 机制推送给应用（FIN 隐含 PUSH 语义）；
  2. 被动关闭方通过 ACK=主动关闭方 FIN 序列号+1 明确 “你的 FIN 我已收到”，随后进入 CLOSE-WAIT 状态——此时被动关闭方的 “接收通道” 已关闭（不再接收主动关闭方的数据），但 “发送通道” 仍开放，可继续发送自己的剩余数据（按协商后的 MSS 分段）。

3. 第三次挥手：被动关闭方发送 FIN 段，关闭自己的发送通道

• 触发场景：被动关闭方在 CLOSE-WAIT 状态下，上层应用处理完所有数据并调用 close() 接口，无更多数据发送。
• TCP 报文头部关键字段：
  • 控制位：FIN=1，ACK=1（结束自己的发送通道 + 确认之前收到的主动关闭方数据，确保双向通信均终止）；
  • 序列号：Sequence Number = 被动关闭方当前 SND.NXT（若被动关闭方在 CLOSE-WAIT 状态发送了剩余数据，此序列号为最后一个数据序列号 + 1；若无剩余数据，则为之前的 SND.NXT，FIN 段本身占用 1 个序列号）；
  • 确认号：Acknowledgment Number = 被动关闭方当前 RCV.NXT（与第二次挥手的确认号一致，因主动关闭方已关闭发送通道，无新数据需确认）；
• RFC 793 原文逻辑（Page 61）：

  状态：CLOSE-WAIT STATE（CLOSE Call 处理）
  Queue this request until all preceding SENDs have been segmentized; then send a FIN segment, enter CLOSING state.

• 通俗解读：
  被动关闭方先确保所有未发送的剩余数据（如服务器的响应尾、日志数据等）按协商后的 MSS 分段并发送完成，再发送 FIN 段——本质是告诉主动关闭方 “我这边也没有数据要发了，关闭我的发送通道”。
  需注意：RFC 793 提到发送 FIN 后进入 CLOSING 状态，这是理论上的 “同时关闭” 场景（双方同时发送 FIN）；但实际工程中，被动关闭方因已收到主动关闭方的 FIN，发送自己的 FIN 后会直接进入 LAST-ACK 状态，核心任务是等待主动关闭方对自己 FIN 的 ACK 确认。

4. 第四次挥手：主动关闭方回复 ACK 段，进入 TIME-WAIT 状态

• 触发场景：主动关闭方在 FIN-WAIT-2 状态（收到第二次挥手的 ACK 后，从 FIN-WAIT-1 转入）下，收到被动关闭方的 FIN 段。
• TCP 报文头部关键字段：
  • 控制位：FIN=0，ACK=1（仅确认被动关闭方的 FIN，主动关闭方的发送通道已在第一次挥手时关闭，无需再发 FIN）；
  • 序列号：Sequence Number = 主动关闭方当前 SND.NXT（与第一次挥手的 FIN 序列号 + 1 一致，因主动关闭方无新数据发送，序列号保持不变）；
  • 确认号：Acknowledgment Number = 被动关闭方 FIN 序列号 + 1（确认收到被动关闭方的 FIN 段，期望下一个序列号是 FIN 序列号 + 1，因 FIN 占用 1 个序列号）；
• RFC 793 原文逻辑 1：回复 ACK 并进入 TIME-WAIT（Page 75）：

  状态：FIN-WAIT-2 STATE（SEGMENT ARRIVES 处理）
  eighth, check the FIN bit
  If the FIN bit is set… advance RCV.NXT over the FIN, and send an acknowledgment for the FIN. Enter the TIME-WAIT state. Start the time-wait timer, turn off the other timers.

• RFC 793 原文逻辑 2：TIME-WAIT 超时后彻底关闭（Page 77）：

  TIME-WAIT TIMEOUT
  If the time-wait timeout expires on a connection delete the TCB, enter the CLOSED state and return.

• 通俗解读：
  1. 主动关闭方收到被动关闭方的 FIN 后，立即发送 ACK 段确认 “你的 FIN 我已收到”，随后进入 TIME-WAIT 状态，并启动 “2 倍最大段生命周期（2MSL）” 计时器（MSL 即报文在网络中最大存活时间，默认 1 分钟，2MSL 为 2 分钟）；
  2. TIME-WAIT 状态的核心作用：一是确保被动关闭方能收到第四次挥手的 ACK（若 ACK 丢失，被动关闭方会重传 FIN，主动关闭方可在 2MSL 内再次回复 ACK）；二是避免 “旧连接的残留报文” 干扰新连接（2MSL 足够让网络中所有旧报文过期）；
  3. 当 2MSL 超时后，主动关闭方删除 TCB（传输控制块，记录连接状态的核心数据结构），进入 CLOSED 状态；被动关闭方收到第四次挥手的 ACK 后，也删除 TCB，进入 CLOSED 状态——至此，TCP 双向连接彻底关闭。

四、关键问题 1：被动关闭方未收到第四次挥手（ACK）会怎样？（结合报文重传）

若主动关闭方发送的第四次挥手（ACK 段）因网络丢包、延迟等原因未被被动关闭方接收，被动关闭方会通过 TCP 内置的 “重传机制” 重传 FIN 段（即第三次挥手的 FIN），这是 RFC 793 定义的可靠传输核心逻辑，具体流程如下：

1. 场景定位：被动关闭方处于 LAST-ACK 状态

被动关闭方发送 FIN 段（第三次挥手）后，进入 LAST-ACK 状态，此时 TCB 中会记录 “已发送但未确认的 FIN 段”，并启动 “重传计时器”（RFC 793 称为 Retransmission Timer）。根据 RFC 793 规范，重传计时器的初始超时时间通常为 1 秒，后续采用 “指数退避” 策略（超时时间翻倍，如 1s→2s→4s→8s…），避免因网络拥塞加剧重传风暴。

2. RFC 793 重传机制的通用规则（所有未确认段均适用）

TCP 协议的核心设计目标之一是 “可靠传输”，因此任何发送后未收到确认的段（包括数据段、FIN 段、SYN 段），都会被放入 “重传队列”，超时后触发重传。

• RFC 793 原文逻辑（Page 77）：

  RETRANSMISSION TIMEOUT
  For any state if the retransmission timeout expires on a segment in the retransmission queue, send the segment at the front of the retransmission queue again, reinitialize the retransmission timer, and return.

• 通俗解读：
  无论 TCP 处于哪个状态（包括 LAST-ACK），只要重传队列中的段超时未收到确认，就会重新发送该段，并重置重传计时器。对于 LAST-ACK 状态的被动关闭方，重传队列中只有 “未被确认的 FIN 段”，因此超时后会 再次发送 FIN 段（即重复第三次挥手）。

3. 被动关闭方的重传终止条件

被动关闭方不会无限重传 FIN 段，RFC 793 虽未明确最大重传次数，但工业实践中通常遵循以下规则：

• 条件 1：收到第四次挥手的 ACK：被动关闭方收到主动关闭方的 ACK 段后，确认自己的 FIN 已被接收，立即删除 TCB，从 LAST-ACK 转为 CLOSED 状态，终止重传；
• 条件 2：达到最大重传次数：若重传次数达到阈值（如 Linux 系统默认 5 次），被动关闭方判断网络已无法正常通信，强制删除 TCB，进入 CLOSED 状态，终止重传（此时可能导致少量未传输完成的数据丢失，但符合 TCP 可靠传输的 “尽力而为” 原则）。

4. 主动关闭方的应对：TIME-WAIT 状态下再次回复 ACK

当被动关闭方重传 FIN 段时，主动关闭方正处于 TIME-WAIT 状态（已发送第四次挥手的 ACK，但 2MSL 未超时），会通过以下逻辑处理重传的 FIN：

• RFC 793 原文逻辑（Page 72、75）：

  TIME-WAIT STATE（SEGMENT ARRIVES 处理）
  The only thing that can arrive in this state is a retransmission of the remote FIN. Acknowledge it, and restart the 2 MSL timeout.

• 通俗解读：
  主动关闭方在 TIME-WAIT 状态下收到重传的 FIN 段后，会 再次发送 ACK 段（重复第四次挥手），并重启 2MSL 计时器——确保被动关闭方最终能收到 ACK，同时避免自己过早关闭连接导致无法处理后续重传的 FIN。

五、关键问题 2：MSS 协商失败或不协商会导致什么问题？（结合 RFC 793 与实践）

MSS 协商是 TCP 连接建立阶段的隐性但关键步骤，若未协商或协商失败，会直接影响数据传输效率甚至导致传输异常，具体问题如下：

1. 未协商 MSS：使用默认值可能导致 IP 分片

若双方在三次握手阶段未携带 MSS 选项（如早期简化版 TCP 实现），根据 RFC 793 规范，TCP 会默认使用 536 字节 作为 MSS（对应 IP 数据报大小 576 字节，这是 RFC 791 定义的 IP 最小重组缓冲区大小）。

• 问题场景：若双方实际网络的 MTU 大于 1500 字节（如数据中心内部网络 MTU=9000 字节，即 “巨帧” 网络），使用 536 字节的默认 MSS 会导致 TCP 报文段过小，每个数据报仅携带少量数据，头部开销占比过高（如 20 字节 TCP 头部 + 20 字节 IP 头部，数据仅 536 字节，头部开销占比约 7.1%），传输效率大幅下降；
• 反向问题：若双方网络 MTU 小于 576 字节（如某些窄带物联网网络 MTU=256 字节），默认 536 字节的 MSS 会导致 TCP 报文段（536+20+20=576 字节）超过 MTU，触发 IP 层分片——IP 分片后若任一分片丢失，需重传整个数据报，且重组过程消耗设备 CPU 资源，易导致传输延迟增加甚至丢包。

2. MSS 协商不一致：以较小值为准，但需避免 “MSS 欺骗”

根据 RFC 793 隐含的协商规则，双方最终使用的 MSS 是 “客户端 MSS 与服务器 MSS 的较小值”，这是保障传输兼容性的关键。但实践中可能出现 “MSS 欺骗” 问题（如恶意设备伪造 MSS 选项，声称支持超大 MSS）：

• 风险场景：若客户端伪造 MSS=65535 字节（TCP 数据部分最大理论值），但实际网络 MTU 仅 1500 字节，服务器按 65535 字节的 MSS 发送数据，会导致 TCP 报文段（65535+20+20=65575 字节）远超 MTU，触发大量 IP 分片，网络拥塞风险剧增；
• 防御机制：现代 TCP 实现（如 Linux、Windows）会在接收 MSS 选项后，结合本地网络的 MTU 进行校验，强制将 MSS 限制为 “本地 MTU - IP 头部长度 - TCP 头部长度”，避免因 MSS 欺骗导致的传输异常，这是对 RFC 793 规范的工程化补充。

六、总结：从 RFC 793 看 TCP 可靠设计的三大核心

TCP 作为面向连接的可靠传输协议，其设计细节在 RFC 793 中体现得淋漓尽致，结合本文拆解的报文头部、MSS 协商、三次握手/四次挥手及重传机制，可归纳为三大核心设计思想：

1. 基于 “状态机” 的连接生命周期管控

RFC 793 定义了 TCP 的 11 种状态（如 CLOSED、LISTEN、SYN-SENT、ESTABLISHED、FIN-WAIT-1 等），通过状态转换严格管控连接的建立、数据传输、关闭全流程——每个状态的进入/退出都依赖明确的报文交互（如 SYN 触发 LISTEN→SYN-RECEIVED，ACK 触发 SYN-RECEIVED→ESTABLISHED），确保连接状态的一致性，避免 “半开连接”“僵尸连接” 等问题。

2. 基于 “序列号+确认号” 的可靠传输保障

TCP 报文头部的序列号和确认号是可靠传输的 “基石”：

• 序列号确保数据的 “有序性”（接收方按序列号重组数据）；
• 确认号确保数据的 “完整性”（发送方通过确认号判断数据是否被接收，未确认则重传）；
• 即使是 SYN、FIN 这类控制段，也会占用序列号并需要确认，确保连接建立和关闭的可靠性（如三次握手需确认两次 SYN，四次挥手需确认两次 FIN）。

3. 基于 “选项协商” 的传输兼容性优化

MSS 选项是 TCP 选项协商的典型代表，RFC 793 通过可选字段的设计，让 TCP 能适配不同网络环境（如窄带、宽带、巨帧网络）：

• 协商过程不增加额外交互（随三次握手的 SYN/SYN+ACK 段携带），无性能开销；
• 结果以 “最小兼容值” 为准，平衡传输效率与兼容性；
• 后续扩展的选项（如窗口缩放选项 RFC 1323、SACK 选项 RFC 2018）也延续了这一设计思路，让 TCP 能随网络技术演进不断优化。

若需深入验证本文内容，可直接查阅 RFC 793 原文（https://datatracker.ietf.org/doc/rfc793/），或通过 Wireshark 抓包分析实际 TCP 连接的报文交互（如过滤条件 tcp.port == 80，观察三次握手的 SYN/SYN+ACK/ACK 段及 MSS 选项），理论与实践结合更易掌握 TCP 核心机制。