UDP 为什么属于传输层？从封装过程讲清网络模型

UDP 是传输层协议。在 OSI 七层模型中位于第四层，在 TCP／IP 模型中也位于传输层。

如果只记住这个答案，很容易过一段时间又把 UDP 与 IP 混淆。更稳妥的理解方式，是看数据在网络中如何被逐层封装，以及每一层究竟解决什么问题。

网络通信要同时处理很多事情：应用如何组织数据、不同程序如何区分、目标主机在哪里、数据如何穿过网卡和物理线路。

如果把这些功能全部塞进一个协议，设计、实现和排错都会非常困难。分层模型把不同职责拆开，每一层只处理相对明确的问题。

在常见的 TCP／IP 模型中，可以分为四层：

UDP 位于应用层与网际层之间。它接收应用程序的数据，加上传输层首部，再交给 IP 协议。

假设应用程序准备向服务器发送一条数据。

第一步，应用层生成业务数据。

第二步，UDP 在数据前面添加首部，形成 UDP 数据报。首部中包含源端口、目标端口、数据报长度和校验和。

第三步，IP 协议在 UDP 数据报外添加 IP 首部，形成 IP 数据包。IP 首部中包含源 IP 地址和目标 IP 地址。

第四步，数据链路层继续封装，最终通过网线、光纤或无线信号发送出去。

整个过程可以写成：

应用数据 → UDP 数据报 → IP 数据包 → 数据帧

接收端会反向解封装。网卡收到数据帧后交给 IP 层，IP 层根据协议字段交给 UDP，UDP 再根据目标端口交给具体应用程序。

这就是 UDP 属于传输层的原因：它解决的是进程之间的数据交付，而不是主机寻址。

UDP 面向数据报，每次发送都对应一个独立消息。

假设发送端连续发送两条 UDP 数据：

接收端正常收到时，看到的仍然是两个独立数据报，而不是一段没有边界的 300 字节数据。

TCP 则不同。TCP 面向字节流，不保留应用程序每次写入时的消息边界。发送端写入两次，接收端可能一次读完，也可能分多次读取。因此，基于 TCP 的应用协议通常需要通过长度字段、分隔符或固定格式识别消息边界。

UDP 首部固定为 8 字节，只包括四个字段。它不需要保存连接状态，也没有 TCP 中用于可靠传输的序号、确认号和窗口字段。

因此，UDP 本身不处理：

这些能力的缺失让 UDP 协议本身更简单，但也意味着应用程序要自己承担相应风险。

如果数据可以丢，应用可以不做额外处理；如果关键数据不能丢，应用就要增加确认和重传；如果数据必须有序，还要设置序号并处理乱序。

TCP 希望为应用程序提供一条可靠、有序的字节流。网络中即使出现丢包和乱序，TCP 也会尽量在传输层处理。

UDP 只提供基本的数据报交付能力，不替应用决定什么数据值得等待、什么数据可以放弃。

所以，TCP 和 UDP 并不是简单的高级与低级关系，而是两种不同的职责划分方式。

"UDP 不可靠"只描述 UDP 本身不提供可靠性机制。

应用层完全可以在 UDP 之上增加：

QUIC 就建立在 UDP 之上，同时提供可靠传输、拥塞控制和安全连接。HTTP／3 使用 QUIC，也具备可靠的数据传输能力。

这类设计选择 UDP，不是为了放弃可靠性，而是为了绕开 TCP 固定的传输方式，在更高层重新组织连接和数据流。

UDP 常用于对实时性较敏感的业务，例如：

TCP 更常用于必须保证内容完整的场景，例如网页数据、文件传输、邮件和数据库连接。

但应用场景只是参考，不是绝对规则。语音业务也可能对关键控制消息做可靠传输，DNS 在某些情况下也会使用 TCP。

判断时应该回到业务要求：数据是否允许丢失，顺序是否重要，旧数据是否仍有价值，以及应用是否愿意自行实现可靠机制。

UDP 属于传输层，因为它负责通过端口实现应用进程之间的数据交付。它和 TCP 的根本区别，是对连接状态和可靠传输责任的划分不同，而不只是一个快、一个慢