用户数据报协议（英语：User Datagram Protocol，缩写：UDP；又称用户数据包协议）是一个简单的面向数据报的通信协议，位于OSI模型的传输层。该协议由David P. Reed（英语：David P. Reed）在1980年设计且在RFC 768中被规范。典型网络上的众多使用UDP协议的关键应用在一定程度上是相似的。
在TCP/IP模型中，UDP为网络层以上和应用层以下提供了一个简单的接口。UDP只提供数据的不可靠传递，它一旦把应用程序发给网络层的数据发送出去，就不保留数据备份（所以UDP有时候也被认为是不可靠的数据报协议）。UDP在IP数据报的头部仅仅加入了复用和数据校验字段。
UDP适用于不需要或在程序中执行错误检查和纠正的应用，它避免了协议栈中此类处理的开销（英语：Overhead (computing)）。对时间有较高要求的应用程序通常使用UDP，因为丢弃数据包比等待或重传导致延迟更可取。
由于UDP缺乏可靠性且属于无连接协议，所以应用程序通常必须容许一些丢失、错误或重复的数据包。某些应用程序（如TFTP）可能会根据需要在应用程序层中添加基本的可靠性机制。
一些应用程序不太需要可靠性机制，甚至可能因为引入可靠性机制而降低性能，所以它们使用UDP这种缺乏可靠性的协议。流媒体，实时多人游戏和IP语音（VoIP）是经常使用UDP的应用程序。在这些特定应用中，丢包通常不是重大问题。如果应用程序需要高度可靠性，则可以使用诸如TCP之类的协议。
例如，在VoIP中延迟和抖动是主要问题。如果使用TCP，那么任何数据包丢失或错误都将导致抖动，因为TCP在请求及重传丢失数据时不向应用程序提供后续数据。如果使用UDP，那么应用程序则需要提供必要的握手，例如实时确认已收到的消息。
由于UDP缺乏拥塞控制，所以需要基于网络的机制来减少因失控和高速UDP流量负荷而导致的拥塞崩溃效应。换句话说，因为UDP发送端无法检测拥塞，所以像使用包队列和丢弃技术的路由器之类的网络基础设备会被用于降低UDP过大流量。数据拥塞控制协议（DCCP）设计成通过在诸如流媒体类型的高速率UDP流中增加主机拥塞控制，来减小这个潜在的问题。
许多关键的互联网应用程序使用UDP，包括：
流媒体、在线游戏流量通常使用UDP传输。实时视频流和音频流应用程序旨在处理偶尔丢失、错误的数据包，因此只会发生质量轻微下降，而避免了重传数据包带来的高延迟。由于TCP和UDP都在同一网络上运行，因此一些企业发现来自这些实时应用程序的UDP流量影响了使用TCP的应用程序的性能，例如销售、会计和数据库系统。当TCP检测到数据包丢失时，它将限制其数据速率使用率。由于实时和业务应用程序对企业都很重要，因此一些人认为开发服务质量解决方案至关重要。
某些VPN应用（如OpenVPN）使用UDP并可以在应用程序级别实现可靠连接和错误检查。
UDP报头包括4个字段，每个字段占用2个字节（即16个二进制位）。在IPv4中，“来源连接端口”和“校验和”是可选字段（以粉色背景标出）。在IPv6中，只有来源连接端口是可选字段。各16bit的来源端口和目的端口用来标记发送和接受的应用进程。因为UDP不需要应答，所以来源端口是可选的，如果来源端口不用，那么置为零。在目的端口后面是长度固定的以字节为单位的长度域，用来指定UDP数据报包括数据部分的长度，长度最小值为8byte。首部剩下地16bit是用来对首部和数据部分一起做校验和（Checksum）的，这部分是可选的，但在实际应用中一般都使用这一功能。
当UDP运行在IPv4之上时，为了能够计算校验和，需要在UDP数据包前添加一个“伪头部”。伪头部包括了IPv4头部中的一些信息，但它并不是发送IP数据包时使用的IP数据包的头部，而只是一个用来计算校验和而已。
当UDP运行于IPV6之上时，校验和是必须的，其计算方法位于RFC 2460:
任何包含来自IP头地址的传输层或其他上层协议，其校验和的计算必须被修改，以适应IPv6的128位ip地址。
IPv6伪头部是生成校验和所用的数据。
