用户数据报协议（UDP）是一种传输层协议，用于在 IP 网络中以很低开销发送数据。它允许应用程序把称为数据报的小型数据单元发出，而不必先在发送方和接收方之间建立正式连接。
与强调可靠交付、排序、重传和流量控制的 TCP 不同，UDP 追求速度、简单性和低延迟。它常用于实时通信、在线游戏、视频流、DNS 查询、VoIP 媒体、物联网遥测、网络发现、VPN 隧道以及“及时到达比延迟到达更有价值”的应用。
一种轻量化的数据传输方式
UDP 的工作方式类似于发送一条不要求接收方逐步确认的消息。发送方准备数据报，写入源端口和目的端口信息，然后交给 IP 进行投递，网络再尝试把数据包送到目标主机。
这种轻量化设计使 UDP 速度很快。数据传输前没有连接握手，丢包时没有内置重传，也没有要求数据包必须按顺序到达，因此能减少延迟和处理开销，适合必须快速响应的应用。
代价是 UDP 本身不保证交付。数据包可能丢失、重复、延迟或乱序到达；如果应用需要可靠性，就必须在 UDP 之上自行加入错误处理、重传、排序或恢复逻辑。
数据报流程如何工作
应用程序创建负载
当应用需要发送数据时，流程就开始了。它可能是一次 DNS 查询、语音包、游戏动作更新、视频流片段、传感器读数或发现消息；应用会把这些数据交给操作系统的 UDP 层。
由于 UDP 不像 TCP 那样管理长会话，应用可以快速、反复地发送消息。当新的状态更新比恢复旧消息更重要时，这种方式特别有用。
端口识别服务
UDP 使用端口号来标识应由哪个应用或服务接收数据报。源端口标识发送方应用，目的端口标识接收主机上的目标服务。
例如，DNS 通常使用 UDP 53 端口，而许多语音、视频、游戏和自定义应用协议会使用各自定义的端口范围。没有端口，接收设备就无法判断应由哪个应用处理收到的数据。
添加报文头
添加报文头说明 UDP 把复杂控制交给应用层，因此UDP、端口、NAT、校验和、报文头必须由系统设计统一评估。
校验和有助于检测传输过程中的数据损坏。如果数据报受损，接收方可以丢弃它，而不是把错误数据交给应用程序。不过，校验和验证本身并不提供重传能力。
IP 负责网络投递
添加 UDP 报文头后，数据报会交给 IP 层在网络中投递。路由器根据目的地址和路由表转发数据包；UDP 本身并不知道也不管理发送方和接收方之间的完整路径。
如果发生拥塞、防火墙规则拦截、路由问题、丢包或网络故障，UDP 不会自动恢复。应用程序必须自行决定是忽略缺失数据、请求重新发送、调整质量，还是改变处理方式。
为什么有些应用更偏好速度
在许多实时系统中，迟到的数据往往不如丢失的数据有价值。语音通话中，两秒前的声音片段不应在对话已经继续后突然播放；在线游戏中，玩家已经再次移动后，旧的位置更新可能已经没有意义。
这正是 UDP 的价值所在。它让应用不必等待传输层重传也能继续运行。应用可以使用抖动缓冲、预测、丢包隐藏、前向纠错或自适应码率来处理不完美的传输。
为什么有些应用更偏好速度说明 UDP 把复杂控制交给应用层，因此UDP、TCP必须由系统设计统一评估。
核心特性
无连接运行
UDP 在发送数据前不需要连接建立握手。只要知道目标 IP 地址和端口，发送方就可以立即发送数据报。
因此，UDP 适合快速请求-响应服务、广播式发现，以及那些需要尽量减少连接建立延迟的实时应用。
不内置交付保证
该协议不保证数据报一定到达，也不保证数据包顺序或避免重复。这听起来像弱点，但正是这种设计让协议保持简单和快速。
需要可靠性的应用可以在自己的协议逻辑中加入确认、序列号、重传或状态跟踪。
低开销
UDP 报文头很小，行为也很简单，因此可以减少带宽开销和处理负载。对于大量小消息场景，这可能是一个重要优势。
低开销说明 UDP 把复杂控制交给应用层，因此DNS、延迟必须由系统设计统一评估。
支持广播和组播
根据网络配置，UDP 可以支持广播和组播通信。这使一个发送方能够比建立多个独立一对一会话更高效地触达多个接收方。
组播常用于 IPTV、服务发现、路由协议、工业系统以及部分媒体分发设计。不过，组播必须得到交换机、路由器和网络策略的支持。
灵活的应用控制
由于 UDP 只提供基础投递能力，应用可以在其上构建自己的行为。流媒体系统可能优先保证播放流畅，游戏服务器可能优先使用最新状态更新，传感器网络可能优先考虑电池效率，VPN 也可以建立自己的可靠性和加密层。
这种灵活性正是 UDP 虽然结构简单，却仍然在现代网络中保持重要地位的原因之一。
UDP 并不是无意中“不可靠”。它被设计得很精简，是为了让应用自行选择速度、恢复能力和控制方式之间的平衡。
常见使用场景
DNS 查询
DNS 查询说明 UDP 把复杂控制交给应用层，因此UDP、端口、DNS必须由系统设计统一评估。
如果响应过大，或者特定条件要求更可靠的传输，DNS 也可以使用 TCP。这说明协议可以为了速度选择 UDP，同时在可靠性或报文大小要求变化时使用其它方式。
语音和视频通信
VoIP 通话、视频会议、SIP 媒体流、RTP 音频、WebRTC 会话和实时会议通常依赖 UDP 传输媒体。原因很简单：实时音频和视频需要低延迟。
如果丢失少量数据包，应用可以隐藏丢包或略微降低质量。花太长时间恢复旧数据包会让对话显得延迟和不自然。
在线游戏
游戏通常会频繁发送位置、移动、动作和状态更新。对游戏服务器而言，最新玩家位置通常比一个迟到的旧更新更重要。
游戏开发者通常会为登录、背包、比赛状态或购买等重要事件添加自己的可靠性层，同时把快速数据报用于实时玩法中的移动更新。
流媒体与实时媒体
流媒体与实时媒体说明 UDP 把复杂控制交给应用层，因此UDP、端口、视频、广播必须由系统设计统一评估。
对于允许缓冲的点播视频，基于 TCP 的传输也很常见。最佳传输方式取决于视频是直播、交互式，还是预录内容。
物联网和传感器数据
许多物联网设备会发送小型状态报告、传感器读数、心跳消息或控制信号。当设备需要轻量通信，并且不希望维护大量连接带来额外开销时，UDP 会很有用。
不过，物联网系统仍应考虑可靠性、安全性和网络丢包。关键告警、固件更新和控制命令通常需要比普通遥测数据更强的确认机制。
VPN 与隧道协议
一些 VPN 技术使用 UDP，是因为它在多变网络条件下表现较好，并能避免可靠协议相互嵌套时可能产生的某些延迟。
当 VPN 在 TCP 隧道中承载 TCP 流量时，重传机制有时会相互影响并带来不良效果。基于 UDP 的隧道让 VPN 软件能够更好地控制可靠性、加密和时序。
网络发现
网络发现说明 UDP 把复杂控制交给应用层，因此UDP、组播、广播必须由系统设计统一评估。
这种方式常见于打印机、智能设备、媒体设备、工业设备和本地服务发现系统。网络分段和防火墙规则可能会影响发现功能能否跨子网工作。
对开发者和网络的设计价值
主要优势是低延迟。由于没有连接握手，也没有强制重传，应用可以快速发送数据并保持实时通信连续运行。这对于语音、视频、游戏、遥测和控制信号等重视时序的场景很有用。
另一个优势是简单。UDP 在传输层容易实现，轻量设计很适合小消息，也适用于嵌入式系统、资源受限设备和简单的请求-响应服务。
可扩展性也可能成为优势。服务器可以接收来自大量客户端的数据报，而不必维持 TCP 那种连接状态模型。这对某些高并发服务很有用，但应用层设计和安全仍然重要。
最后，UDP 给应用开发者更大的灵活性。开发者可以决定哪些消息需要确认，哪些可以丢弃，哪些应重复发送，哪些应快速过期，从而让传输行为匹配实际业务或技术需求。
局限与风险
数据包丢失
数据包丢失说明 UDP 把复杂控制交给应用层，因此UDP、数据报、防火墙、拥塞必须由系统设计统一评估。
对于非关键的实时更新，这可能可以接受。但对于重要命令、交易或记录，还需要额外的可靠性机制。
乱序到达
数据包可能以不同于发送顺序的顺序到达。这可能是因为数据包走了不同的网络路径，或经历了不同的延迟。
需要顺序性的应用必须包含序列号或时间戳，并决定如何重新排序、丢弃或处理数据包。
默认没有拥塞控制
TCP 包含拥塞控制，会在网络过载时降低发送速率。UDP 不会自动提供这一能力。如果应用发送过于激进，可能会加剧拥塞和丢包。
负责任的应用设计应在需要时加入速率控制、自适应码率、发送节奏控制或拥塞感知行为。
防火墙和 NAT 挑战
防火墙和 NAT 挑战说明 UDP 把复杂控制交给应用层，因此UDP、TCP、端口、NAT、防火墙必须由系统设计统一评估。
应用通常使用 keepalive 消息、STUN、TURN、ICE 或中继服务，以支持穿越 NAT 和防火墙环境的通信。
安全暴露
由于 UDP 是无连接的，在某些场景下攻击者可能更容易伪造源地址。如果防护不足的服务会响应伪造请求，UDP 也可能被用于反射和放大攻击。
使用 UDP 的服务应验证请求、限制响应大小、设置速率限制、尽可能限制访问，并在需要时使用加密或认证。
建立在 UDP 之上的可靠性方法
虽然 UDP 本身很精简，但许多应用会在更高层加入可靠性功能。实时媒体系统可能使用序列号、时间戳、抖动缓冲、丢包隐藏和前向纠错；游戏协议可能只重传重要状态变化，而忽略过时的移动更新。
一些现代传输技术也在 UDP 之上构建更高级的行为，例如加密、流复用、拥塞控制和更快的连接建立，同时仍把 UDP 作为底层传输。这说明 UDP 可以作为更高级通信模型的灵活基础。
建立在 UDP 之上的可靠性方法说明 UDP 把复杂控制交给应用层，因此UDP、安全必须由系统设计统一评估。
与 TCP 的实际比较
当需要完整且有序的交付时，通常更适合使用 TCP。文件下载、网页、电子邮件传输、数据库连接和许多业务应用都需要数据正确并按顺序到达。TCP 负责连接建立、确认、重传、排序和拥塞控制。
当速度、时序或应用专属控制更重要时，通常更适合使用 UDP。实时音频、直播视频、DNS 查询、游戏更新和遥测数据，往往不会从传输层等待延迟重传中受益。
两种协议没有绝对优劣。它们服务于不同的设计目标。优秀的应用会根据数据类型、用户体验、网络条件和安全需求选择合适的传输行为。
部署与故障排查建议
部署使用 UDP 的服务时，要确认所需端口和协议。即使端口号相同，开放 TCP 端口也不会自动允许 UDP 流量。防火墙、路由器、云安全组和主机防火墙都必须放行正确的协议。
必要时应从两个方向进行测试。UDP 不像 TCP 那样建立可见连接，因此没有响应并不一定证明服务可达。抓包、应用日志、服务器端计数器和测试工具可以帮助确认数据报是否到达。
部署与故障排查建议说明 UDP 把复杂控制交给应用层，因此数据包、延迟、抖动必须由系统设计统一评估。
在 NAT 环境中，应检查映射超时和保活行为。如果会话短暂可用后停止，可能是 NAT 设备过快关闭了 UDP 映射。
UDP 故障排查应重点确认数据包是否到达、应用是否监听正确端口、防火墙规则是否匹配协议，以及网络质量是否满足应用的时序需求。
安全最佳实践
不要把不必要的 UDP 服务暴露到公网。未知或未使用的服务应默认阻断。面向公网的服务应保持更新、受到监控并设置速率限制。
当数据敏感或命令会影响系统时，应使用认证和加密。UDP 本身不提供保密性、身份验证或重放保护。
限制放大风险。服务应避免对未经认证的小请求返回大响应，尤其是在公网环境中。速率限制和源地址验证可以降低滥用风险。
安全最佳实践说明 UDP 把复杂控制交给应用层，因此数据报、端口、NAT必须由系统设计统一评估。
FAQ
UDP 可以加密吗？
可以。加密可以由 UDP 之上的协议或应用提供。传输层本身不加密数据，因此安全性必须由其它层实现。
为什么 UDP 端口测试有时没有响应？
许多 UDP 服务只有在请求格式正确时才会回复。没有响应可能意味着端口被过滤、服务未监听，或测试数据包不包含有效的应用数据。
UDP 支持 IPv6 吗？
可以。UDP 可以运行在 IPv4 和 IPv6 之上。传输行为类似，但地址、 防火墙规则和网络配置可能不同。
UDP 数据包可以大于网络 MTU 吗？
可以在 IP 层被分片，但分片会增加丢包风险。许多应用会让数据报保持足够小，以避免分片。
为什么实时应用通常能容忍一定丢包？
因为等待旧数据会产生延迟。实时应用通常更愿意继续使用最新数据，并通过丢包隐藏、预测、缓冲或自适应质量来降低丢包影响。
