3. UDP 数据包边界：消息边界特性与流式数据的区别
好，咱们进入第三章。这一章我要跟你聊一个非常核心的概念——UDP 的数据包边界。说白了，就是 UDP 怎么把一条条消息“切”开，而 TCP 又是怎么把数据“揉”成一团的。
我记得刚入行那会儿，有个同事把 TCP 的代码直接改成 UDP，结果发现客户端收到的数据全乱了。他跑来问我：“我发的明明是两条消息，怎么收端只读到一条？” 嗯，这就是没搞懂消息边界。
3.1 什么是消息边界？
消息边界，就是数据在传输时，接收方能明确知道“这条消息从哪开始、到哪结束”。
你想想看，两个人聊天，你说一句“今天天气不错”，对方知道这是一句完整的话。但如果把这句话拆成“今天”、“天气”、“不错”三个词混在一起说，对方就得猜你到底想表达什么。
网络传输也是这个道理。UDP 和 TCP 处理边界的方式完全不同。
核心区别一句话：
- UDP：保留消息边界。你发一次
sendto()，对方一次recvfrom()就能拿到完整的一条消息。 - TCP：不保留消息边界。你发两次
send()，对方可能一次recv()就全读走了，也可能分三次才能读完。
3.2 UDP 的数据报模型
UDP 是“数据报”协议。什么叫数据报？就是每个包都是独立、自包含的。我发一个 100 字节的包，接收端要么完整收到这 100 字节，要么就丢包了——不存在收到 50 字节的情况。
我在项目中遇到过一个问题：有个同事用 UDP 传文件，每次发 64KB。结果发现对方经常收不全。查了半天，原来是 MTU 限制。UDP 虽然保留边界，但数据报大小不能超过底层网络的 MTU（通常是 1500 字节）。超过的话，IP 层会帮你分片，但分片后的重组一旦丢一个片，整个数据报就废了。
避坑指南：
我曾经在一个视频流项目中，直接把一帧 60KB 的数据塞进 UDP 发送。结果丢包率飙升到 30%。后来改成每帧分片成多个 1400 字节的 UDP 包，丢包率直接降到 1% 以下。
记住：UDP 单次发送不要超过 1472 字节（1500 - 20 IP头 - 8 UDP头），这是最安全的做法。
3.3 TCP 的流式模型
TCP 是“流”协议。它不关心你发了几条消息，它只关心字节的顺序。你发“Hello”和“World”，TCP 可能把它们变成“HelloWorld”一股脑推给接收端。
为什么会这样？因为 TCP 是面向连接的、可靠的字节流。它内部有缓冲区，有滑动窗口，有拥塞控制。这些机制决定了它必须把数据当成一个连续的流来处理。
我刚开始做网络编程时，写过一段代码：
// 发送端
send(sock, "msg1", 4, 0);
send(sock, "msg2", 4, 0);
// 接收端
char buf[1024];
int n = recv(sock, buf, 1024, 0);
// 猜猜 n 是多少？可能是 8，也可能是 4，甚至可能是 2
这就是 TCP 粘包。你没法保证一次 recv 正好拿到一条完整的消息。
3.4 对比表格：UDP vs TCP 边界特性
| 特性 | UDP（数据报） | TCP（流） |
|---|---|---|
| 消息边界 | 保留，一次 sendto 对应一次 recvfrom | 不保留，字节流无边界 |
| 数据完整性 | 可能丢包、乱序 | 保证有序、不丢、不重 |
| 发送粒度 | 数据报，最大 65535 字节（含头部） | 无限制，流式发送 |
| 粘包问题 | 不存在粘包，但存在丢包和分片 | 存在粘包，需要应用层拆包 |
| 典型场景 | DNS、DHCP、视频通话、游戏 | HTTP、FTP、数据库连接 |
3.5 为什么 UDP 没有粘包问题？
这个问题我经常被问到。答案其实很简单：UDP 的 API 设计就是“一次发送，一次接收”。
你调用 sendto() 时，内核会把你的数据封装成一个独立的 UDP 数据报。接收端调用 recvfrom() 时，内核会把一个完整的数据报交给你。如果接收缓冲区里有多个数据报，recvfrom() 也只返回其中一个。
但注意：这不代表 UDP 就完美了。它有自己的麻烦——
- 丢包：数据报可能在路上就消失了，应用层收不到任何通知。
- 乱序：先发的包可能后到，后发的包可能先到。
- 重复：极少数情况下，同一个包可能被收到两次。
- 分片：超过 MTU 的包会被 IP 层分片，任何一个分片丢失都会导致整个包作废。
我的建议：
如果你用 UDP 传输结构化消息（比如 JSON、Protobuf），每条消息最好控制在 1400 字节以内。这样既能避免 IP 分片，又能充分利用 UDP 的边界特性。我在做物联网网关时，所有设备上报的数据都按这个规则打包，从来没出过边界问题。
3.6 核心逻辑图：UDP 数据报 vs TCP 字节流
下面这张图展示了两种协议在传输层处理数据的差异。你可以看到 UDP 保持了消息的独立边界，而 TCP 把消息合并成了一个连续的流。
3.7 实际开发中的选择
了解了这些区别之后，你可能会问：那我到底该用 UDP 还是 TCP？
我的经验是：
- 需要消息边界、能容忍少量丢包 → 用 UDP。比如实时音视频、游戏状态同步。
- 需要可靠传输、不关心边界 → 用 TCP。比如文件下载、网页请求。
- 既需要边界又需要可靠 → 在 UDP 之上自己实现确认重传机制，或者直接用 QUIC。
嗯，这一章的内容就到这里。UDP 的边界特性既是它的优势，也是它的局限。理解了这一点，后面我们讲粘包拆包实战时，你就能明白为什么 UDP 不需要拆包，而 TCP 需要了。