首页/网络/协议速查/UDP 用户数据报协议总览
TCP 与 UDP54 条

UDP 用户数据报协议总览

无连接、不保证可靠、保留报文边界的最小传输层协议:头部仅 8 字节,开销小、延迟低,适合 DNS、音视频、QUIC、监控等场景。

协议速查网络更新于 2026-10-13

UDP 是什么

UDP 是最小的传输层协议:无连接、不保证可靠、不保证顺序,但完整保留消息边界,一次发送对应一个报文。它的头部只有八个字节,开销小、延迟低,因此适合短请求应答、实时音视频、以及自身能容忍丢失或能自行重试的业务。它不负责重传与拥塞控制,这些能力要么由使用它的协议在上层实现,要么由应用自己承担。

基本信息

特性无连接、不可靠、无序、保留消息边界
报文头八个字节,包含源端口、目的端口、长度与校验和
适合场景短请求应答、实时流、可自行重试或可自愈的业务
不适合场景要求不丢字节的业务数据
可靠性由上层协议或应用自己实现

典型使用场景

  • 域名解析:一次问答即可完成,重试由客户端负责
  • 实时音视频:丢几帧可以接受,重传反而增加延迟
  • 时间同步:短小的请求应答模式
  • 监控与日志上报:允许少量丢失,优先低开销
  • 代理与隧道协议:把可靠性与拥塞控制放到上层实现

查看数据报套接字

查看数据报套接字
ss -uanp   # 查看数据报套接字的连接与进程
ss -lunp   # 只看处于监听状态的套接字
netstat -su | grep -i error   # 观察接收错误与缓冲溢出统计
# 排查丢包时同时看应用计数与内核统计,两者对不上说明卡在套接字缓冲区

与连接式协议对比

对比项连接式协议本协议
连接状态需要建立与关闭无连接,直接发送
可靠性确认重传保证有序不保证,可能丢失与乱序
消息边界不保留,应用需自行定帧保留,一次对应一个报文
头部开销较大很小
拥塞控制内置没有,需要上层实现

排查要点

  • 应用发送成功只代表交给了内核,不代表对端收到,排障要两端同时看计数
  • 接收缓冲区偏小时丢包发生在内核,抓包看到收到了包但应用没处理,容易误判
  • 公网暴露的数据报服务要做好来源校验,避免被用作流量放大
「发出去」只代表数据交给了内核:丢包、乱序、重复都可能发生,都要由应用层自己兜底。如果业务需要不丢字节,请使用连接式协议或在上层实现确认与重传。
无连接意味着源地址可以被伪造:公网暴露的数据报服务极易被当作流量放大器用于攻击第三方。这类服务应限制响应体积并校验来源,尽量只在内网或加白名单后开放。

易错点

  • 认为发送成功就等于送达,业务侧缺少超时与重试导致静默丢数据
  • 接收缓冲区过小造成内核丢包,抓包能看到但应用计数为零,排查方向被带偏
  • 把数据报服务直接暴露在公网,被用作流量放大器攻击他人
  • 用数据报承载需要严格有序的大数据流,应用层不得不重造一整套可靠性机制

数据来源与参考

  • RFC 768(UDP)
  • RFC 9293 §1.5(UDP 定位)

相关工具

​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌