UDP 首部格式

• 源端口：源端口号。在需要对方回信时选用。不需要时可全为０
• 目的端口：目的端口号。这在终端交付报文时必须要使用到
• 长度：UDP 数据包的长度 (包括首部和数据)，其最小值是 8 (仅有首部)
• 校验和：检测 UDP 数据报在传输中是否有错。有错就丢弃。该字段是可选的，当源主机不想计算校验和，则直接令该字段全为 0

UDP 优点

• UDP 无需建立连接。因此 UDP 不会引入建立连接的时延。试想如果 DNS 运行在 TCP 之上而不是 UDP，则 DNS 的速度会慢很多。HTTP 使用 TCP 而不是 UDP，是因为对于基于文本数据的 Web 网页而言，可靠性是至关重要的
• 无连接状态。TCP 需要在端系统中维护连接状态。此连接状态包括接收和发送缓存、拥塞控制参数和序号与确认号的参数。而 UDP 不维护连接状态，也不跟踪这些参数。因此，某些专用应用服务器使用 UDP 时，一般都能支持更多的活动客户机
• 分组头部开销小。TCP 有 20 字节的首部开销，而 UDP 仅有 8 字节的开销
• 应用层能更好地控制要发送的数据和发送时间。UDP 没有拥塞控制，因此网络中的拥塞也不会影响主机的发送效率。某些实时应用要求以稳定的速度发送，能容忍一些数据的丢失，但不允许有较大的时延，而 UDP 正好满足这些应用的需求

• UDP 常用于一次性传输比较少量数据的网络应用中，如 DNS、SNMP 等，因为对于这些应用，若采用 TCP，则将为连接创建、维护和拆除而带来不小的开销。
• UDP 也常用于多媒体应用（如 IP 电话、实时视频会议、流媒体等），显然，可靠数据传输对于这些应用来说并不是最重要的，但 TCP 的拥塞控制会导致数据出现较大的延迟，这是它们不能容忍的
• UDP 提供尽最大努力的交付，即不保证可靠交付，但这并不意味着应用对数据的要求是不可靠的，因此所有维护传输可靠性的工作需要用户在应用层来完成。应用实体可以根据应用的需求来灵活设计自己的可靠性机制
• UDP 是面向报文的。发送方 UDP 对应用层交下来的报文，在添加首部后就向下交付给 IP 层，既不合并，也不拆分，而是保留这些报文的边界；接收方 UDP 对 IP 交上来的 UDP 用户数据包，在去除首部后就原封不动地交付给上层应用进程，一次交付一个完整的报文。因此报文不可分割，是 UDP 数据包处理的最小单位