用户数据报协议（英语：User Datagram Protocol，缩写：UDP；又称用户资料包协议）是一个简单的面向资料包的通信协议，位于OSI模型的传输层。该协议由David P. Reed在1980年设计且在RFC 768中被规范。典型网络上的众多使用UDP协议的关键应用在一定程度上是相似的。
 |
在TCP/IP模型中，UDP为网络层以上和应用层以下提供了一个简单的接口。UDP只提供资料的不可靠传递，它一旦把应用程序发给网络层的资料发送出去，就不保留资料备份（所以UDP有时候也被认为是不可靠的资料包协议）。UDP在IP资料包的头部仅仅加入了复用和资料校验字段。
UDP适用于不需要或在程序中执行错误检查和纠正的应用，它避免了协议栈中此类处理的开销。对时间有较高要求的应用程序通常使用UDP，因为丢弃资料包比等待或重传导致延迟更可取。
可靠性
由于UDP缺乏可靠性且属于无连接协议，所以应用程序通常必须容许一些丢失、错误或重复的数据包。某些应用程序（如TFTP）可能会根据需要在应用程序层中添加基本的可靠性机制。[1]
一些应用程序不太需要可靠性机制，甚至可能因为引入可靠性机制而降低性能，所以它们使用UDP这种缺乏可靠性的协议。流媒体，实时多人游戏和IP语音（VoIP）是经常使用UDP的应用程序。 在这些特定应用中，丢包通常不是重大问题。如果应用程序需要高度可靠性，则可以使用诸如TCP之类的协议。
例如，在VoIP中延迟和抖动是主要问题。如果使用TCP，那么任何数据包丢失或错误都将导致抖动，因为TCP在请求及重传丢失数据时不向应用程序提供后续数据。如果使用TCP，那么应用程序则需要提供必要的握手，例如实时确认已收到的消息。
由于UDP缺乏拥塞控制，所以需要基于网络的机制来减少因失控和高速UDP流量负荷而导致的拥塞崩溃效应。换句话说，因为UDP发送端无法检测拥塞，所以像使用包队列和丢弃技术的路由器之类的网络基础设备会被用于降低UDP过大流量。数据拥塞控制协议（DCCP）设计成通过在诸如流媒体类型的高速率UDP流中增加主机拥塞控制，来减小这个潜在的问题。
应用
许多关键的互联网应用程序使用UDP[2]，包括：
- 域名系统（DNS），其中查询阶段必须快速，并且只包含单个请求，后跟单个回复数据包；
- 动态主机配置协议（DHCP），用于动态分配IP地址；
- 简单网络管理协议（SNMP）；
- 路由信息协议（RIP）；
- 网路时间协定（NTP）。
串流媒体、线上游戏流量通常使用UDP传输。 实时视频流和音频流应用程序旨在处理偶尔丢失、错误的数据包，因此只会发生质量轻微下降，而避免了重传数据包带来的高延迟。 由于TCP和UDP都在同一网络上运行，因此一些企业发现来自这些实时应用程序的UDP流量影响了使用TCP的应用程序的性能，例如销售、会计和数据库系统。 当TCP检测到数据包丢失时，它将限制其数据速率使用率。由于实时和业务应用程序对企业都很重要，因此一些人认为开发服务质量解决方案至关重要。[3]
UDP的分组结构
UDP报头包括4个字段，每个字段占用2个字节（即16个二进制位）。在IPv4中，“来源连接端口”和“校验和”是可选字段（以粉色背景标出）。在IPv6中，只有来源连接端口是可选字段。 各16bit的来源端口和目的端口用来标记发送和接受的应用进程。因为UDP不需要应答，所以来源端口是可选的，如果来源端口不用，那么置为零。在目的端口后面是长度固定的以字节为单位的长度域，用来指定UDP数据报包括数据部分的长度，长度最小值为8byte。首部剩下地16bit是用来对首部和数据部分一起做校验和（Checksum）的，这部分是可选的，但在实际应用中一般都使用这一功能。
- 报文长度
- 该字段指定UDP报头和数据总共占用的长度。可能的最小长度是8字节，因为UDP报头已经占用了8字节。由于这个字段的存在，UDP报文总长不可能超过65535字节（包括8字节的报头，和65527字节的数据）。实际上通过IPv4协议传输时，由于IPv4的头部信息要占用20字节，因此数据长度不可能超过65507字节（65,535 − 8字节UDP报头 − 20字节IP头部）。
- 在IPv6的jumbogram中，是有可能传输超过65535字节的UDP数据包的。依据RFC 2675，如果这种情况发生，报文长度应被填写为0。
- 校验和
- 校验和字段可以用于发现头部信息和数据中的传输错误。该字段在IPv4中是可选的，在IPv6中则是强制的。如果不使用校验和，该字段应被填充为全0。
UDP校验和计算
当UDP运行在IPv4之上时，为了能够计算校验和，需要在UDP数据包前添加一个“伪头部”。伪头部包括了IPv4头部中的一些信息，但它并不是发送IP数据包时使用的IP数据包的头部，而只是用来计算校验和而已。
| 位 | 0 – 7 | 8 – 15 | 16 – 23 | 24 – 31 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 来源地址 | |||||||||||||||||||||||||||||||
| 32 | 目的地址 | |||||||||||||||||||||||||||||||
| 64 | 全零 | 协议名 | UDP报文长度 | |||||||||||||||||||||||||||||
| 96 | 来源连接端口 | 目的连接端口 | ||||||||||||||||||||||||||||||
| 128 | 报文长度 | 检验和 | ||||||||||||||||||||||||||||||
| 160+ | 数据 | |||||||||||||||||||||||||||||||
当UDP运行于IPV6之上时，校验和是必须的，其计算方法位于RFC 2460:
任何包含来自IP头地址的传输层或其他上层协议，其校验和计算必须被修改，以适应IPv6的128位ip地址。[4]
IPv6伪头部是生成校验和所用的数据。
| 位 | 0 – 7 | 8 – 15 | 16 – 23 | 24 – 31 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 来源地址 | |||||||||||||||||||||||||||||||
| 32 | ||||||||||||||||||||||||||||||||
| 64 | ||||||||||||||||||||||||||||||||
| 96 | ||||||||||||||||||||||||||||||||
| 128 | 目的地址 | |||||||||||||||||||||||||||||||
| 160 | ||||||||||||||||||||||||||||||||
| 192 | ||||||||||||||||||||||||||||||||
| 224 | ||||||||||||||||||||||||||||||||
| 256 | UDP报文长度 | |||||||||||||||||||||||||||||||
| 288 | 全零 | 下一个指针位置 | ||||||||||||||||||||||||||||||
| 320 | 来源连接端口 | 目的连接端口 | ||||||||||||||||||||||||||||||
| 352 | 报文长度 | 校验和 | ||||||||||||||||||||||||||||||
| 384+ | 数据 | |||||||||||||||||||||||||||||||
参见
- TCP/UDP端口列表
- UDP-Lite——一种通过减少校验和覆盖程度来提升数据可达性的改进
- Micro Transport Protocol
- 基于UDP的数据传输协议
参考文献
外部链接
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
