WebRTC中DTLS协商应何时启动？候选提名时机疑问

核心结论 #

DTLS协商不需要等待候选提名完成，甚至会在ICE候选收集的过程中就启动——这完全符合WebRTC的设计逻辑，也是Chrome等主流实现的标准行为。

为什么不等候选确定就启动DTLS？ #

• ICE与DTLS解耦设计：WebRTC把路径发现（ICE）和安全传输（DTLS）拆分为两个独立并行的流程，目的是减少端到端连接的总耗时。ICE负责找到可用的传输路径，DTLS负责给路径加密，两者没必要串行执行。
• DTLS适配UDP路径切换：DTLS基于UDP实现，天生支持路径切换。即使一开始用主机候选发送Client Hello，后续ICE切换到中继候选（TURN）或反射候选（STUN），DTLS握手可以在新路径上继续完成——只要两端能交换握手报文，不管走哪个候选对，握手状态都会同步。
• 提前抢占时间窗口：等ICE完全确定最优候选对再启动DTLS，会额外增加握手等待时间。提前启动的话，往往ICE选好路径时，DTLS已经完成握手，能立刻进入媒体传输阶段。

实现时的具体建议 #

自己实现WebRTC栈时，不需要等ICE的候选提名完成信号（比如selected-candidate-pair事件）再初始化DTLS：

1. 当本地SDP协商完成、开始收集ICE候选后，就可以初始化DTLS上下文（生成密钥、配置证书）。
2. 每收集到一个新的ICE候选，就尝试用该候选发送DTLS Client Hello及后续握手报文。
3. 处理DTLS握手的多路径兼容：可能多个候选路径都在传输握手包，只要其中一个路径完成握手，就可以绑定该候选对作为后续媒体传输的安全通道；其他路径的握手报文可以直接忽略。

内容的提问来源于stack exchange，提问作者Usama