在计算机网络中，传输层有两个非常重要的协议，一个是TCP，另一个就是UDP。很多人对TCP比较熟悉，因为它和日常的网页浏览、文件下载密切相关，而UDP往往因为不常被直接感知而被忽略。但实际上，UDP在今天的互联网流量中占据着相当大的比例，尤其是在实时通信领域，它的作用几乎不可替代。要理解UDP，首先要明确它是什么，以及它和TCP在设计思路上的根本差异。
UDP的基本定义与报文结构
UDP的全称是User Datagram Protocol，中文一般翻译为用户数据报协议。它和TCP一样，工作在OSI参考模型的传输层，下层使用IP协议进行数据传输。从功能上看，UDP提供的是非常简单的传输服务：应用层把数据交给UDP，UDP加上一个简短的头部后就直接交给IP层发送，接收方则根据头部信息把数据交给对应的应用程序。整个过程不涉及连接建立、状态维护、确认应答或重传机制，因此UDP常被称为无连接协议。
UDP的头部结构相当精简，总共只有8个字节，包含四个字段。源端口号和目的端口号各占16位，用来标识发送方和接收方的应用进程。长度字段占16位，表示UDP头部加上数据部分的总字节数。校验和字段也占16位，用来检测数据在传输过程中是否出现差错，不过这个字段在IPv4中是可选的，发送方可以选择不计算校验和，接收方如果发现校验和错误，通常会直接丢弃该数据报，而不会要求重发。正因为头部小、逻辑简单，UDP的处理开销比TCP低很多。
| 字段名称 | 长度 | 说明 |
|---|---|---|
| 源端口号 | 16位 | 标识发送方应用进程，可为0 |
| 目的端口号 | 16位 | 标识接收方应用进程 |
| 长度 | 16位 | UDP头部和数据的总长度，最小为8 |
| 校验和 | 16位 | 用于差错检测，IPv4中可选 |
从这张表可以看出，UDP的设计目标就是尽量少做事。它不维护连接状态，不记录发送窗口，也不处理确认和重传，把所有可靠性相关的工作都留给了上层应用。这种极简设计让UDP非常轻量，但同时也决定了它无法提供像TCP那样的可靠传输保证。
UDP的主要特点
UDP的第一个显著特点是无连接。使用UDP通信时，发送方不需要先和接收方建立连接，也不需要双方维护连接状态。只要知道对方的IP地址和端口号，就可以直接把数据报发送出去。这一特点省去了TCP三次握手和四次挥手的过程，降低了通信延迟，也让服务器可以同时处理大量客户端而不用为每个连接分配资源。
第二个特点是不可靠交付。UDP不保证数据报一定能够到达接收方，也不保证数据报的到达顺序与发送顺序一致。如果网络中间发生丢包、延迟或重复，UDP本身不会进行任何纠正，接收方收到的可能就是乱序的数据。这一点常被拿来和TCP对比，TCP会通过序号、确认、重传等机制保证数据完整有序，但UDP把这些问题都抛给了应用层。如果应用需要可靠传输，就必须自己在协议设计上增加序号、确认和重传逻辑。
第三个特点是面向报文。UDP对应用层交下来的报文不进行拆分或合并，而是在前面加上头部后直接作为一个完整的数据报发送出去。接收方一次收到的也是一个完整的数据报。这个特性让UDP很好地保留了消息边界，应用层不需要像处理TCP字节流那样处理粘包或拆包问题。对于很多以消息为单位的应用来说，UDP的使用更加直观。
第四个特点是支持多种通信模式。由于UDP不维护连接，它天然支持一对一、一对多、多对一和多对多的通信方式。发送方可以通过广播地址把数据报发给同一网络内的所有主机，也可以通过组播地址发给一组特定的主机。这一点在视频直播、局域网发现等场景中非常有用，而TCP因为基于连接，通常只能实现一对一的通信。
第五个特点是头部开销小。UDP头部只有8个字节，而TCP头部至少20个字节，如果加上选项字段还会更长。在传输小数据量或需要高频发送数据的场景下，UDP能有效减少网络带宽的额外消耗，提高有效载荷占比。
第六个特点是没有拥塞控制。UDP不会像TCP那样根据网络拥塞情况调整发送速率，应用层可以按照自己的节奏持续发送数据。这在高带宽、低延迟的场景中是优势，比如实时视频传输不希望因为拥塞控制而自动降低码率。但如果大量UDP流量不加节制地涌入网络，也可能加剧拥塞，因此不少基于UDP的应用会在应用层自行实现拥塞控制或速率限制。
UDP与TCP的主要区别
TCP和UDP是传输层最常用的两个协议，理解它们的差异有助于根据实际需求做出选择。TCP在传输前需要建立连接，传输过程中通过确认和重传保证数据可靠到达，传输结束后释放连接。由于这些机制的存在，TCP适合对数据完整性要求很高的场景，如网页、文件传输、电子邮件等。相比之下，UDP不建立连接，不进行确认和重传，传输效率高、延迟低，但无法保证可靠性。
| 比较项 | UDP | TCP |
|---|---|---|
| 连接方式 | 无连接 | 面向连接 |
| 可靠性 | 不可靠，不保证到达和顺序 | 可靠，保证数据完整有序 |
| 传输形式 | 面向报文，保留消息边界 | 面向字节流，可能拆包粘包 |
| 头部开销 | 8字节 | 至少20字节 |
| 通信模式 | 支持一对一、一对多、广播、组播 | 仅支持一对一 |
| 拥塞控制 | 无 | 有 |
| 典型应用 | 音视频、游戏、DNS等 | 网页、文件传输、邮件等 |
从这张对比表可以看出，UDP和TCP并不是简单的谁好谁坏，而是各自针对不同的设计目标。TCP把可靠性放在首位，适合需要完整传输数据的场景；UDP把速度和效率放在首位，适合实时性要求更高的场景。实际开发中也可以在同一应用里同时使用两种协议，例如用TCP传输控制指令，用UDP传输实时媒体数据。
UDP的典型应用场景
实时音视频通信是UDP最常见的使用场景之一。网络电话、视频会议、语音连麦等应用对延迟非常敏感，如果使用TCP，一旦发生丢包，TCP会等待重传，导致声音或画面卡顿。UDP虽然可能丢包，但在实时通信中，少量的数据丢失通常不会严重影响通话质量，而低延迟带来的流畅体验更为重要。因此，很多音视频传输协议如RTP都基于UDP进行封装。
在线游戏也大量使用UDP。游戏服务器需要频繁同步玩家的位置、动作、状态等信息，这些数据的时效性极强。一条几毫秒前的操作指令如果因为TCP重传而延迟到达，会造成游戏画面不同步。UDP的快速发送机制正好符合游戏对低延迟的追求，即使偶尔丢失一个状态包，后续的更新包也会很快覆盖，不会明显影响体验。
DNS域名解析同样离不开UDP。当用户在浏览器输入一个网址时，系统会向DNS服务器发送查询请求。这个请求通常很小，一次就能装进一个UDP数据报。如果查询响应丢失，客户端可以简单地重新发送请求。UDP的低开销和无连接特性让DNS服务器能够高效地处理海量查询，因此DNS默认使用UDP的53端口。
直播推流也常用UDP。直播对实时性的要求很高，观众希望看到的主播画面尽可能接近现场。如果使用TCP进行直播传输，网络波动时容易出现缓冲等待，影响观看体验。基于UDP的传输方案可以减少延迟，即使网络状况不稳定，也可以通过应用层的前向纠错等技术弥补丢包。
还有一些网络管理协议使用UDP，例如SNMP简单网络管理协议和TFTP简单文件传输协议。这些协议通常传输的数据量不大，对实时性和简易性要求较高，UDP恰好满足需求。
使用UDP时需要注意的问题
UDP虽然简单高效，但正因为不提供可靠性保证，开发者在使用时需要自行处理一些潜在问题。首先是丢包问题。如果业务数据不能容忍丢失，就必须在应用层引入确认应答和超时重传机制。例如可以实现类似TCP的序列号，让接收方对收到的数据报进行确认，发送方在超时后重发未被确认的数据。
其次是乱序问题。UDP数据报可能沿着不同的网络路径到达接收方，导致顺序错乱。应用层可以在每个数据报中加入序号，接收方根据序号重新排序，或者直接丢弃过时的数据。对于实时音视频来说，可以通过缓冲区和对时戳的处理来减少乱序带来的影响。
另外，使用UDP时还要注意网络安全。由于UDP无连接，攻击者可以伪造源IP地址向目标主机发送大量UDP数据包，造成UDP洪泛攻击。一些网络服务如果对外开放UDP端口，需要做好流量监控和限制，避免被滥用。
总的来说，UDP是一种设计理念非常明确的协议，它把复杂性留给应用层，用最小的协议开销换取速度和灵活性。理解它的定义和特点，能够帮助开发者在网络编程中根据实际场景做出更合理的协议选择。无论是追求低延迟的实时应用，还是需要快速响应的查询服务，UDP都是一个值得认真掌握的传输层工具。