UDP学习笔记（四）UDP 为什么大小不能超过 64KB？

🌐 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、可靠通道等