TCP 协议详解

1.概述

TCP（Transmission Control Protocol，传输控制协议）是互联网协议栈中最重要的传输层协议。它运行于网络层 IP 协议之上，为应用层提供一种可靠的、有序的、面向连接的全双工字节流服务。HTTP/HTTPS、SSH、FTP、SMTP 等绝大多数应用层协议都构建在 TCP 之上。

1981 年发布的 RFC 793 首次完整定义了 TCP。此后四十余年间，大量修订散落在多个独立文档中。RFC 9293（2022 年 8 月，STD 7）将这些修订与 RFC 793 的原始规范汇集为一，成为当前 TCP 的唯一权威基础规范：它废止了 RFC 793 以及 879、2873、6093、6429、6528、6691 等修订文档，并更新了 RFC 1011、1122、5961。拥塞控制等复杂算法则有意留给 RFC 5681、6298、7323 等伴随文档规定。

1.1 TCP 提供的服务（RFC 9293 §2.2 关键概念）

• 面向连接（Connection-oriented）：通信前必须经「三次握手」建立连接，通信结束后通过「四次挥手」释放。连接状态只存在于通信双方端点上，网络中间设备不感知 TCP 连接。
• 可靠传输（Reliability）：每个字节都有序号；接收方通过确认（ACK）告知已收到的数据；发送方超时未收到确认即重传；校验和检测损坏；重复数据被丢弃、乱序数据被重排。
• 有序交付（In-order delivery）：无论报文段以何种顺序到达，TCP 都按字节序号重排后，按序交付给应用层。
• 字节流（Byte stream）：TCP 不保留应用层报文边界——应用写入 2 次共 2000 字节，对端可能读 3 次才读完。这就是所谓「粘包/拆包」现象的根源，报文边界需由应用层协议自己界定。
• 全双工（Full duplex）：连接双方可以同时收发，每个方向独立编号、独立关闭（半关闭）。
• 点对点（Point-to-point）：一条 TCP 连接恰好有两个端点，不支持广播或多播。
• 流量控制（Flow control）：接收方通过「窗口」字段通告自己的接收能力，防止快速发送方淹没慢速接收方。
• 拥塞控制（Congestion control）：发送方维护拥塞窗口 cwnd，平稳时每 RTT 加性增大约 1 MSS，丢包或收到 ECN 拥塞标记时乘性减小（AIMD），既保护网络不崩溃，也维持多流间的近似公平。RFC 9293 只要求「必须实现某种拥塞控制」，慢启动、拥塞避免、快速重传/快速恢复四大机制的完整介绍见本文第 9 节（规范原文在 RFC 5681，RTO 计算在 RFC 6298）。

1.2 连接与四元组

一条 TCP 连接由四元组唯一标识：(源IP, 源端口, 目的IP, 目的端口)。同一台服务器可以用同一个 443 端口同时服务成千上万的连接，因为每个连接的源 IP/源端口组合不同。TCP 报文段封装在 IP 数据报中传输：[ IP 首部 | TCP 首部 | 应用数据 ]。下文第 2 节将逐字段剖析 TCP 首部。

2.TCP 报文段格式（RFC 9293 §3.1）

TCP 首部固定部分 20 字节，加上可变长选项后最长 60 字节，其后才是应用数据。下图为交互式首部结构图（与 RFC 9293 图 1 一致）：把鼠标悬停在任意字段上即可在下方说明栏查看该字段的详细解释；单击字段可以「钉住」当前说明，方便滚动阅读，再次单击取消。

2.1 字段速查表

2.2 校验和与伪首部（Pseudo-header）

计算校验和时，TCP 在首部之前概念性地拼上一个 96 位（IPv4）伪首部——它来自 IP 层，并不随报文传输。把源/目的地址纳入校验，可以防止报文段被错误路由后仍被接收方接受。IPv4 伪首部结构如下（悬停查看各字段）：

3.TCP 选项（RFC 9293 §3.2）

选项位于首部末尾，总长须为 4 字节的整数倍（不足时以 EOL/零填充）。RFC 9293 规定所有实现必须支持 EOL、NOP、MSS 三个选项（MUST-4）；窗口扩大、SACK、时间戳定义于 RFC 7323 / 2018 等文档，是实现高性能 TCP 的事实标准。悬停下列选项卡片查看详情。

4.连接的建立：三次握手（RFC 9293 §3.5）

建立连接的本质是双方可靠地交换初始序列号（ISN）并确认对方收到。下图为标准的三次握手时序，悬停每个报文查看该步的细节与状态变迁。

4.1 为什么必须是三次，而不是两次？

• 双向序号都要可靠交换：TCP 是全双工，双方各有一条字节流、各有一个 ISN。每个 ISN 都需要「发送 + 对方确认」两个环节，两次握手无法让服务器确认客户端收到了它的 ISN。
• 防止历史连接复活：网络中可能滞留已失效的旧 SYN 报文（延迟的重复 SYN）。若两次握手即建连，一个迟到的 SYN 就会让服务器凭空分配资源并进入已连接状态。第三次 ACK 使服务器能核实「客户端确实在等这条连接」，迟到 SYN 换来的只会是客户端的 RST。

4.2 相关细节

• 同时打开（simultaneous open）：双方几乎同时向对方发 SYN，各自经历 SYN-SENT → SYN-RECEIVED → ESTABLISHED，共四个报文，最终只建立一条连接（§3.5，状态机中 SYN-SENT 收到 SYN 的边即对应此情形）。
• ISN 随机化：ISN 不应从 0 或可预测值开始——早期实现的 ISN 可预测，攻击者无需抓包就能猜中序号，凭空伪造 RST 切断他人连接或注入数据（盲攻击，真实出过多起安全事故）。RFC 9293 §3.4.1 吸收 RFC 6528，推荐的生成方案为：
  ISN = M + F(源IP, 源端口, 目的IP, 目的端口, 本地密钥)　# M ≈ 每 4µs 递增的计时器；F = 单向散列（如 MD5/SHA-1）
  计时器分量 M 保证同一四元组的 ISN 随时间单调推进（避免新旧连接序号冲突）；散列分量 F 使外部无法从一条连接的 ISN 推出下一条；本地密钥定期更换、绝不外发。这正是抓包里 tcp.seq_raw 总是一大串随机数的原因（§11.3）。
• 半开连接与 RST：一方崩溃重启后收到对方发来的数据段（不属于任何已知连接），应回复 RST 拆除这条「半开」连接（§3.5.1/§3.5.2）。
• SYN 泛洪：攻击者只发 SYN 不回 ACK，耗尽服务器半连接队列；通用防御是 SYN Cookies（推迟状态分配，RFC 4987，信息性文档）。

5.连接的终止：四次挥手（RFC 9293 §3.6）

FIN 的含义是「我这一方数据发完了」。由于 TCP 全双工，两个方向要分别关闭，因此正常释放需要四个报文。任一方向关闭后另一方向仍可传输，称为半关闭（half-closed，§3.6.1）。悬停各报文查看细节。

5.1 TIME-WAIT 与 2MSL

• MSL（Maximum Segment Lifetime）是报文段在网络中的最长存活时间，RFC 1122 建议 120 秒，故 2MSL = 240 秒；许多系统实现取更短（Linux 为 60 秒，常量不可调）。
• 主动关闭方是进入 TIME-WAIT 的一方。高并发短连接服务器若大量主动关闭，会积压 TIME-WAIT 套接字占用四元组资源——常见对策是让客户端主动关、启用连接复用（Keep-Alive/长连接）等。
• 同时关闭（simultaneous close）：双方几乎同时发 FIN，各自经 FIN-WAIT-1 → CLOSING → TIME-WAIT 路径收尾（见第 6 节状态机）。

5.2 真实抓包中的挥手变体：段数不够 4 不是异常

教科书是 4 个报文，真实抓包常常「不像」，因为 TCP 会合并报文（coalescing）：

• FIN 捎带数据：回完最后的数据立即 close()，内核把 [PSH, ACK, FIN] 合成一个包，看不到独立的 FIN 段；
• ACK+FIN 合并（3 段关闭）：收到 FIN 的一方恰好无数据待发，直接回 [FIN, ACK] 一个包——HTTP 短连接里极常见；
• 同时关闭：双方几乎同时发 FIN，各走 CLOSING（见 §6 状态机）。

判断异常要看 RST、重传、零窗口，而不是「段数不够 4」。但注意：关闭不可能只有 2 段——少任何一个方向的 FIN 或它的 ACK 都关不完，TCP 没有「快速挥手」机制。

5.3 只关一半之后：FIN-WAIT-2 有兜底，CLOSE-WAIT 没有

• 主动方卡在 FIN-WAIT-2（FIN 已被 ACK，对方的 FIN 迟迟不来）：多数内核有超时兜底（Linux tcp_fin_timeout，默认 60 秒），孤魂套接字会被自清；
• 被动方卡在 CLOSE-WAIT：没有任何内核超时，只能等应用调 close()。应用漏调 close、连接池不释放、keep-alive 卡死 → CLOSE-WAIT 只涨不跌，文件描述符耗尽，服务假死；
• 因此生产排障时，CLOSE-WAIT 堆积比单次重传更值得盯，实战判定方法见 §11.5。

6.TCP 状态机（RFC 9293 §3.3.2）

一条连接在任一时刻处于 11 种状态之一，状态随「用户调用 / 报文到达 / 超时」三类事件迁移。下图为完整状态迁移图：实线为正常路径，虚线为较少见路径；悬停任一状态节点查看其含义，迁移条件标注在箭头上（recv = 收到，send = 发送）。

6.1 状态迁移速查表

注：除 RST 触发的迁移外，表中列出正常迁移；任何状态收到合法 RST 都会中止连接回到 CLOSED/LISTEN。

6.2 RST 的生成与处理（RFC 9293 §3.5.2–3.5.3 要点）

何时生成 RST：凡收到「不属于任何已知连接」的非 RST 报文段（如发到未监听端口的 SYN、半开连接上收到的数据段），原则上都应回送 RST。RST 的序号/确认号取值分两种情形，目的都是让对方能立即采信：

• 入站段带有 ACK：RST 的序列号直接取入站段的确认号（seq = 入站 ack），且不置 ACK 位——这个值必然等于对方下一期待序号，落在其窗口正中；
• 入站段不带 ACK：RST 序列号取 0、置 ACK 位，确认号 = 入站段序号 + 段长（SYN/FIN 各按 1 计），即 ack = 对方的 Next Seq。

收到 RST 如何处理（吸收 RFC 5961，防盲注攻击）：复位前先校验序号——RST 的序列号恰好等于 RCV.NXT 才直接拆除连接；落在接收窗口内但不等于 RCV.NXT 的，只回送一个 challenge ACK 请对方重发正确的 RST，连接保持不动；窗口之外的直接丢弃。攻击者要盲猜中 32 位序号里的唯一正确值，概率约 2⁻³²，伪造 RST 断连的门槛由此大幅抬高。

RFC 9293 对 RFC 5961 的一处澄清：SYN-RECEIVED 状态收到合法 RST 时，若连接源自被动打开，应回到 LISTEN 继续等待新连接，而不是直接进入 CLOSED——这也是 RFC 9293 相对旧文档为数不多的实质改动之一。

7.可靠传输机制（RFC 9293 §3.4 / §3.8）

TCP 在不可靠的 IP 之上提供可靠字节流，依赖四根支柱：编号与确认、超时重传、快速重传、差错检测。

7.1 字节编号与累计确认

• 字节流中每个字节都有 32 位序号；报文段只携带其第一个数据字节的序号，段长即隐式给出本段覆盖的序号区间。SYN 与 FIN 各消耗一个序号。
• 确认号表示「下一期望字节」：ack = N 意味着 N 之前的所有字节已收妥（累计确认）。这种方式对丢失个别 ACK 具有鲁棒性——后到的 ACK 能覆盖先前的确认。
• 序号空间为 2³² 会回绕，比较序号使用模运算（§3.4）：当且仅当 0 ≤ (b − a) < 2³¹（模 2³²）时认为 a < b。高速链路上序号可能数秒内回绕一圈——一个迟到的旧段，其序号可能恰好「回绕」进当前窗口而被误当新数据。防护机制是时间戳选项的 PAWS（Protect Against Wrapped Sequences，RFC 7323）：每个段携带单调递增的发送时间戳，接收方维护「最近有效时间戳」，凡是时间戳更老的段一律丢弃——于是旧连接的迟到段即使序号巧合落入窗口，也会因时间戳过时被剔除。
• 接收方缓存乱序到达的段，补齐空洞后按序交付应用；重复段直接丢弃。

7.2 超时重传与 RTO 估算（§3.8.1，算法见 RFC 6298）

每发出一个含数据的段即启动重传定时器，超时（RTO）未收到确认则重传。RTO 不能拍脑袋定：太小导致不必要的重传加剧拥塞，太大则丢包恢复缓慢。标准做法是 Jacobson/Karels 算法，动态跟踪 RTT 的均值与波动：

• Karn 算法：重传过的段不用于 RTT 采样（无法区分 ACK 对应原段还是重传段）；且每次重传将 RTO 加倍（指数退避），直到收到对未重传段的确认才恢复正常估算。
• 边界参数（RFC 6298）：更精确的公式是 RTO = SRTT + max(G, 4·RTTVAR)，G 为系统计时器粒度（越细越好）；拿到首个 RTT 样本前初始 RTO = 1 秒；建议上限 60 秒；采样规则——首个样本直接令 SRTT = R′、RTTVAR = R′/2，之后每个新样本才按上式以 α、β 平滑更新。
• 借助时间戳选项（TSopt），每个段都可精确测 RTT，不受重传二义性影响。

7.3 快速重传（Fast Retransmit）

接收方收到失序段时会立即重发对已收妥字节的确认（重复 ACK）。若发送方连续收到 3 个重复 ACK（dupthresh = 3），说明某个段大概率已丢失而非仅仅延迟——于是不等超时立即重传该段。快速重传把丢包恢复时延从一个 RTO 缩短到一个 RTT 量级，通常与快速恢复（§9）配合。

7.4 差错检测

• 16 位校验和覆盖伪首部 + 首部 + 数据（见 §2.2），校验失败的段被静默丢弃，由超时/重复 ACK 机制触发重传。发送方必须生成、接收方必须校验（MUST-2 / MUST-3）。
• 校验和仅 16 位，检错能力有限，但链路层 CRC 与之配合，实践中足够；伪首部使其额外具备防误投递能力。

7.5 其他可靠性相关的规范要点

• 延迟 ACK：接收方可延迟发送 ACK 以便与反向数据捎带，但延迟不得超过 500 ms，且对全尺寸段应至少每 2 个段确认一次（吸收自 RFC 1122，§3.8.6/§3.10.8）。
• Keep-Alive（§3.8.4）：可选机制，用于探测长期空闲连接的对端是否存活；默认必须关闭，开启后空闲探测间隔不得小于 2 小时（MUST-17）。注意它与 HTTP 的 Keep-Alive 只是同名，毫无关系。
• 连接故障判定（§3.8.3）：持续重传超过实现定义的阈值（如 R1/R2）后向应用报告错误并放弃；超时阈值建议 ≥ 100 秒。
• 静音时间（quiet time，§3.4.3）：主机崩溃重启后，在 MSL 内不应发出任何报文段，防止旧连接的残余报文被误认为属于新连接。

8.流量控制：滑动窗口（RFC 9293 §3.8.6）

每个 ACK 报文中的 Window 字段都在告诉发送方：「从确认号开始，我还能再收 rwnd 个字节」。发送方据此维护发送窗口，任何时刻未确认数据量不得超过对方通告的窗口——这就是滑动窗口流量控制，它保证快速发送方不会淹没慢速接收方。悬停下图各区域查看含义。

8.1 窗口管理的关键问题

• 零窗口与坚持定时器：接收方缓冲耗尽时通告 Window = 0，发送方停止发送数据。此后接收方应用读走数据会发出窗口更新（不含数据的 ACK）——但 ACK 不保证送达，若丢失则双方互等形成死锁。为此发送方启动坚持定时器（persist timer），周期性发送 1 字节的窗口探测（Zero Window Probe，指数退避、约 60 秒封顶），直到拿到非零窗口通告（§3.8.6）。此处吸收了 RFC 6429 的修订：旧规（RFC 1122）要求无限期坚持探测，RFC 6429 允许实现为「坚持状态」增设发送超时——超时后拆除连接并向应用报错，避免对端永远零窗口时应用被永久吊死。
• 糊涂窗口综合征（Silly Window Syndrome, SWS）：若接收方应用每次只读 1 字节就通告 1 字节窗口，发送方就发 1 字节的段，网络将被大量小报文充斥。RFC 9293 吸收 RFC 1122 的两端对策（§3.8.6）：
  • 接收方（Clark 方案）：缓冲可用空间小于一个全尺寸段或缓冲的一半时，通告零窗口，攒够再一次通告；
  • 发送方（Nagle 算法）：见下条。
• Nagle 算法（§3.7.4）：只要还有未确认的数据在途，发送方就把后续的小块应用数据缓冲起来，直到积满一个 MSS 或收到 ACK 才发送。它用微小的延迟换取小报文聚合，显著减少交互式流量的小段数量。对延迟敏感的应用（游戏、终端回显）可用 TCP_NODELAY 关闭。
• 窗口更新策略：RFC 9293 建议接收方避免频繁通告微小窗口增长（REC-级别要求），并提供了何时发送窗口更新的指导，以防 SWS 复发。

9.拥塞控制（RFC 9293 §3.8.2 → RFC 5681 / 6298）

RFC 9293 有意不收录完整的拥塞控制算法（§1：让基础规范可与多种算法组合），只要求实现必须支持某种拥塞控制，并指向伴随文档。以下是经典算法（RFC 5681「TCP 拥塞控制」+ RFC 6298「RTO 计算」）的框架，现代实现（CUBIC、BBR）在此基础上演进。

9.1 核心状态变量

• cwnd（拥塞窗口）：发送方给自己设的在途数据上限（字节）。
• ssthresh（慢启动阈值）：cwnd 低于它走慢启动，高于它走拥塞避免。
• rwnd：对方通告的接收窗口；实际上限取 min(cwnd, rwnd)。

9.2 四个经典机制

9.3 丢包即拥塞信号：AIMD

• 超时被视为严重拥塞：ssthresh ← cwnd/2，cwnd ← 1 MSS，重新慢启动。
• 3 个重复 ACK被视为轻度拥塞：走快速重传 + 快速恢复，cwnd 减半。
• 整体上「加性增大、乘性减小」（AIMD），使多条 TCP 流在共享链路上收敛到近似公平，并保持网络稳定——这是 TCP 对互联网最重要的贡献之一（Van Jacobson, 1988）。

10.专题：MTU/MSS、粘包与常用观察手段

10.1 MSS、MTU 与分片

• MTU（链路层最大传输单元，以太网 1500 字节）→ MSS 典型值 = 1500 − 20（IP 首部）− 20（TCP 首部）= 1460 字节。IPv6 首部 40 字节，对应 MSS 1440。
• TCP 按 MSS 把字节流切成段（§3.7 分段），目标是不让 IP 层分片——分片丢失任一片即整包重传，效率低下。
• 路径 MTU 发现（PMTUD，§3.7.2，RFC 1191/8201）：发送时置 IP 首部的 DF（禁止分片）位；途经 MTU 更小的路由器无法转发，会回 ICMP「需要分片」并附下一跳 MTU，TCP 据此把段长调到该值以下，逐跳收敛到全路径最小 MTU。PMTUD 黑洞：若防火墙把 ICMP 一刀切误杀，发送方永远收不到通告——典型症状是「SYN 能通、小请求正常、一发大包就卡死超时」。对策：放行 fragmentation-needed 类 ICMP；或改用不依赖 ICMP 的 PLPMTUD（RFC 4821，用 TCP 自己的探测段逐步试大）；Linux 另有 net.ipv4.tcp_mtu_probing 兜底开关。

10.2 「粘包」不是 TCP 的问题

TCP 是字节流协议，不保留应用层消息边界：一次 send 可能被拆成多个段，多次 send 也可能被 Nagle 合并进一个段。期望按「条」收消息是应用层的责任，常见做法：① 定长消息；② 分隔符（如 HTTP/1.x 的 \r\n\r\n）；③ 长度前缀（如先发送 4 字节长度）。UDP 才是保留报文边界的协议——这也是「面向报文」与「面向字节流」的本质区别。

10.3 观察 TCP 的常用命令

经验：服务器大量 CLOSE-WAIT → 应用忘记 close；大量 TIME-WAIT → 本端在主动关闭短连接，考虑长连接复用；大量 SYN-RECEIVED → 疑似 SYN 泛洪。Wireshark 侧的过滤器与专家信息读法见第 11 节。

11.抓包实战：用 Wireshark 读懂 TCP

前面讲的是规范怎么写，这一节看线上长什么样。内容来自对真实生产抓包（内网监控终端 ↔ 负载均衡，单条连接 66 个报文）的完整复盘，重点收录初学者最容易犯晕的几个点，与前面的规范条文一一对应。

11.1 先钉死三个数：Seq / Next Seq / Ack

• Seq（序列号）：本段第一个字节在发送方自己这条流里的编号——Seq 永远是发送方在数自己往外发的字节。
• Next Seq（下一序列号）：Wireshark 的派生值，TCP 首部里根本没有这个字段。线上只传 Seq 和 Ack，Next Seq 是 Wireshark 按公式替你算出的「下一段从哪开始」。
• Ack（确认号）：本报文发送方在告诉对方「接下来请给我第 N 字节」，即「编号小于 N 的连续字节我全收到了」——它永远指向对方的 Seq，跟本行的 Seq 是两套体系。

全双工意味着两本账、四个数同时跑：客户端的 Seq 由服务端的 Ack 追踪，服务端的 Seq 由客户端的 Ack 追踪，互不干扰。看到 C→S 一行的 Ack 在变化，那是客户端在确认「服务端的数据收到哪了」，与这一行自己的 Seq 无关——别被它搞懵。

11.2 一轮真实事务的逐包验算（悬停每一行看剧情）

以下是一条健康连接（HTTP over TCP，Wireshark 相对序号视图）的三次握手与第一轮请求/响应。拿黄金等式逐行验算：每个「对方回的 Ack」都精确等于「你的 Next Seq」。

这条连接按同样的流水线跑了 9 轮半（客户端共发 15008 B，服务端回 11402 B），全程零重传、零 RST、Ack 严格单调——教科书级健康。最后一包（#48594，又一个 1388 字节请求首段）没等到 ACK：不是丢了，是抓包在这一刻停了，服务端的确认没来得及被记录。看抓包下结论前，先看抓包窗口。

11.3 一开始最容易晕的 8 个点

11.4 Wireshark 排障三板斧

① 显示过滤器（逻辑运算：and/&&、or/||、not/!；混用时务必加括号，and 优先于 or）：

② 专家信息（分析 → 专家信息）：Warning 级重点看 [TCP Retransmission]、D-SACK（对方报告「早收过了」，说明存在不必要的重传——ACK 丢失或 RTO 太激进）；Note 级的 (Suspected) spurious retransmission 是伪重传（数据其实到了，ACK 丢了导致误判）；ACKed segment not captured 只是抓包起点问题，正常现象。

③ 量化判读：重传率 > 1%~2% 需警惕，> 5% 基本可断定链路丢包；常见元凶是 Wi-Fi 干扰、带宽跑满、对端过载、中间设备丢包。统计 → TCP 流图形 → Time-Sequence (Stevens) 里，重传表现为「往回掉再跟上」的锯齿。

11.5 生产案例剪影：负载均衡与 CLOSE_WAIT

• LB 是两条独立的 TCP 连接：客户端↔LB、LB↔后端各自走自己的状态机。客户端先 FIN 时，LB 回完 ACK 就卡在 CLOSE_WAIT 等后端关闭——后端不发它自己的 FIN，LB 就没资格给客户端发 FIN，抓包便看到「只有一半的挥手」。LB 先 FIN 时通常能干净关完（说明后端已就绪）。
• 判良性还是泄漏（在 LB 上执行）：
  ss -tan | grep :9001 | grep CLOSE_WAIT | wc -l　# 隔几秒再跑，对比数字
  ss -tan | grep :9001 | awk '{print $1}' | sort | uniq -c　# 状态分布全貌
  数字稳定、偶尔几个、过会儿归零 → 良性（只是没抓全）；只涨不跌 → 后端应用没 close()，socket 泄漏，去查后端。回顾 §5.3：FIN-WAIT-2 有内核超时兜底，CLOSE-WAIT 没有。
• 单侧抓包的局限：在客户端侧抓包看不到 LB↔后端那一段，只能反推——客户端 FIN 之后，LB 过一阵是否给客户端发它自己的 FIN+ACK？有 → 间接证明后端关了；一直不来 → 后端没关或 LB 卡住，权威判据仍是上面的 ss。
• 健康样本对照：一次「180 B 请求 → 8 B 响应」的短连接（44418↔6661），握手 3 步、Seq/Ack 数学全吻合、窗口正常波动、零重传零 RST、服务端 FIN 收尾——完整生命周期的连接就该长这样。
• 实操提醒：要看完整报文内容，抓包时 tcpdump -s 0（snaplen 拉满）；双层 VLAN（QinQ）链路上抓包需在 Wireshark 确认 VLAN 解析正常，否则内层 IP/TCP 显示不全。

11.6 抓包判读进阶：文件质量、窗口定位与看包顺序

11.1–11.5 都默认抓包是干净完整的，真实世界常常不是：镜像口把同一份包交错复制了好几遍、tcpdump 默认 snaplen 只留 64 字节、链路还有乱序。这一节处理三件事——抓包本身可不可信、窗口归零该查谁、按什么顺序看包。要点来自一次带重复镜像包与 64 字节截断的真实抓包复盘。

① 先给抓包「体检」：文件质量决定判读可信度

② 红色提示的正确读法：分析提示 ≠ 线上字段

方括号里的 [TCP …] 是 Wireshark 依序号关系推算出来的注解，不是 TCP 首部里真实携带的字段。在脏抓包里尤其要降级看待：

③ Zero Window ↔ Window Update：先分清是谁喊的

• Win=0 是接收方在喊「我满了」：报文里的 Window 通告的是发送该报文这一端的剩余接收空间。看到 A → B：Win=0，含义是 A 暂时收不下 B 的数据、B 应暂停正常发送——瓶颈在 A（接收方），优先查它的应用读取速度与接收缓存，不是发送方故障。
• Window Update 是接收方「缓过来了」：应用读走数据、缓存腾出空间后，接收方会发一个 ACK 不变但 Win 变大的报文（如 Ack=500 Win=0 → Ack=500 Win=4096）——这就是 Window Update（§8.1）。
• 判读口径：短暂出现 Zero Window 多为正常突发；长时间保持为 0 才值得重点排查。且 Zero Window 是某一条连接的问题，不代表整台主机或网卡坏了。

④ 到 Linux 上印证：ss -tinp

判断方向看谁发出了 Win=0：发 Win=0 的那一端是接收方，优先检查它的应用与接收缓存。

⑤ 看包的推荐顺序（别一上来就盯红色提示）

12.发送速率、窗口与 RTT：从流量控制到数据中心微突发

§8 讲了窗口怎么滑、§9 讲了 cwnd 怎么涨。这节把「窗口」和「实际能发多快」彻底串起来，并延伸到数据中心里绕不开的微突发（microburst）——它正是交换机 buffer、ECN、PFC/ETS 调优要压的场景。

12.1 发送端是「窗口受限」的：在途数据永远 ≤ W

§8.1 已给出在途上限 min(cwnd, rwnd)。把接收窗口 rwnd 记作 W（不失一般性，取瓶颈窗口），则任意时刻「已发未确认（在途）」的字节数 ≤ W。于是 TCP 会连续发送数据，直到在途量（FlightSize）达到发送窗口 W，窗口就满了，必须等 ACK 回来才能发下一个 W——这就是「窗口受限」。

12.2 持续发送速率由窗口与 RTT 决定，其上限再受线速约束

ACK 为 TCP 提供发送时钟（ACK Clock），窗口 W 决定每个 RTT 能发送的数据量，因此持续发送速率为 W/RTT。 一个 RTT 内，发送方随 ACK 的节奏连续注入数据、累计正好一个窗口 W，所以平均持续速率 = W / RTT。它与线速的关系由恒等式统一：

下图标出时序：t=0 以线速发出 W → 耗时 D 到达对端 → ACK 再耗时 D 返回 → 直到 t=RTT 窗口才解锁、发下一 W。所以「速率」的分母必须用往返 RTT，而不是单程 D——决定能不能再发的，是 ACK 回来的整段往返时刻。

12.3 实际吞吐 = min(窗口派生速率, 线速)

窗口推导出的可持续发送速率与链路线速是两个上界，二者取小：

12.4 数据中心低 RTT 为何让「微突发」更凶（incast）

微突发：许多条流在同一时刻把流量怼进同一个出口，队列在微秒级暴涨、超过交换机 buffer，来不及被 TCP 降窗反应就丢包。数据中心低 RTT 非但没「治好」它，反而喂肥了它：

• BDP 极小，而交换机缓存通常也极小：在数据中心中，交换机端口缓存通常只有几十 KB 到几百 KB，与链路 BDP 处于同一数量级，因此对微突发的吸收能力有限。
• 每条流瞬间打满 C、每个 RTT（微秒级）重打：突发又尖又频。
• Incast 同步：N 条流各想以 C 进入一个 C 出口 → 进 N·C、出 C → 队列在 µs 内爆。而 TCP 降窗指令要等 1 个 RTT 才生效，可突发比 RTT 还短，等指令回来丢包早已发生。

用排队方程一句话说清（流体模型，Misra–Gong–Towsley SIGCOMM'00 框架）：

闭式 incast 模型（Zhang–Ren–Lin, INFOCOM'11，逐 RTT 同步分析）给出单流排队上限：

回到 §8（窗口滑动）与 §9（cwnd）：微突发本质是「聚合到达 N·W/R 压垮单出口 C」，而 §9 的加性增大/乘性减小（AIMD）降窗是这个压力的唯一反馈回路——可惜在 DC 微秒级突发里它慢了整整一个 RTT。

12.5 一页速记

13.术语与符号速查（RFC 9293 §3.3 / §4）

14.参考文献