为什么 UDP 头只有 8 个字节 （二）

数据传输

RFC768 在介绍 UDP 协议时强调 UDP 协议假设底层会使用 IP 协议。IP 协议是 TCP/IP 协议栈的核心成员，它不保证端到端数据的可靠性和顺序，也不包含流控制等机制，其作用就是从来源向目的地传输数据包⁶。在本文中，我们只需要知道 IP 协议头中包含源 IP 和目的 IP，就不展开介绍 IP 协议的具体实现了，感兴趣的读者可以阅读 RFC791 和相关文档了解更多的内容。

『UDP 协议只能尽力送达数据』这一说法『继承』自 UDP 的下层协议，也就是 IP 协议。只包含了两个端口号的 UDP 协议本身是无法提供路由和寻址功能的，它还是需要下层的协议来解决这个问题。

上面提到的这种各司其职的设计源于网络通讯协议的分层结构。抽象是计算机科学中的基础概念，通过定义良好的接口、构建抽象层，我们可以减少同时需要关注的问题，让每一层都能聚焦到需要处理的问题上。TCP/IP 协议簇将通信过程分成了四个抽象层，分别是：链接层（Link）、网络层（Internet）、传输层（Transport）和应用层（Application）⁷。

图 2 - TCP/IP 协议簇的抽象层

不同的抽象层有着完全不同的功能，我们来看一下网络层和传输层的职责。TCP 和 UDP 等传输层协议的主要作用是为应用建立基本的数据管道，为特定任务提供数据传输的功能；而 IP 等网络层协议的主要作用是寻址和路由，它能够帮助我们将数据发送目标的主机。

简单总结一下，UDP 协议下层的 IP 协议实现数据包的传输，虽然 UDP 属于传输层协议，但是其本身没有提供主机到主机的数据传输能力。

进程定位

在软件层面上，端口是用来表示特定进程或者特定类型网络服务的逻辑概念⁸，计算机硬件中也有端口的概念，但是这里说的端口是没有实体的。当主机接收到 IP 数据包时会根据协议号交给不同的模块处理，TCP 和 UDP 协议会根据端口号确定送给对应的进程处理。

虽然 TCP 和 UDP 协议中都有端口号这一概念，但是因为它们两者的端口不在一个命名空间下（TCP 和 UDP 是两套命名空间），所以 TCP 和 UDP 可以同时使用相同的端口号，例如：53/TCP 和 53/UDP，这两个端口号后的服务都处理 DNS 请求。从这一点来看，只有通过 IP 地址、传输层协议和端口号三者才能在网络上定位到具体的服务，只凭借 IP 地址和端口号是不可行的。

图 3 - TCP 和 UDP 的重复端口号

UDP 协议中的两个端口号占据了 UDP 协议头的一半开销，这从侧面表明了端口号在 UDP 协议的重要地位和 UDP 协议的主要功能。接收 IP 数据包的主机可以使用目的端口号找到特定的进程，该进程也可以使用数据包中的源端口号向发送方回复数据。

图 4 - 端口号和进程

TCP 和 UDP 的端口号是主机和进程的中间层，进程和端口号既可以是一对一的关系，也可以是一对多的关系，端口号的引入可以让同一个主机上的多个进程对外提供服务，也可以让一个进程对外提供多个服务。有了端口号，想要访问主机服务的请求也不需要使用进程标识符等方式定位提供服务的具体进程。

总结

简单回答一下本文提出的问题：UDP 协议利用下层的 IP 协议提供基本的数据传输能力，它的作用就是引入端口号的概念让同一主机可以同时提供对外多个服务，由于不保证可靠性，所以协议本身只占用 8 个字节。

在理想情况下，我们可以在 IP 协议上构建新的传输层协议实现特定的需求，不过在实际操作中由于协议号的限制，新的传输层协议无法被大量部署的网络地址转换（Network address translation，NAT）⁹设备识别和支持，所以使用这种方式构建新的传输层协议在实践中难以落实。

注 1：协议号是 IP 首部中的一个字段，它表示当前报文数据区使用的协议，最常见的 TCP 和 UDP 协议的协议号分别是 6 和 17。

注 2：SCTP 协议¹⁰就是一个 RFC 标准中的传输层协议，但是 NAT 设备的兼容性问题会导致 SCTP 报文被丢弃。

由于 UDP 协议非常简单，很多新的传输层协议都会基于 UDP 实现，例如：Google 的 QUIC 协议¹¹。到最后，我们还是来看一些比较开放的相关问题，有兴趣的读者可以仔细思考一下下面的问题：

• UDP 协议中的长度和校验码可以被省略么？为什么？

• 除了 UDP 和 TCP 协议，其他基于 IP 的传输层协议有没有端口号的概念？

如果对文章中的内容有疑问或者想要了解更多软件工程上一些设计决策背后的原因，可以在博客下面留言，作者会及时回复本文相关的疑问并选择其中合适的主题作为后续的内容。

1. Postel, J., “User Datagram Protocol”, STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, https://tools.ietf.org/html/rfc768 ↩
   

2. 为什么 DNS 使用 UDP 协议 · Why’s THE Design?, November 2019 https://draveness.me/whys-the-design-dns-udp-tcp ↩
   

3. Stackoverflow: UDP checksum calculation, Sep 2017 https://stackoverflow.com/questions/1480580/udp-checksum-calculation ↩
   

4. Mockapetris, P., “Domain names - implementation and specification”, STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, https://www.rfc-editor.org/info/rfc1035. ↩
   

5. 为什么 TCP 建立连接需要三次握手 · Why’s THE Design?, Oct 2019 https://draveness.me/whys-the-design-tcp-three-way-handshake ↩
   

6. Postel, J., “Internet Protocol”, STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, https://www.rfc-editor.org/info/rfc791. ↩
   

7. Wikipedia: Internet protocol suite https://en.wikipedia.org/wiki/Internet_protocol_suite#Link_layer ↩
   

8. Wikipedia: Port (computer networking) https://en.wikipedia.org/wiki/Port_(computer_networking) ↩
   

9. Wikipedia: Network address translation https://en.wikipedia.org/wiki/Network_address_translation ↩
   

10. Stewart, R., Ed., “Stream Control Transmission Protocol”, RFC 4960, DOI 10.17487/RFC4960, September 2007, https://www.rfc-editor.org/info/rfc4960. ↩
    

11. Wikiepedia: QUIC https://en.wikipedia.org/wiki/QUIC ↩
    

关于图片和转载

本作品采用知识共享署名 4.0 国际许可协议进行许可。

  转载时请注明原文链接，图片在使用时请保留图片中的全部内容，可适当缩放并在引用处附上图片所在的文章链接，图片使用 Sketch 进行绘制，你可以在 [](https://draveness.me/sketch-and-sketch) 一文中找到画图的方法和素材。

本文转载自 Draveness 技术博客。

原文链接：https://draveness.me/whys-the-design-udp-minimum-header