真实世界的 UDP：WebRTC 和 DNS 如何使用快速但不可靠的协议

UDP 在设计上可能比较轻量级且 “不可靠 ”，但这并没有阻止开发人员在其基础上构建强大的系统。在本文中，我们将了解 WebRTC 和 DNS 这两项关键技术是如何成功使用 UDP 并将其局限性转化为优势的。

WebRTC：通过 UDP 进行实时通信

什么是 WebRTC？

WebRTC 是一种允许直接在浏览器中进行点对点通信的技术。想想 Google Meet 上的视频通话、Discord 语音聊天或屏幕共享，所有这些都由 WebRTC 支持。

为什么 WebRTC 使用 UDP？

实时通信不能等待重传。丢弃几个视频帧或音频样本总比暂停重试要好。UDP 允许低延迟传输，非常适合实时语音、视频和数据。

但仅用 UDP 还不够，因此 WebRTC 使用了辅助协议：

• ICE（交互式连接建立）： 尝试多种网络路径并选择最有效的路径。
• STUN（用于 NAT 的会话遍历实用程序）： 帮助设备发现其公共 IP 和端口映射。
• TURN（使用 NAT 中继的会话遍历）：当对等网络连接时，通过服务器中继流量： 当点对点失败时，通过服务器中继流量。
• SRTP（安全 RTP）： 通过 UDP 对媒体进行加密，以保证其安全。

WebRTC 本质上是在 UDP 的基础上建立一个可靠、安全的系统，并在必要时定制重传和抖动缓冲。

VoIP 和在线游戏：延迟是敌人

VoIP（Voice over IP）和多人在线游戏是 UDP 的另外两个主要用例。这些应用对延迟的要求极低，但能容忍一定程度的数据包丢失。

为什么 UDP 非常适合这些应用？

• VoIP：错过一个音节总比等待重试要好。UDP 可确保语音流保持畅通。
• 游戏：跳跃、射击或移动等操作必须实时进行。即使错过一次更新，下一次更新也会很快到来。

与 WebRTC 一样，这些系统通常使用 STUN、TURN 和 ICE 等 NAT 遍历技术在玩家或参与者之间建立连接。

有些游戏引擎甚至在 UDP 的基础上实施自定义的可靠性机制，只重新发送关键数据（如命中注册），让非关键更新（如玩家位置）自由流动。

了解 NAT 类型及其重要性

当两台设备位于 NAT（网络地址转换）之后时，点对点通信会变得棘手。NAT 的类型会极大地影响连接成功率。

常见的NAT类型：

• 全锥型 NAT：最容易连接。一旦端口开放，任何人都可以向该端口发送数据。
• 限制锥型 NAT：仅允许内部主机首先联系的 IP 做出响应。
• 对称 NAT：最严格。只有精确的外部 IP:端口对才能响应。每个出站请求使用唯一的映射。

为什么这很重要：

• 对称 NAT 经常会中断点对点连接。这时，TURN 服务器就变得必不可少，可以充当中继。
• STUN 适用于锥形 NAT，但在对称场景中失败。

在构建或排除点对点 UDP 应用程序故障时，了解 NAT 类型至关重要。

DNS：使用 UDP 快速解析名称

什么是 DNS？

域名系统 (DNS) 将类似 openai.com 这样的域名转换成 104.20.21.46 这样的 IP 地址。

DNS 为什么使用 UDP？

• DNS 查询很小（通常小于 512 字节）
• 这是一个简单的请求/响应模型
• 使用 UDP 可以避免建立 TCP 连接的开销

如果 UDP 失败怎么办？

• 对于较大的响应（例如 DNSSEC），DNS 会回退到 TCP
• 当响应被截断或涉及安全扩展时，也会使用 TCP

DNS 充分利用了 UDP 的速度，同时仍然具有安全网。

图解：使用 STUN/TURN/ICE 的 P2P 设置

以下是点对点通信如何与 NAT 遍历协同工作的简要概述：

• Peer 使用 STUN 发现其公共 IP/端口。
• ICE 协调连接尝试。
• 如果直接连接失败，则通过 TURN 中转流量。

这种方法可实现基于 UDP 的实时连接，即使两个 Peer 都位于严格的 NAT 后面。

总体情况

WebRTC、VoIP、游戏和 DNS 向我们表明，UDP 并没有问题，只是不完整。但通过一些巧妙的分层，它成为了以下应用的基础：

• 实时通信
• 快速查找
• 灵活、可扩展的互联网应用

通过了解 WebRTC 和 DNS 等系统如何克服 UDP 的限制，您可以更自信地设计自己的网络应用程序。

UDP 为您提供原始、快速、简洁的通信。但要使其投入生产，您需要：

• 处理 NAT
• 保护您的数据
• 处理丢失或无序的数据包
• 监控您的流量

这正是 WebRTC、VoIP、在线游戏和 DNS 等协议所做的 —— 而且它们做得非常出色。

作者：Prateek Kumar