这道题看上去只是考一个很小的知识点，但如果只是记住 `UDP 首部有四个字段`，考试时仍然很容易和 `TCP` 混在一起。更稳妥的办法，是把 `UDP` 的首部结构、每个字段存在的理由，以及 `UDP` 为什么主动放弃序列号这件事连在一起理解。

题目是这样的。

UDP 首部不包括（　　）字段。

A．目标端口  
B．序列号  
C．长度  
D．校验和

答案选 **B，序列号**。

这里最关键的一句话就是

> `UDP` 有目标端口、长度、校验和，但没有序列号。

`RFC 768` 对 `UDP` 的报文格式定义得非常简洁。一个标准 `UDP` 首部固定只有 **8 字节**，里面只有四个字段，每个字段恰好都是 **16 位**。它们分别是源端口 `Source Port`、目标端口 `Destination Port`、长度 `Length`、校验和 `Checksum`。协议首部里根本不存在 `Sequence Number`。[RFC Editor](https://www.rfc-editor.org/rfc/rfc768.html?utm_source=chatgpt.com)

把它写成最紧凑的结构，就是

```text
Source Port        16 bits
Destination Port   16 bits
Length             16 bits
Checksum           16 bits
```

四个字段加起来正好是

```text
16 + 16 + 16 + 16
= 64 bits
= 8 bytes
```

所以考试中看到 `UDP 首部长度是多少`，标准答案通常也是 **8 字节**。

这一点和 `TCP` 差别很大。`TCP` 为了完成可靠传输，要记录数据顺序、确认数据是否收到、判断哪些数据需要重传，所以它的首部里有一个明确的 **32 位序列号字段** `Sequence Number`。现代 `TCP` 标准 `RFC 9293` 依然明确规定，`Sequence Number` 是 `TCP` 首部的重要字段，它表示当前报文段中第一个数据字节对应的序列号，在 `SYN` 报文中又承担初始序列号 `ISN` 的作用。[RFC Editor](https://www.rfc-editor.org/rfc/rfc9293.html?utm_source=chatgpt.com)

所以只要记住这一层关系，这道题就已经没有悬念了。

`UDP` 没有序列号。

`TCP` 有序列号。

不过，真正值得弄明白的是另一个问题，为什么 `UDP` 明明知道网络中可能发生乱序和丢包，却还是没有设计序列号。

理解这一点以后，`UDP` 的首部结构基本不需要再死记。

`UDP` 全称是 `User Datagram Protocol`，通常翻译成用户数据报协议。它提供的是一种非常轻量的传输层数据报服务。应用程序交给 `UDP` 一块数据，`UDP` 加上一个很小的首部，再交给 `IP` 层发送。

它没有建立可靠字节流的任务。

所以 `UDP` 不负责确认某个数据报是不是成功到达，也不负责发现某个数据报丢失以后自动重新发送，更不负责保证两个数据报按照发送顺序交给应用程序，也不维护类似 `TCP` 那样复杂的发送窗口、接收窗口、累计确认、重传计时器和拥塞窗口。

既然这些事情都不归 `UDP` 负责，序列号自然就没有必要成为 `UDP` 协议本身的一部分。

这其实体现了一种非常典型的计算机系统设计思想，协议不一定要替上层解决所有问题，而是只解决自己承诺解决的问题。

`UDP` 做出的承诺非常少。

它大致负责把一段应用数据封装成数据报，通过端口号交给正确的进程，并提供一定程度的差错检测。

至于数据报有没有丢，有没有重复，有没有乱序，应用程序自己决定怎样处理。

正因为责任范围很小，`UDP` 才能拥有一个只有 8 字节的固定首部。

看看第一个字段，源端口 `Source Port`。

端口号的作用，并不是定位网络上的哪一台计算机。定位计算机主要依赖网络层的 `IP 地址`，端口号负责进一步区分计算机内部的应用程序或者通信端点。

一台服务器可以同时运行 `DNS` 服务、Web 服务、邮件服务以及各种内部服务。所有这些程序可能共用同一个服务器 `IP 地址`，仅靠 `IP 地址` 无法判断一个数据报究竟应该交给哪个程序。

端口号正是为了解决这个问题。

客户端发送 `UDP` 数据报时，源端口通常代表客户端当前使用的通信端点。服务器回包时，就可以把目的端口填写成这个源端口，让操作系统把返回数据交回正确的套接字。

源端口占 16 位，因此端口号空间从 0 延伸到 65535。

再看目标端口 `Destination Port`。

这是本题 A 选项中的字段，也是明确存在于 `UDP` 首部中的字段。

目标端口告诉接收方操作系统，这个 `UDP` 数据报应该交给哪个服务或者套接字。

一个非常真实的互联网案例就是 `DNS`。

传统 `DNS` 查询大量使用 `UDP`。`IANA` 当前的服务名称与端口号注册表仍然登记 `domain` 服务使用端口 **53**，并同时登记了 `UDP 53` 与 `TCP 53`。[IANA](https://www.iana.org/assignments/service-names-port-numbers?search=53+domain\&utm_source=chatgpt.com)

当操作系统或者应用程序向某台 `DNS` 服务器发起传统的 `UDP DNS` 查询时，外层 `UDP` 首部中的目标端口通常就是

```text
53
```

假设某台计算机临时选择源端口 53128，向 `DNS` 服务器发送查询，在传输层看到的逻辑关系大致就是

```text
客户端

Source Port
53128

Destination Port
53
```

服务器返回响应时，这两个角色会反过来。

```text
服务器

Source Port
53

Destination Port
53128
```

由此也可以看到，端口号解决的是进程到进程的交付问题，而不是数据排序问题。

因此题目里的 A `目标端口` 必然属于 `UDP` 首部。

接着看 C 选项，长度 `Length`。

这个字段同样真实存在，而且非常容易考。

`UDP Length` 是一个 16 位字段，用于表示整个 `UDP` 数据报的长度，也就是

```text
UDP Length
=
UDP Header
+
UDP Data
```

这里有一个考试中很重要的小细节。

长度字段不是只计算数据，也不是只计算首部，而是把 **8 字节 UDP 首部和后面的应用层数据一起计算进去**。

假设应用程序交给 `UDP` 的数据长度是 100 字节，那么

```text
UDP 首部
8 字节

应用数据
100 字节

UDP Length
108 字节
```

如果应用层没有任何数据，仅仅存在一个空的 `UDP` 数据报，那么长度字段最小也是

```text
8
```

因为 `UDP` 自己的首部就已经占了 8 字节。

`RFC 768` 对这一点写得非常明确，`Length` 表示整个用户数据报的字节数量，包括首部和数据，因此最小值为 8。[RFC Editor](https://www.rfc-editor.org/rfc/rfc768.html?utm_source=chatgpt.com)

所以看到考试题问

`UDP 长度字段是否包括 UDP 首部`

答案是包括。

问

`UDP Length 最小是多少`

答案是 8 字节。

问

`UDP 首部固定多长`

也是 8 字节。

这几个知识点其实来自同一张协议结构图。

D 选项中的校验和 `Checksum` 也确实存在。

它占 16 位。

这里有一个很有意思的地方，`UDP Checksum` 并不只是简单地把 `UDP` 首部和数据相加计算。它在计算时还会引入一个逻辑上的 `Pseudo Header`，也就是伪首部。

这个伪首部不是真的插进 `UDP` 数据报前面发送出去，它只是参与校验和计算。

以经典 `IPv4 UDP` 为例，参与校验的内容涉及源 `IP 地址`、目标 `IP 地址`、协议号、`UDP` 长度、`UDP` 首部以及 `UDP` 数据。

这里很容易产生一个疑问。

既然源 `IP 地址` 和目标 `IP 地址` 属于 `IP` 首部，为什么 `UDP` 的校验还要把它们考虑进去。

原因在于传输层不仅关心数据有没有发生比特错误，也希望降低数据被错误交付到不正确网络端点的风险。把源地址、目标地址和协议号等网络层信息纳入计算以后，校验范围就和通信双方的身份信息产生了联系。

因此 `UDP Checksum` 和简单的数据区校验不是一回事。

在经典 `IPv4 UDP` 中，`RFC 768` 还允许发送方把校验和值设置为零来表示没有生成校验和。到了 `IPv6` 环境，规则发生了变化，普通 `UDP over IPv6` 通常要求使用非零校验和，后来只有少数非常特殊的隧道化场景通过专门标准提供例外。

软考、计算机网络基础考试或者常规认证考试如果只是问 `UDP 首部有哪些字段`，不需要进入这些例外规则，只要牢牢记住 `Checksum` 是标准 `UDP` 首部四个字段之一即可。

这样一来，题目的 A、C、D 已经全部确认。

真正剩下的 B `序列号`，属于典型的干扰项。

这个干扰项之所以很有迷惑性，是因为日常网络通信里经常会听到数据包顺序、乱序、丢包、重传这些概念，于是很容易产生一个直觉，既然网络可能乱序，传输协议应该都要带序号。

现实并不是这样。

传输层存在不同的服务模型。

`TCP` 选择提供可靠、有序的字节流服务，因此它必须知道一段数据在整个字节流中的位置。

于是 `TCP` 要维护序列号。

假设某个 `TCP` 发送方发送了 1000 字节数据，某个报文段的起始序列号为 5001，那么接收方就能根据序列号判断数据属于字节流的哪个位置。如果某一段数据没有到达，而后面的数据先到了，接收方也有机会判断中间存在缺口。

`TCP` 还存在确认号 `Acknowledgment Number`。

序列号和确认号结合以后，才能构造可靠传输机制。

发送方知道自己发到了哪里。

接收方知道自己收到了哪里。

接收方还能告诉发送方下一段希望看到哪个序列号。

超时重传、快速重传、滑动窗口、乱序重组等机制，也都围绕这个序列空间运行。

`UDP` 根本不维护这样的字节流状态。

两个连续发送的 `UDP` 数据报，在协议看来就是两个彼此独立的数据报。

发送

```text
Datagram A
```

紧接着发送

```text
Datagram B
```

网络中完全可能出现 `B` 比 `A` 更早到达的情况。

`UDP` 自己不会把 `B` 暂存起来等待 `A`。

它也不会查看一个 `UDP Sequence Number` 再恢复顺序，因为根本没有这个字段。

接收应用程序收到什么，就由应用层根据自己的协议逻辑处理什么。

这也是很多实时系统愿意使用 `UDP` 的原因之一。

实时语音是一个很典型的场景。

语音数据存在很强的时间属性。

一小段语音如果因为网络拥塞而晚到了几百毫秒甚至几秒，它的价值可能已经明显下降。对实时通话而言，把旧数据不断重传并不一定比直接跳过它更好。

很多实时媒体协议因此会选择在 `UDP` 上构建自己的时序机制。

经典的 `RTP` 就是一个很有代表性的例子。`RTP` 通常运行在 `UDP` 之上，但 `RTP` 自己定义了序列号和时间戳。

这里非常容易成为网络考试中的认知陷阱。

看到基于 `UDP` 的实时音视频里出现了序列号，并不能据此认为 `UDP` 有序列号。

那个序列号属于上层协议。

可以把整个协议栈想象成

```text
应用或媒体协议
RTP

传输层
UDP

网络层
IP
```

`RTP` 可以拥有自己的 `Sequence Number`。

下面的 `UDP` 仍然没有 `Sequence Number`。

这恰恰体现了分层协议设计的力量。底层没有提供某种能力，并不妨碍上层根据自己的业务需求补上这种能力。

现代互联网里还有一个更有代表性的案例，`QUIC`。

`QUIC` 运行在 `UDP` 之上，而 `QUIC` 自己实现可靠传输、数据流、多路复用、丢包检测和拥塞控制等机制。`HTTP/3` 就建立在 `QUIC` 上。

因此看到一个应用建立在 `UDP` 上，并不能简单理解成整个通信一定是不可靠的。

更准确的理解应该是，**`UDP` 自己不提供可靠传输，但使用 `UDP` 的上层协议完全可以自己实现可靠性。**

这也是理解这道选择题很关键的一步。

协议功能要看它属于哪一层。

不能因为整个应用最终实现了可靠通信，就把那些可靠性字段算进 `UDP` 首部。

也不能因为某个实时媒体协议带有序列号，就认为 `UDP` 本身带序列号。

回到 `TCP` 和 `UDP` 的结构差异，会更加清晰。

`UDP` 的任务范围很窄，因此只需要解决几个核心问题。

端口告诉操作系统数据属于哪个通信端点。

长度告诉接收端当前 `UDP` 数据报有多大。

校验和用于进行差错检测。

这几个任务都不要求维护报文之间的连续状态。

序列号却完全不同。

序列号的价值只有放进连续通信状态中才能充分体现。发送方和接收方必须共同维护一个序列空间，才能知道某一块数据处在整体传输过程的哪个位置。

一旦加入这种机制，协议就不再只是简单的数据报转发。

它还要考虑确认。

还要考虑丢失。

还要考虑重复。

还要考虑乱序。

还要考虑重传。

还要考虑发送窗口和接收窗口。

还要考虑连接生命周期。

`TCP` 正是沿着这条道路设计的。

所以标准 `TCP` 首部至少 20 字节，而 `UDP` 首部固定只有 8 字节。

二者之间的差异不是简单的 `一个字段多，一个字段少`，而是两套传输服务思想的差异。

`TCP` 更像一条持续存在的数据管道。

应用程序向里面写入连续字节，`TCP` 负责尽可能可靠、有序地把字节送到另一端。

`UDP` 更像一次次独立投递的数据报。

应用程序每交给它一个消息，它就尽力发出一个消息。

前一个数据报和后一个数据报之间，`UDP` 不建立类似 `TCP` 字节流那样的逻辑连续关系。

正因为没有这种连续关系，`UDP` 才不需要利用序列号维护数据位置。

这里还可以顺带解决另一个经常出现的误区。

有人会认为

`UDP 没有序列号，所以 UDP 数据报内部的数据字节也完全没有顺序`

这种理解并不准确。

一个单独的 `UDP` 数据报内部仍然是一段确定的字节序列。

假设应用程序发送

```text
ABCDEF
```

如果这个数据报成功并完整地到达应用程序，正常情况下不会莫名其妙变成

```text
FEDCBA
```

所谓 `UDP 不保证顺序`，主要讨论的是多个独立数据报之间的到达顺序。

例如应用程序依次发送三个独立数据报

```text
A
B
C
```

接收方可能观察到

```text
A
C
B
```

也可能只收到

```text
A
C
```

甚至某个数据报因为应用层逻辑、网络环境或者缓冲区问题没有成功交付。

`UDP` 协议自身没有一套类似 `TCP Sequence Number` 的机制帮助恢复成原来的发送顺序。

这一点在学习计算机网络时很重要，因为 `报文内部字节顺序` 和 `多个报文的到达顺序` 是两个完全不同的概念。

再从抓包角度观察，会更加直观。

使用 `Wireshark` 捕获一个普通 `UDP` 报文，把 `User Datagram Protocol` 展开，可以看到类似

```text
Source Port
Destination Port
Length
Checksum
```

继续展开应用层数据，可能看到 `DNS`、`DHCP`、`RTP` 或其他协议的内容。

但在 `UDP` 那一层不会看到标准的

```text
Sequence Number
Acknowledgment Number
SYN
ACK
FIN
Window
```

这些字段主要属于 `TCP` 的可靠连接机制。

如果抓一个 `TCP` 报文，情况就完全不同。

`Wireshark` 的 `Transmission Control Protocol` 部分会显示源端口、目标端口、序列号、确认号、首部长度、各种控制标志、窗口大小、校验和等信息。

只要真正观察过两种报文的抓包结构，这类选择题几乎不再需要记忆。

考试里还很喜欢利用协议之间的字段差异设计干扰项。

看到 `序列号`，应该优先联想到 `TCP` 的可靠、有序传输。

看到 `确认号`，也应该优先联想到 `TCP`。

看到 `SYN`、`ACK`、`FIN`、`RST`，仍然是 `TCP`。

看到 `窗口大小`，也是典型的 `TCP` 首部内容。

反过来看 `UDP`，结构非常克制。

源端口。

目标端口。

长度。

校验和。

只有四个。

因此可以形成一个非常好用的记忆图景。

`UDP` 首部就是四个并排的 16 位格子。

```text
源端口      16 位
目标端口    16 位
长度        16 位
校验和      16 位
```

四个 16 位就是 64 位。

64 位除以 8，就是 8 字节。

这个数字关系一旦建立起来，字段和首部长度就一起记住了。

再看题目本身。

A `目标端口`

存在，因为接收方必须知道数据应该交给哪个应用端点。

B `序列号`

不存在，因为 `UDP` 不负责构建可靠、有序的数据流，也不维护 `TCP` 那样的序列空间。

C `长度`

存在，用于记录整个 `UDP` 数据报的长度，包括 8 字节首部和应用数据。

D `校验和`

存在，用于执行差错检测。

所以答案只能是

**B．序列号**

如果把这道题压缩成考场里十秒钟能够调用出来的一条记忆链，可以记成

```text
UDP
四字段
每个 16 位
总计 8 字节

源端口
目标端口
长度
校验和

没有序列号
没有确认号
没有窗口
没有 SYN ACK FIN
```

这里真正值得留下来的，并不是单独一个 `B`。

更重要的是建立一个协议设计模型。

`UDP` 是面向数据报的轻量传输协议，它没有承担可靠、有序传输职责，所以首部只保留完成基本进程寻址、长度描述和差错检测所需要的信息。

`TCP` 是面向连接的可靠字节流协议，需要追踪数据在连续字节流中的位置，因此引入 32 位序列号以及确认号、窗口、控制标志等一整套状态机制。

当脑中形成这幅结构图以后，再碰到 `UDP 是否包含序列号`、`UDP 首部长度`、`UDP Length 是否包含首部`、`TCP 为什么需要 Sequence Number`、`UDP 为什么可能乱序` 这类题，实际上都已经变成了同一个知识体系里的不同切面。

这道题的最终答案就是 **B，序列号**。

参考资料

`RFC 768，User Datagram Protocol`，RFC Editor，定义了 `UDP` 的四个首部字段以及 `Length`、`Checksum` 的计算规则。[RFC Editor](https://www.rfc-editor.org/rfc/rfc768.html?utm_source=chatgpt.com)

`RFC 9293，Transmission Control Protocol`，RFC Editor，定义了现代 `TCP` 的首部结构，其中包含 32 位 `Sequence Number` 与 32 位 `Acknowledgment Number`。[RFC Editor](https://www.rfc-editor.org/rfc/rfc9293.html?utm_source=chatgpt.com)

`IANA Service Name and Transport Protocol Port Number Registry`，可查到 `domain` 服务登记在 `TCP 53` 与 `UDP 53`。[IANA](https://www.iana.org/assignments/service-names-port-numbers?search=53+domain\&utm_source=chatgpt.com)

这道题看上去只是考一个很小的知识点，但如果只是记住 UDP 首部有四个字段，考试时仍然很容易和 TCP 混在一起。更稳妥的办法，是把 UDP 的首部结构、每个字段存在的理由，以及 UDP 为什么主动放弃序列号这件事连在一起理解。

UDP 首部为什么没有序列号，从一道选择题看懂 UDP 与 TCP 的设计分野

紫薇堂堂主

人工智能

UDP首部固定8字节，仅含源端口、目标端口、长度和校验和四个16位字段，无序列号。TCP因需可靠传输才设32位序列号。理解UDP为何放弃序列号，即不维护报文间连续状态，考试即可轻松判断答案为B。

实时音视频

数据管道

代码解释

服务器

数据流

DHCP

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

UDP 首部为什么没有序列号，从一道选择题看懂 UDP 与 TCP 的设计分野-腾讯云开发者社区-腾讯云

UDP 首部为什么没有序列号，从一道选择题看懂 UDP 与 TCP 的设计分野

UDP 首部为什么没有序列号，从一道选择题看懂 UDP 与 TCP 的设计分野

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐