🌐 UDP 为什么大小不能超过 64KB？TCP 有这个限制吗？
在进行网络编程或者调试网络协议时，我们常常会看到一个说法：
"UDP 最大只能发送 64KB 数据。"
这到底是怎么回事？这 64KB 是怎么来的？TCP 又是否也有这种限制？
今天我们就系统地聊聊这个话题，深入分析 UDP 最大传输单元的限制原理 ，并和 TCP 的传输方式进行对比。
🧱 一、UDP 协议结构决定了其"上限"
UDP（User Datagram Protocol）是一种无连接、面向报文的协议，它结构简单，效率高，非常适合低延迟、不需要可靠性的场景。
📦 UDP 报文格式：
| Source Port (2 bytes) | Destination Port (2 bytes) |
| Length (2 bytes) | Checksum (2 bytes) |
| Data ... |注意其中的 Length 字段为 2 字节（16 位），表示整个 UDP 报文的长度（包括头部和数据）。所以：
- UDP 报文最大长度为：2¹⁶ = 65536 字节（即 64KB）
- 减去 UDP 头部的 8 字节，实际可传输数据最大为：65528 字节
✅ 这意味着 64KB 是协议结构本身的"硬性上限"，不是操作系统、网络环境或语言库设置的，而是 UDP 协议规范规定的最大报文长度。
🌐 二、IP 层的限制也在"背后捣乱"
UDP 本身不能分片，它是依赖下层的 IP 协议来传输的。而 IP 层也有自己的最大限制。
IPv4 的 Total Length 字段：
- IP 报文结构中也有一个 Total Length 字段 ，同样是 2 字节，最大为 65535 字节
- 所以任何经 IP 传输的包，最多只能是 65535 字节（包括 IP 头）
📌 一旦 UDP 报文 > MTU，会触发"IP 分片"
- MTU（Maximum Transmission Unit） 是指网络层一次最多能传输的 IP 数据包大小（以太网一般是 1500 字节）。
- 如果你的 UDP 报文大于 MTU，IP 会进行 分片，将其拆成多个片段传输。
但问题是：
❗ 如果 UDP 报文被 IP 层分片后，只要有一个片段丢失，整个报文就无法还原！
⚠️ 三、为什么 UDP 虽然支持 64KB，却不推荐这么用？
虽然理论上 UDP 支持 64KB，但实际使用中我们通常建议：
UDP 报文长度应控制在 MTU（1500 字节）以内，甚至更低，比如 1200 字节左右。
原因很简单：
- IP 分片极其脆弱，不支持丢片重传
- UDP 本身就没有重传机制
- 如果丢了一个片段，整个大报文就失败了
所以在实际项目中，如 RTP、VoIP、游戏、IoT等，UDP 报文通常被设计得非常小，以规避分片问题。
🔁 四、那 TCP 呢？它有这个限制吗？
✅ TCP 同样基于 IP 传输，也受 MTU 限制
但和 UDP 不同的是：
| 特性 | UDP | TCP |
|---|---|---|
| 报文处理方式 | 一次性发送完整报文 | 拆分为多个 Segment 发送 |
| 是否分片 | IP 层分片，风险大 | TCP 层分段，避免 IP 分片 |
| 是否有重传机制 | 无 | 有 |
✅ TCP 使用 MSS（Maximum Segment Size） 控制发送段大小
- TCP 在三次握手中会协商 MSS（一般为 1460 字节）
- TCP 会主动分段（Segmentation），每段不超过 MSS
- 这样可以避免 IP 层进行分片，提升传输的稳定性和效率
- 应用层可以持续写入大量数据，TCP 会自动拆成多个包发送出去
所以：
TCP 没有"单个数据不能超过 64KB"的限制，传输是连续的流（Stream），可传任意多数据。
✅ 总结一下
| 特性 | UDP | TCP |
|---|---|---|
| 最大报文长度 | 65535 字节（含头部） | 无限制（持续流式传输） |
| 处理超大数据方式 | IP 层分片，易丢包 | TCP 分段，避免 IP 分片 |
| 是否推荐发送大包 | ❌ 不推荐，极易出错 | ✅ 可以持续写入，系统自动处理分段 |
| 重传机制 | 无 | 有 |
| 场景 | 音视频、实时通信、游戏、IoT 等 | 文件传输、网页、API、可靠通道等 |
🧩 最后的建议
如果你在开发中使用 UDP：
- 请注意单个 UDP 报文大小
- 尽量控制在 MTU 以下
- 如果真的要发送大数据，考虑用 TCP 或实现自己的分片机制（如 RTP）