UDP 长度是这份用户数据报的八位组数，含 UDP 头和数据，最小是 8。它不计 IP 头。IP 传输载荷更长时，多出来的一段在 RFC 9868 里叫做余量区。IPv6 上只有头加数据超过 65535，RFC 2675 才要求把该字段写成 0。
长度含头，最小是 8
一个可独立引用的定义句：UDP 长度是这份用户数据报的八位组数，含这个头和数据。因此长度的最小值是 8（RFC 768）。
RFC 768 是 1980 年 8 月的 Internet Standard，STD 6。它没有 BCP 14 的用词条款。上面这句是字段定义，不是后来加上的「必须」。图里在数据之前有源端口、目的端口、长度、校验和四栏。原文没有另印「头长等于 8」；它印出的是最小值 8。
源端口不用时填 0。目的端口的含义要连同目的地址一起看。这两栏都是 16 位，但不进入本文的长度规则。校验和盖住伪首部、UDP 头和数据；伪首部里也有一份 UDP 长度。全 0 校验和表示什么，见 UDP 校验和。本文不重述。
2026 年 10 月 25 日打开的 RFC 768 勘误页 写着没有匹配的勘误。同日的 RFC 编辑器元数据把更新者列为 RFC 9868。下一节只采用已读过的那些节。
它可以短于 IP 给出的空间
一个可独立引用的定义句：UDP 长度含 UDP 头。IP 头所暗示的传输载荷更长时，多出来的一段是余量区，RFC 9868 用它放置 UDP 选项。多数情况下两者指到同一处，这不是 RFC 768 的一项要求（RFC 9868 第 7 节）。
RFC 9868 是 2025 年 10 月的 Standards Track，更新 RFC 768。关键词按 RFC 2119 和 RFC 8174 解释，只在全大写时才算。行首的 >> 标出使用这些词的句子。
第 7 节给出长度的上界。协议字段是 17 时：
| 外层 | 上界 |
|---|---|
| IPv4 | UDP 长度 ≤ IPv4 总长度 − IHL × 4。前面若还有垫片头，再减去那些头的长度 |
| IPv6 | UDP 长度 ≤ IPv6 载荷长度 − 各扩展头长度之和 |
IHL 以 4 字节为单位，这句引自 RFC 9868 对 RFC 791 的转述。本文不另写 IPv4 头长度。协议字段不是 17 时，例如中间还有 IPsec 或 IPComp，第 7 节把这写成例外，上表的前提不成立。本文不展开那两份封装怎样改写协议字段。
第 8 节有一条带 >> 的必须：UDP 长度必须至少等于 UDP 头（8），并且不得大于 IP 传输载荷。落在这个范围外的数据报必须当作无效而静默丢弃，并记入日志。日志应当限速。第 21 节列出的更新只有两条：把 UDP 长度之外、IP 长度之内的区域定义为余量区；以及扩展 UDP 的编程接口。上一段的「必须丢弃」印在第 8 节，没有再出现在第 21 节的条目里。
第 18 节写：UDP 长度与 IP 传输载荷长度不一致，一直是允许的，并引用 RFC 768。第 22 节又写：这种关系在 RFC 768 和主机要求 RFC 1122 里都没有明确约束。两句都在 RFC 9868 里。RFC 768 正文没有比较这两个长度。2026 年 10 月 25 日没有重读 RFC 1122，因此不复述那一份的句子。
图 3 把 UDP 长度画成盖住 UDP 头和用户数据，余量区在这个长度之后、IP 传输载荷之内。第 17 节写明，长度偏移之后的数据默认不交给应用，只在 UDP 传输层里解释。本文没有读完各选项种类，因此不给 Kind、AUTH 或分片选项的格式。已验证勘误 8834 改的是第 14 节过长选项如何处理，并指向第 10 节；它不改第 8 节的长度范围。勘误 8708 标为 Held for Document Update，改的是第 11.4 节的一张图。本文不采用尚未写入正文的那一处。
写成 0 时，实际长度要另算
一个可独立引用的定义句：UDP 头加数据大于 65535 八位组时，才把 UDP 长度设为 0，接收方再从 IPv6 巨型载荷长度减去 IPv6 头和 UDP 头之间的扩展头，得到实际长度。在这份修改之前，0 不是合法值，因为长度含头，最小是 8（RFC 2675 第 4 节）。
RFC 2675 是 1999 年 8 月的 Proposed Standard，取代 RFC 2147。正文没有 RFC 2119 的关键词条款。下面的「必须」对应它的小写 must。巨型载荷选项的类型是十六进制 C2，选项数据长度是 4，放在紧跟 IPv6 头的逐跳选项头里。选项里的 32 位长度不含 IPv6 头，但含逐跳选项头和其他扩展头，并且必须大于 65535。IPv6 头里的载荷长度在带这个选项时必须为 0。它不得与分片头同时出现。第 2 节和第 3 节是这些句子的出处。
发送时还有一句「当且仅当」。校验和使用实际的头加数据长度，不用 0。接收时也是当且仅当长度为 0，才做上面的减法。意外情形是长度为 0 但没有巨型载荷选项：这时改用 IPv6 头里的载荷长度来做同一减法。校验和仍然用算出来的长度，不用 0。
第 4 节开头还有一句较松的话：让接收方从 IPv6 载荷长度推出实际 UDP 包长。勘误 2175 的状态是 Held for Document Update，建议把这句改成从巨型载荷长度推出，理由是 IPv6 载荷长度此时为 0。编号后的接收规则已经分开写了巨型载荷长度和意外情形。本文不把这条尚未入正文的勘误写成现行句子。
RFC 9868 第 22 节写明：UDP 长度为 0 时不能支持 UDP 选项。它把这写成用于、但不限于 IPv6 巨型报文，并写明 RFC 2675 虽是 Standard，却没有 update RFC 768。因此第 8 节「至少为 8」没有在本文里被读成「已经废止长度为 0」。
2026 年 10 月 25 日在下载的 RFC 8200 纯文本里没有检索到 jumbo 或 2675。同日的元数据也没有把 RFC 2675 标成已被取代。本文不据此宣称 RFC 8200 改写或保留了巨型载荷，只说明那份文本里没有这两个词。TCP 没有自己的长度字段，第 5 节是另一件事。本文没有复述。
IPv6 扩展头 里的 Hdr Ext Len 不含前 8 字节，而且只描述某一段扩展头。IPv6 载荷长度则含基本头之后的全部字节。UDP 长度只含 UDP 头和数据。三者不是同一个数。
隧道外层仍用这一个字段
端口 4500 上，IKE 以四个 0 开头，ESP 直接从 SPI 开始。那四个 0 在 UDP 载荷里，见 非 ESP 标记。UDP 长度含数据，因此这四个 0 在 UDP 长度之内。这是两句的对照，不是第三份 RFC 里印出的「长度含标记」。IKE 头自己的长度字段不含这四个 0，见 IKE 头。
外层用 UDP 还是 TCP，见 VPN 用 TCP 还是 UDP。TCP 头没有这个 16 位长度。IP 层把一份 UDP 再拆开，是另一层的事，见 IP 分片。分片不改写「UDP 长度含头」这句定义。
本文不提供构造余量区、把长度写成 0，或改写外层长度的步骤。
现象对照
| 现象 | 更可能先看什么 |
|---|---|
| 长度为 8 | 只有 UDP 头，用户数据长度为 0。这仍含头 |
| 长度大于 8，且与 IP 传输载荷对齐 | 没有余量区。RFC 9868 写明这是常见情况，不是 RFC 768 的要求 |
| 长度小于 IP 传输载荷，且至少为 8 | 余量区。默认不交给应用 |
| 长度小于 8，或大于 IP 传输载荷 | RFC 9868 第 8 节：必须静默丢弃并记日志 |
| IPv6 上长度为 0 | RFC 2675 的发送条件是头加数据超过 65535。接收方还要处理没有巨型选项的意外情形 |
| 长度为 0 仍想读 UDP 选项 | RFC 9868 第 22 节：这种包不能支持 UDP 选项 |
核对清单
- 长度含头，最小是 8：RFC 768 没有另印「头长等于 8」。0 在这份修改之前不合法；
- 余量区在长度之后：定义和编程接口的更新在 RFC 9868 第 21 节。至少为 8、否则丢弃，印在第 8 节。第 18 节和第 22 节对「768 有没有写明不一致」用词不同；
- 写成 0 要另算：发送端当且仅当超过 65535。校验和使用实际长度。勘误 2175 尚未入正文；
- 至少为 8 没有在本文里废止长度 0：RFC 9868 第 22 节把长度 0 保留为不能加选项的情形；
- 四个 0 在 UDP 长度里，不在 IKE 长度里。选项种类、RFC 1122 和 RFC 8200 的巨型载荷句子没有读完。