目录
1、概念
2、报文结构
3、核心特性
3.1 无连接
3.2 不可靠交付
3.3 面向数据报
3.4 轻量级&高效
3.5 支持广播和组播
4、典型应用场景
5、优缺点分析
6、与TCP的区别
1、概念
UDP(User Datagram Protocol,用户数据报协议)
主要目的:供一种简单、高效、无连接的数据传输服务。
2、报文结构
UDP 头部: (8 字节)
-
源端口: (2 字节) 发送方应用程序的端口号。可选(可置为 0),用于接收方回复时知道发给谁。
-
目的端口: (2 字节) 接收方应用程序的端口号。必需。
-
长度: (2 字节) UDP 数据报的总长度(头部 + 数据),以字节为单位。最小值是 8(只有头部)。
-
校验和: (2 字节) 用于检测头部和数据在传输过程中是否出错(可选,但强烈推荐使用)。覆盖头部、数据和伪头部(包含源/目标IP地址、协议号等)。如果接收方计算校验和不匹配,数据报会被静默丢弃(不通知发送方)。
数据: (长度可变) 应用程序要发送的有效载荷。
3、核心特性
3.1 无连接
这是 UDP 最显著的特点。在发送数据之前,不需要像 TCP 那样先建立连接(三次握手)。
应用程序只需构造好数据报(Datagram),指定目标 IP 地址和端口号,就可以直接发送出去。
同样,接收方也不需要事先同意或准备好接收连接。它只是监听某个端口,等待数据报的到来。(虽然UDP可以有校验和检查错误,但不保证送达)
3.2 不可靠交付
UDP 不保证数据报一定能到达目的地。
它不提供以下 TCP 具有的可靠性机制:
-
数据包确认: 接收方不会发送 ACK 确认收到数据。
-
超时重传: 发送方在超时后不会自动重发丢失的数据包。
-
数据包排序: 接收到的数据包顺序可能与发送顺序不同,UDP 不会重新排序。
-
重复数据检测: 可能会收到重复的数据包(例如,网络路径变化导致),UDP 不会去重。
-
流量控制: 不会根据接收方的处理能力调整发送速率。
-
拥塞控制: 不会主动检测和避免网络拥塞。
结果: 数据包可能丢失、重复、乱序到达,或者被网络设备(如路由器)静默丢弃(例如在拥塞时)。应用程序需要自己处理这些问题(如果需要)。
3.3 面向数据报
数据是以离散的、独立的 “数据报” 为单位发送和接收的(完整的)。
-
发送方应用程序的每次写操作(例如一个
sendto()
调用)通常会产生一个独立的 UDP 数据报。 -
接收方应用程序的每次读操作(例如一个
recvfrom()
调用)通常接收一个完整的 UDP 数据报。
关键: UDP 不会像 TCP 那样将应用层的数据流拆分成多个段(Segments)或重新组装成流。它保留消息边界。
3.4 轻量级&高效
-
协议头非常小(只有 8 字节),开销远低于 TCP(通常 20 字节,带选项更多)。
-
没有连接建立/拆除的开销(三次握手、四次挥手)。
-
没有复杂的确认、重传、排序、流量控制、拥塞控制逻辑。这使得 UDP 的协议栈处理非常快,消耗的 CPU 和网络资源更少。
结果: 延迟更低,传输速度理论上可以更快(尤其是在低丢包率的网络上)。
3.5 支持广播和组播
UDP 可以将数据报发送到:
-
单播: 单个目标主机。
-
广播: 同一局域网内的所有主机(例如
255.255.255.255
或子网广播地址)。 -
组播: 加入特定组播组的所有主机。
TCP 是严格的一对一连接,只支持单播。
4、典型应用场景
1> 对延迟极其敏感,能容忍少量丢包:
-
实时音视频传输: VoIP (如 Skype, Zoom 的部分传输)、视频会议、在线直播。偶尔丢帧或短暂声音中断比延迟高导致卡顿更可接受。
-
在线游戏: 特别是快节奏的 FPS、MOBA 等。玩家位置、动作指令需要极快送达,丢失个别数据包(如非关键位置更新)影响相对较小,而延迟高(Lag)会严重影响体验。
-
实时流媒体: 部分直播协议(如某些 RTP 实现)。
2> 简单查询/响应模型,且请求/响应本身很小:
-
DNS(域名系统): 查询域名对应的 IP 地址。请求和响应通常很小,一次查询一个响应,重试成本低且快速(客户端负责超时重试)。
-
DHCP(动态主机配置协议): 获取 IP 地址、网关等信息。使用广播/组播,且过程本身包含重试机制。
-
SNMP(简单网络管理协议): 网络设备监控和管理。查询和陷阱(Trap)消息。
-
TFTP(简单文件传输协议): 轻量级文件传输(如路由器固件升级),协议简单,自带简单的确认机制(ACK)。
3> 广播/组播应用:
-
服务发现: 设备在局域网内广播宣告自身服务(如 Bonjour/mDNS)。
-
路由协议: 如 RIP。
-
多媒体分发: 组播视频流。
4> 在可靠传输之上构建自定义协议:
-
应用层可以在 UDP 基础上实现自己需要的、更贴合应用特性的可靠性、顺序、拥塞控制逻辑。这提供了极大的灵活性:
-
QUIC: HTTP/3 的底层传输协议,基于 UDP,整合了 TLS 加密,并实现了更快速、更灵活的连接建立、可靠传输和拥塞控制。
-
DTN(容断网)协议: 用于高延迟、易中断的网络环境(如太空通信)。
-
特定游戏网络协议: 针对游戏状态同步特性优化的可靠性和顺序机制。
-
5、优缺点分析
优点:
-
低延迟: 无连接建立开销,无等待确认的延迟。
-
低开销: 头部小,协议逻辑简单,节省带宽和计算资源。
-
高效率: 在低丢包率网络中,吞吐量可以非常高。
-
简单: 协议本身简单,API 也相对简单。
-
支持广播/组播: 实现一对多通信的基础。
-
无连接状态: 服务器端无需为每个客户端维护连接状态,能支持更多并发“连接”(实际是无连接的会话)。
-
灵活性: 为应用层提供基础传输,允许在其上构建自定义的可靠性等机制。
缺点:
-
不可靠: 数据可能丢失、重复、乱序。应用程序必须自行处理(如果需要可靠性)。
-
无拥塞控制: 发送方可能以过高速度发送数据淹没网络,导致拥塞崩溃。应用层需要谨慎设计发送速率。
-
数据报大小限制: 单个 UDP 数据报的有效载荷通常不能超过 64KB(减去 IP 和 UDP 头部)。更大的数据需要应用层分片和重组(易丢失)。
-
易受 DDoS 攻击: 伪造源 IP 地址发送大量 UDP 数据报进行反射放大攻击(如 DNS/NTP反射攻击)非常容易。
6、与TCP的区别
特性 | UDP | TCP |
---|---|---|
连接 | 无连接 | 面向连接 (需三次握手) |
可靠性 | 不可靠 (不保证送达、顺序、不重复) | 可靠 (保证送达、顺序、无重复) |
传输单位 | 数据报 (保留消息边界) | 字节流 (无消息边界) |
速度 | 更快 (低延迟、低开销) | 相对较慢 (连接管理、确认、控制机制) |
开销 | 低 (头部小,8字节) | 高 (头部大,通常20字节+) |
流量控制 | 无 | 有 (滑动窗口) |
拥塞控制 | 无 | 有 (多种算法) |
广播/组播 | 支持 | 不支持 (仅单播) |
复杂性 | 简单 | 复杂 |
典型应用 | 实时音视频、游戏、DNS、广播、QUIC/HTTP3 | Web浏览(HTTP/HTTPS)、文件传输(FTP)、邮件(SMTP/POP/IMAP)、远程登录(SSH) |