基于Bouncy Castle的客户端与Chrome之间DTLS握手延迟问题排查

多Server Hello的常见原因 #

• DTLS版本协商不兼容：Chrome支持DTLS 1.0/1.2/1.3，若你的Client Hello未明确指定兼容版本或版本列表有误，Chrome会依次发送不同版本的Server Hello尝试匹配。比如客户端仅支持DTLS 1.2，但Hello里未正确标识，Chrome先发1.3版本的Server Hello，未收到响应后再发1.2版本，导致多轮发送。
• 扩展字段缺失或不匹配：WebRTC DTLS依赖SRTP加密套件、ALPN、ICE等特定扩展。若Client Hello未携带这些扩展，或扩展内容不符合Chrome预期，Chrome会发送带不同扩展组合的Server Hello，尝试协商出兼容配置。比如SRTP套件列表未包含Chrome支持的选项，就会触发多次协商。

多轮Change Cipher Spec与2秒延迟的关联因素 #

• 握手消息确认不及时：DTLS基于UDP，需可靠确认每个握手消息。若客户端未及时发送ACK，或Chrome未收到确认，会触发额外的握手消息发送（非重传，而是重新发起协商分支）。比如收到Server Hello后未及时回复Client Key Exchange，Chrome会认为协商停滞，继续发送后续消息。
• Bouncy Castle状态机配置问题：Bouncy Castle的DTLS实现需正确配置握手超时、重传策略及状态回调。若未设置合理的超时时间，或未正确处理DTLSHandshakeListener的回调，会导致客户端响应滞后。比如状态机卡在某个阶段，未及时触发后续消息发送，拖慢整个握手流程。
• 密钥协商效率低下：若客户端生成密钥对（如ECDH）时未优化，比如使用大尺寸密钥且无硬件加速，会导致密钥生成耗时过长，Chrome等待响应超时后重复发送消息，增加整体延迟。

排查建议 #

• 对比标准握手流程：正常WebRTC DTLS握手流程为：Client Hello → Server Hello → Server Certificate → Server Key Exchange → Server Hello Done → Client Key Exchange → Client CCS → Client Finished → Server CCS → Server Finished。用Wireshark抓包对比，定位哪一步出现重复或停滞。
• 校验Client Hello内容：检查Client Hello中的DTLS版本、加密套件、扩展字段是否与Chrome要求一致。可对比Firefox等标准WebRTC客户端的Hello包，找出差异。
• 调试Bouncy Castle状态机：在客户端代码中添加日志，跟踪每一步握手消息的接收与发送，确认收到Server Hello后是否及时触发后续响应，排查状态机是否存在卡顿。
• 调整DTLS参数：强制指定DTLS版本为1.2（WebRTC主流版本），设置合理的握手超时时间，关闭不必要的重传策略，减少协商来回。

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