一、为什么非切不可：三个"装不下"

应用层把数据交给 TCP 的时候，是一整坨——write() 一次写了 3 MB，TCP 就收到 3 MB 的字节流。它能不能"一票发出去"？不能，撞三堵墙（3.4 埋过这三堵墙，本节把它们对准 TCP）：

所以 TCP 必须自己先切。注意这里说的是"TCP 自己切"——和"IP 被迫分片"是两回事，第五节专门对比。

二、切多大：MSS 登场（本节第一个新概念）

切块不能随便切，得有把尺子。这把尺子叫 MSS（Maximum Segment Size，最大报文段长度）。

它的算法简单到只有一步减法：

MSS = MTU − IP 头 − TCP 头
    = 1500 −  20   −  20
    = 1460 字节

为什么要减掉两个头？ 因为"1500"是整个帧能装的数据上限，而这一段路要装的是「IP 头 + TCP 头 + 你的数据」三样。两个头各占 20 字节，剩下的才是留给数据的——1460。

MTU 和 MSS 别混：一个在链路层，一个在传输层

三、切完怎么编号（本节第一张图）

尺子有了，动手切。假设：

• 应用层交来 10000 字节
• MSS = 1460
• 握手时谈好的起始序号是 1001（为什么不是 0，见 3.18 的"起始序号是随机挑的"）

按 1460 一段切下去，能切出 7 段（6 个满段 + 1 个尾巴）：

算号的全部规则就一条：

本段序号 = 上段序号 + 上段的长度

1001 + 1460 = 2461 → + 1460 = 3921 → + 1460 = 5381 …… 一路加到 9761，最后一段只剩 1240 字节的余量，装多少算多少。

核对一下：6 × 1460 + 1240 = 8760 + 1240 = 10000 ✅ 不多不少，正好装完。

四、对面怎么对账：ACK 号（本节第二张图）

切好、编好、发出去。对面收到之后干什么？回一个号。

ACK 号（确认号）= 我下一个期望收到的字节编号。

也就是说：这个号之前的字节，我全收到了；从这个号开始，我还没收到。

还是上面那 7 段，逐段看：

这里就是本节最该看懂的一处

段 4、5、6 明明都送到了，为什么回的 ACK 号还停在 3921？

因为累积确认只认"缺口的起点"（3.18 讲过这个词，这里是它的现场）：

• 段 4 是 5381~6840 这一段，它后面的东西
• 而 3921~5380 那段还空着
• TCP 要交给程序的是一段连续的字节流，中间有个洞，后面的就接不上
• 所以接收方只能一遍遍说："我缺的是 3921，给我 3921"

顺带把"ACK 号不等于收到了"再钉一次

ACK 3921 ≠ 我收到了 3921 这个字节。

是"3921 之前的全收到了，从 3921 开始还没收到"。差这一个字节，重传范围就判错了（3.18 的误区 2，本节的表又演示了一遍）。

五、切段 vs 分片：两个"切"千万别混（本节最值钱的一张表）

现在可以把一笔大账结清了。网络里有两个"切"，名字都带"分"，但性质完全不同：

一句话：

TCP 切段是"主动规划"，IP 分片是"被迫拆解"。

而 MSS 的使命就是让 IP 永远不必分片——TCP 在源头就把段切到刚好能过，IP 层一路上都是轻装通过。

六、序号不是无限的：32 位会绕回来

序号字段是 32 位，能表示的数是 2³² = 4,294,967,296 ≈ 4.29 GB。

也就是说，一条连接每传完约 4.29 GB，序号就绕回 0 重来一次（术语叫序号回绕，wraparound）。绕一圈要多久？

在万兆网络下，序号 3 秒多就重来一遍。

那问题来了：新数据的序号和几秒前的老数据序号撞了怎么办？ 比如一个很晚才到、其实早该丢弃的旧段，怎么知道它是"上一圈的"而不是"这一圈的"？

答案是时间戳选项（TCP Timestamp，RFC 1323）：每个报文段都带一个时间戳，接收方靠它把"上一圈的段"和"这一圈的段"分开，这个机制叫 PAWS（Protection Against Wrapped Sequences，防序号回绕）。

七、两个该知道的小规矩

1. SYN 和 FIN 也各占一个序号

序号是按字节编的（3.18），但有两个"不装数据却占号"的特殊段：SYN 和 FIN。

所以握手时 SYN 报的序号是 X，第一个数据字节的序号就是 X + 1——不是 X。

例：SYN 的序号是 1000 → 第一个数据字节是 1001（本节例子里那个 1001 就是这么来的，自洽）→ 挥手时 FIN 也会再吃掉一个号。看抓包时对不上号，十有八九是忘了这两个家伙也占位。

2. 窗口报 0 的时候，发的是个"1 字节的探子"

接收方缓冲区满了会报窗口 0，发送方随即停发（收 3.18 的流量控制）。但它不能就这么死等——万一对面腾出位置了却不通知呢？所以它会定期发一个只带 1 个字节的探测包去试门。这个"1 字节探子"的序号也是正常递推的。

八、动手 Demo33：把"切"和"编"看个实在

1. 看本机的段账本 netstat -s -p tcp 找「发送的段」Segments Sent 与「接收的段」Segments Received 两项。
2. 打开一个网页、或下载一个大文件，再跑一遍——两个数字都会明显上涨

3. 涨的那部分，就是本节讲的"切出来的段"一段段出去的

4. 用段数 ÷ 字节数，验证 MSS（本节最实证的一步）

如果输出里有「发送的字节」Bytes Sent 这一项（不同系统项名可能不同，有就算）： 平均段长 ≈ 发送的字节数 ÷ 发送的段数 算出来应当在 1400 出头——因为每段最多 1460，而且不是每段都装满（尾段、小请求会拉低平均）。能算出这个数，就说明 TCP 真的在按 MSS 大小切。

1. 从 MTU 倒推 MSS，把两个算式对上（收 3.4 的 Demo18）

先用 ping 摸出自家 MTU： ping -f -l 1472 www.baidu.com 通了说明 MTU = 1500（因为 1472 + 20(IP 头) + 8(ICMP 头) = 1500）。

于是可以倒推： MSS = 1500 − 20(IP 头) − 20(TCP 头) = 1460

一个很漂亮的对照 1472 和 1460 差 12。这 12 是哪来的？ 是 ICMP 头（8 字节）和 TCP 头（20 字节）的差：20 − 8 = 12。

所以两个算式其实是同一件事： - ping：数据 1472 + IP 头 20 + ICMP 头 8 = 1500 - TCP：数据 1460 + IP 头 20 + TCP 头 20 = 1500

都是"数据 + 各种头 = MTU"，只是夹在中间的"头"换了个身份。

1. 看自家接口的 MTU 清单 netsh interface ipv4 show subinterface 看 「MTU」 列。有线网卡、Wi-Fi、回环的值可能各不同；连过 VPN 之后再看，会多出一条 MTU 明显偏小的条目——那就是"路变窄了"，MSS 得跟着让。

2. 30 秒实验：数一数"打开这个网页"用了多少段 netstat -s -p tcp 记下「接收的段」数字 → 刷新一个复杂网页 → 再看数字。涨了几十上百是常态——你眼里"一个网页",底下是成百上千个段在跑。

九、几条实战规矩

1. 看到"重传率"高，先怀疑 MTU/MSS 不合

链路一变窄（VPN、PPPoE），如果 MSS 没跟着降，TCP 切出来的段就会超重、逼出 IP 分片，重传率随之上升。"连上 VPN 网页就打不开 / 特别慢"多半是这里。

2. 抓包看序号时，记住三条递推关系

• 本段序号 = 上段序号 + 上段长度
• ACK 号 = 对方"下一个期望的字节号"
• SYN、FIN 各占 1 个序号（所以第一个数据字节 = SYN 序号 + 1）

三条对上，一串抓包记录就能读出整段故事。

3. 重复 ACK 是"诊断信号"，不是噪声

抓包里连着三个一模一样的 ACK 号，不用等超时——那是在告诉你"这个号开始的数据丢了"。看到它就去查那个位置前后的包。

4. 别用"段数"估流量，要用"字节数"

段数受 MSS 影响（大包少、小包多），同样 1 MB 数据，小包场景下段数会多得多。要估流量看字节计数。

十、常见误区

1. ❌ "序号是第几个包" → 是按字节编的号（3.18 已纠，本节再看一次）；正因为按字节编，切段长度变化时号码不会乱
2. ❌ "MSS 是链路决定的" → 链路给的是 MTU；MSS 是 TCP 握手协商出来的，是"为了迁就 MTU 而倒推的数"
3. ❌ "MSS 就是 1460" → 1460 只是 IPv4 + 以太网 的组合值；PPPoE 是 1452、VPN 还要更小
4. ❌ "段切得越小越保险" → 头开销占比会上升（每段固定 40 字节头），小包太多反而不划算；正解是"刚好不触发分片"
5. ❌ "段 4、5、6 到了，ACK 应该跳到 8300 之后" → 累积确认只认缺口起点，缺 3921 就一直回 3921
6. ❌ "ACK 号 X = 收到了 X 号字节" → 是"X 之前的都收到了，从 X 开始还没收到"，差一个字节就会判错重传范围
7. ❌ "TCP 切段和 IP 分片是一回事" → 源头主动切 vs 中途被迫切；丢了一段补一段，丢了一片全重来
8. ❌ "序号永远不会重复" → 32 位约 4.29 GB 就绕一圈，靠时间戳选项 + PAWS 防撞车
9. ❌ "SYN、FIN 是控制报文，不占序号" → 各占 1 个序号，所以第一个数据字节号 = SYN 号 + 1
10. ❌ "接收方收到的乱序段都丢了" → 不丢，存在接收缓冲区里，缺口一补上就一起交上去——这是"局部重传"能省成本的另一半原因

十一、下一步学什么

• ☑ 3.20 只对传输给应用程序的数据进行分发（UDP） ✅ 已完成 → 只对传输给应用程序的数据进行分发（UDP）：本节把切割与可靠性整体抽掉，看"只做分发"的传输层是什么样
• ☐ 3.21（按教材顺序） —— 报个标题接着走：按教材脉络，接下来大概率是 DNS 与域名（把名字换成 IP 地址）、DHCP 的进一步展开，或 第三章小结。等你报标题。

相关笔记

• 只对传输给应用程序的数据进行分发（UDP） —— 下一节：把本节这套"切段、编号、对账"整体抽掉之后，传输层剩下什么——答案是只剩"把数据交给正确的程序"
• 对应用程序的数据进行可靠传输（TCP） —— 上一节：本节的两个主角（序号、确认号）就是它从 TCP 头里挑出来的字段；"快速重传"的触发条件在本节看到了现场
• 接收和传输数据的规则（使用TCP/IP进行通信） —— 握手时"顺便交换"的第三件东西（MSS）藏在这里
• 收发数据时的规则（数据打包） —— MTU 1500 与 IP 分片的出处；本节把"TCP 切段 vs IP 分片"这对概念彻底分开了
• 数据的称谓（信息、数据段、数据包、数据帧） —— "数据段 Segment"就是本节一段段切出来的东西
• 根据端口号分配数据到应用程序（端口号、已知端口号） —— 每段除了序号，还带着源/目的端口，两样一起装在 TCP 头里
• 网络的网络（互联网） —— 千网互联导致各段链路 MTU 不同，这才是"MSS 要取小的那个"的原因
• 数据是否成功传输给接收方（ICMP） —— 对比：ICMP 出问题只能"报信"，TCP 靠本节这套序号/ACK 体系能"自己补"
• TCP通信 —— 你 write() 一个几百 KB 的数组时，底下正在按本节这套规则切成一段段发出去