UDP只在 IP的数据包服务 之上增加了一点功能，这就是复用和分用的功能以及差错检测的功能。
UDP的主要特点：
| 序号 | 特点 | 描述 |
|---|---|---|
| 1 | 无连接 |
发送数据之前不需要建立连接，因此减少了开销（overhead）和发送数据之前的时延（delay） |
| 2 | 使用尽最大努力交付 |
不保证可靠交付，因此 主机不需要维持复杂的 连接状态表 |
| 3 | 面向报文（Message） |
发送方的UDP对应用程序交下来的报文（Message），在添加首部（header）后就向下交付网络层，既不合并，也不拆分，而是保留这些报文的边界。应用层交给UDP多长的报文，UDP就照样发送，一次发送一个报文。接收方的UDP，对网络层交上来的UDP用户数据报，在去除首部后就原封不动地交付上层的应用进程。UDP一次交付一个完整的 报文。若报文太长，UDP把它交给IP层后，IP层在传送时可能要进行分片，这会降低IP层的效率 |
| 4 | 没有拥塞控制 |
网络出现的拥塞[se]（Congestion）不会使源主机的发送速率降低。这对 实时应用是很重要的。很多的实时应用（如IP电话，实时视频会议等）要求源主机以恒定的速率发送数据，并且允许在网络发生拥塞是丢失一些数据，但却不允许数据有太大的时延。UDP正好适合这种要求。 |
| 5 | - |
支持一对一、一对多、多对一和多对多的交互通信 |
| 6 | UDP的首部开销小 |
只有8个字节，比TCP的20个字节的首部要短。 |
虽然某些实时应用需要使用没有拥塞控制的UDP，但当很多的源主机同时都向网络发送高速率的实时视频流时，网络就有可能发生拥塞，结果大家都无法正常接收。因此，不使用拥塞控制功能的 UDP有可能会引起网络产生严重的拥塞问题。
还有一些使用UDP的实时应用，需要对UDP的不可靠的传输进行适当的改进，以减少数据的丢失。在这种情况下，应用进程本身可以在不影响应用的实时性的前提下，增加一些提高可靠性的措施，如采用前向纠错或重传已丢失的报文。
用户数据报UDP有两个字段：数据字段和首部字段。
首部字段很简单，只有8个字节，由4个字段组成，每个字段的长度都是两个字节。
各字段（Field）意义如下：
| 序号 | 字段（Field） | 描述 |
|---|---|---|
| 1 | 源端口 | 源端口号。 在需要对方回信时选用。不需要时可用全 0。 |
| 2 | 目的端口 | 目的端口号。 这在 终点交付报文时必须使用。 |
| 3 | 长度 | UDP用户数据报的长度，其最小值是8（仅有首部） |
| 4 | 校验和 | 检测UDP用户数据报 在传输中是否有错，有错就丢弃。 |
UDP用户数据报的 首部 和 伪首部：
传输层从IP层收到UDP数据报时，就根据首部中的目的端口，把UDP数据报通过相应的端口，上交最后的终点：应用进程。
如果 接收方UDP发现收到的报文中的目的端口号不正确，就丢弃该报文，并由网际控制报文协议ICMP 发送【端口不可达】差错报文给发送方。
请注意，虽然在UDP之间的通信要用到其端口号，但由于UDP的通信是无连接的，因此不需要使用套接字（TCP之间的通信必须要在两个套接字之间建立连接）。
UDP用户数据报 首部中 校验和 的计算方法有些特殊。在计算校验和时，要在UDP用户数据报之前增加12个字节的伪首部。所谓【伪首部】是因为这种伪首部并不是UDP用户数据报真正的首部。只是在计算校验和时，临时添加在UDP用户数据报前面，得到一个临时的UDP用户数据报。校验和就是按照这个临时的UDP用户数据报来计算的。
伪首部既不向下传输，也不向上递交，而仅仅是为了计算校验和。
