企业官网建设流程全解析

做 WebRTC 网关调试的时候，最难缠的往往不是媒体通道，而是 DTLS。握手超时、证书指纹不对、角色协商僵住、UDP 一丢包就整个卡死，这些 BUG 我在项目中几乎全踩过一遍。这篇文章不聊理论书上的概念，只讲我在实际项目里怎么定位、怎么修，以及修完之后沉淀下来的一套排查方法。如果你也在做 SFU、自定义客户端、或者只是想搞懂 WebRTC 里的 DTLS 为什么这么容易出问题，这篇笔记应该能帮你少走不少弯路。

1. 先搞清楚 DTLS 在 WebRTC 里到底干了什么

1.1 它在整个链条里的位置

WebRTC 的媒体面默认走 UDP，数据通道（DataChannel）也走 UDP，但 UDP 本身既不可靠、也不安全。DTLS 就是为 UDP 这类不可靠传输设计的 TLS 版本，它的核心任务有两个：第一，对端身份认证；第二，协商出一套对称密钥，然后把密钥交给 SRTP 去加密媒体流、交给 SCTP 去保护数据通道。

用个生活化的类比：TLS 是你在浏览器里和网站建立 HTTPS 连接时，先“亮证”、再“商量密码本”的过程；DTLS 把同一套过程搬到了 UDP 上，只是每一步都可能丢包、乱序，所以状态机里多了一大堆重传和缓存逻辑。WebRTC 里的 DTLS 连接建立在 ICE 连通之后，也就是说，先打洞打通了 UDP 通路，然后在这个通路上做 DTLS 握手，握手成功后才开始传音视频和数据。

这个顺序很重要，我见过不少人一上来就在抓 DTLS 超时，结果回头一看 ICE 根本没连通，DTLS 当然不可能成功。排查的时候一定要先确认 ICE 状态是 connected 或 completed，再去看 DTLS。

1.2 握手的状态机，以及 WebRTC 独有的两个坑

DTLS 握手本身的状态机，跟 TLS 很像：

1. 客户端发 ClientHello。
2. 服务端回 HelloVerifyRequest，里面带一个 cookie，目的是防 DoS。
3. 客户端再发一次带 cookie 的 ClientHello。
4. 服务端回 ServerHello、Certificate、ServerKeyExchange、ServerHelloDone。
5. 客户端回 ClientKeyExchange，然后双方各发 ChangeCipherSpec 和 Finished。

其中第 2 步和第 3 步是 DTLS 特有的，UDP 没有连接概念，服务端必须先确认“你是真实客户端，不是伪造源地址的洪水”，所以需要 cookie 机制。很多自定义实现为了省事，把 cookie 环节砍了，这在公网环境很容易被扫描和攻击，但在 WebRTC 场景里因为 ICE 已经做了双向校验，所以部分实现也接受跳过 cookie 校验。理解这一点，有助于你在看日志时不会被“客户端发了两次 ClientHello”搞糊涂。

WebRTC 独有的第一个坑是角色协商。SDP 里有a=setup属性，常见值有actpass、active、passive。offer 方通常写actpass，answer 方根据自己能力选active或者passive。active意思是“我主动发起 DTLS 连接”，passive意思是“我等你来连”。问题在于，如果商量的结果两边都觉得自己是active，就会出现双方都在等对方先发 ClientHello 的僵局。这种僵局在日志里看起来像“握手超时”，但其实双方都活着，只是没人开口。

第二个坑是 WebRTC 的 DTLS 握手必须验证证书指纹。普通 TLS 是验证证书链是否由受信任的 CA 签发，WebRTC 不搞 PKI，它直接在 SDP 里带一个a=fingerprint:sha-256 xx:xx:xx...，握手时拿对端实际证书的指纹和 SDP 里的指纹作比对。这个机制的好处是省去 CA，坏处是一旦 SDP 被重写、指纹没同步更新，或者证书每次启动都重新生成，指纹就必然对不上。

2. 我遇到的 DTLS BUG 清单，每个都有根因

2.1 握手一直挂起，谁都不先开口

这是我最早遇到的，也是最隐蔽的一个问题。症状是两端 ICE 都连通了，但 DTLS 状态一直停在connecting，日志里只有零星的 ClientHello 重传，没有任何 Certificate 消息。

查到最后发现是角色协商问题。a 端用的是某个开源库，setup写死成active；b 端自定义实现里也写成了active，并且没有解析远端 SDP。结果两边都等着对方先发 ClientHello。后来我查了标准，也看了更多实现，基本结论是：offer 方应当写actpass，answer 方要么写active要么写passive，并且一定要根据对端setup值来选择，不能写死。如果遇到两边都是active的情况，标准里还有一个破局规则，就是让 ICE 的 controlling 方作为 DTLS 客户端。但我的建议是别依赖这种兜底，干脆在 SDP 协商阶段就保证一个active对passive。

2.2 指纹对不上：SDP 是你的、证书是我的

有一个非常典型的报错：Fingerprint does not match。我当时在一个跨平台项目里，客户端用的是系统自带的 WebRTC 栈，服务端自研，两边每次建立连接都会各自生成一个新的自签名证书。问题出在某层代理上，代理重写了 SDP 但不重新计算指纹，于是服务端收到的 SDP 里指纹是旧的。

这个 BUG 排查起来很费劲，因为不是每次都失败，只有经过特定代理的路径才失败。后来我在服务端把收到的 SDP 原样打印出来，再去比对实际证书指纹，一眼就发现了不一致。处理办法有两个层面：第一，让代理在改写 SDP 时必须同步重算指纹；第二，端侧做更友好的错误上报，把“远端提供指纹”和“我方证书指纹”都写进日志。指纹对不上时千万不要只回一个DTLS Error，这种信息对排查毫无帮助。

2.3 没做重传处理，UDP 一丢包就卡死

另一个让我印象深刻的问题：在弱网环境里 DTLS 握手成功率极低，但不是加密算法问题，而是 DTLS 的重传机制没实现好。DTLS 和 TCP 不一样，TCP 有内核帮忙重传，DTLS 完全靠应用层自己定时重发。标准建议超时时间从 1 秒开始，每次重传翻倍，同时引入抖动。有些实现图省事，把超时写死成固定值，或者重传次数太少，结果公网环境下只要丢一个 ClientHello 或 Certificate 分组，握手就卡死。

我在自己的服务端里做过一个对照实验：用固定 1 秒重传 3 次，弱网环境下失败率很高；改成指数退避、初始 1 秒、最大 10 秒、重传 8 次之后，成功率显著提升。更细一点，还要区分“握手消息”和“应用数据”的重传策略，握手消息的优先级要更高，因为握手不完成，后面什么都走不了。

2.4 握手消息太大，被 MTU 分片干趴

这个问题相对少见，但遇到了会非常头疼。我接手过一个服务端模块，证书链里塞了根证书和中间证书，整个 Certificate 消息超过 2KB。公网链路的 MTU 通常是 1500 字节，大消息会被 IP 层分片，而 UDP 分片里只要丢一片，整个数据报就废了。TCP 遇到这种情况会重传，UDP 不会，于是 DTLS 层一直收不到完整消息，握手卡在中间阶段。

解决思路有几个：一是减少证书链，只传叶子证书，因为 WebRTC 本来就不依赖 CA 信任；二是如果你必须用证书链，就要在创建 DTLS 连接时设置合理的 MTU 提示，让消息在 DTLS 层主动分片而不是依赖 IP 层分片；三是干脆换更小的公钥算法。这个问题的典型特征是：抓包看到 IP 分片，且永远只有部分分片到达对端。

2.5 ICE restart 之后，DTLS 连接“留着还是重来”的尴尬

还有一个场景让我印象很深：移动端网络切换触发 ICE restart，媒体恢复了，但数据通道始终打不开。查了半天才发现，两端在 ICE 重启后还在复用旧的 DTLS 连接状态，但底层 5 元组已经变了。按标准语义，ICE restart 后如果传输地址发生变化，就应该建立新的 DTLS 连接，但很多实现做了“优化”，试图保留旧连接。

这种优化在某些情况下确实能加速恢复，但一旦对端实现没有同步做同样的处理，就会出现半开连接：一方认为 DTLS 还用旧的，另一方已经在新地址上等握手了。我的经验是，默认走标准流程，ICE restart 且传输地址变化时，直接触发 DTLS 重协商或重置连接状态。至于“复用旧密钥”这类优化，除非你能完全控制两端，否则别碰。

2.6 数据通道打不开，但媒体正常，别急着怪 DTLS

这个其实不算 DTLS 的 BUG，但容易误判。有一次我遇到媒体收发正常、数据通道连不上的情况，第一反应是 DTLS 出了问题。后来冷静分析：SRTP 的密钥和 SCTP 的密钥都来自 DTLS 握手导出的主密钥，媒体既然能解密，说明 DTLS 握手已经成功，问题几乎可以确定是在 SCTP 层，而不是 DTLS。

常见的原因包括 SCTP 端口号不一致、流数配置不匹配、或者 DataChannel 的 open 消息没有按序到达。所以以后遇到“音视频通了，数据通道不通”，不用再去抓 DTLS 握手包，直接查 SCTP 关联状态和 DataChannel 协议消息就行。

3. 排查工具与定位方法：别再用眼睛调 BUG 了

3.1 日志等级和关键字段

DTLS 调试最怕的就是日志里只有一个handshake failed，连哪一步失败都没说。我自己的习惯是，日志至少要打到下面这个粒度：

• 每次收到或发送握手消息时，记录消息类型和序号。
• 记录 SDP 中的setup值、actual 角色（client 还是 server）。
• 记录本地证书指纹和远端 SDP 里的期望指纹。
• 记录握手超时参数和当前重传次数。
• 记录底层 ICE 状态变化。

在代码层面，如果你用的是 OpenSSL 或者 BoringSSL，可以打开SSL_CB_HANDSHAKE回调，把每个状态机的变化打出来。libwebrtc 里可以设置日志级别到 verbose，能看到DTLS相关的内部日志。调日志级别这步看起来笨，但绝大多数疑难杂症最后都是靠日志定位的，不要一上来就上抓包。

3.2 Wireshark 抓包：看到比日志更真实的东西

当日志不足以说明问题时，抓包是唯一能还原现场的方式。Wireshark 对 DTLS 的支持已经比较成熟，过滤dtls || stun || rtp就可以看到同一端口上混杂的包。这里有个需要注意的点：因为 STUN、DTLS、SRTP 共用同一个 UDP 端口，Wireshark 可能把一个 DTLS 握手包误判成 STUN 包，这种情况下需要右键“Decode As”选择 DTLS。

如果要做深度解密，Wireshark 支持 DTLS 的密钥导出。你可以在偏好设置里配置 DTLS 端口和私钥，或者使用 SSLKEYLOGFILE。服务端是自己实现的话，可以给 SSL_CTX 设置 keylog 回调，把客户端随机数、主密钥写进文件，然后 Wireshark 里就能看到明文的应用数据。对于排查“握手到底停在哪一步”这类问题，不需要解密，光看消息类型就够了；但如果你怀疑两端密钥不一致，解密后对比 SRTP 保护头，能快速判断问题出在密钥导出还是媒体封装。

3.3 用 OpenSSL 做一个裸 DTLS 服务端/客户端做对照实验

有时候问题不在协议，而在于你自己的实现细节。这种情况下，我强烈建议把 DTLS 从 WebRTC 里剥出来做对照实验。

用 OpenSSL 的命令行工具起一个裸的 DTLS 服务端，监听某个 UDP 端口，然后用客户端去连接。这个实验可以验证很多事情：你的证书和私钥是否匹配、你用的加密套件是否被对端支持、你的 cookie 校验逻辑是否正常。命令行大概是这个风格：

openssl s_server -dtls1_2 -accept 127.0.0.1:4433 -cert cert.pem -key key.pem -msg -state openssl s_client -dtls1_2 -connect 127.0.0.1:4433 -msg -state

-msg和-state这两个参数会把握手状态机打出来，能直观看到卡在哪一步。如果裸的 OpenSSL 服务端能被正常连上，但你的 WebRTC 客户端连不上，问题基本就在 SDP 协商或者指纹校验；如果裸连也失败，那问题就在证书、加密套件或者网络路径上，优先排查这三个方面。

4. 端到端排查框架与速查表

4.1 四要素检查法

调试多了之后，我总结了一个“四要素检查法”，每次 DTLS 出问题都按这个顺序过一遍，能省不少时间。

第一是协商。查看 SDP 里的setup值，确认两端角色互补。主动方为active，被动方为passive，若出现两端都active或都passive，先解决角色问题。

第二是凭据。确认 SDP 里的指纹格式正确，且与实际证书指纹一致。特别注意 SDP 经过代理、网关、SFU 转发后指纹是否被正确改写，这是最容易忽略的环节。

第三是传输。确认 ICE 状态已经连通，UDP 端口能互相访问。同时检查 NAT 或防火墙是否拦截了 ICMP，因为 ICMP 被拦截虽然不影响 UDP 本身，但会导致路径 MTU 发现失效，间接引发分片问题。

第四是状态机。确认重传参数合理，cookie 机制正常，握手消息序号连续。如果抓包里出现了很多重复的同一序号消息，说明对端没有正确应答，问题可能在消息解析或状态推进逻辑上。

4.2 症状对照速查表

我整理了一个速查表，方便团队里的同学按图索骥：

这个表不是万能药，但能把排查范围从“整个协议栈”缩小到“某一个环节”，对团队协作特别有用。

4.3 测试环境建议

要真正把 DTLS 的隐患在开发阶段就暴露出来，建议至少准备三类测试环境。第一是模拟丢包环境，可以用系统自带的网络损耗工具，或者直接在服务端入口对 UDP 包做随机丢弃，重点关注握手阶段的丢包恢复能力。第二是小 MTU 环境，把两台机器之间的 MTU 调低到 1280 甚至更低，验证握手消息的分片处理。第三是证书异常环境，人为生成过期证书、指纹不一致证书、证书链过长证书，确保客户端能给出清晰的错误信息，而不是卡死在连接状态。

这些环境一开始搭建会花点时间，但对比在真实用户环境里去排查，这点投入太值了。

5. 避坑实操记录

5.1 一次让我翻车的证书链排查

说一个具体的案例。某次在客户环境里做联调，服务端总是报握手失败，客户端日志只显示DTLS error。因为两边代码都是自己人写的，不存在指纹被改写的问题，所以我一度怀疑是加密套件不兼容。

后来抓包发现，客户端发了 ClientHello，服务端回了 HelloVerifyRequest，客户端也重新发了带 cookie 的 ClientHello，但服务端没有继续回 ServerHello。再仔细看，服务端的日志里有一条非常不起眼的警告：证书链无法构建。原来是客户环境的根证书证书库和测试环境的库不一样，服务端在发送证书的时候做了链校验，而 DTLS 客户端根本不需要完整的链，它只认 SDP 里的指纹。

最后处理方式很简单：服务端发送证书时关闭链校验，或者只传叶子证书。但从那以后，我只要看到“服务端不回 ServerHello”这个现象，第一反应就是去查证书加载和链构建，而不是调加密算法。

5.2 写码时的几个习惯

如果让我给正在写 DTLS 相关代码的人三条建议，我会说：第一，永远在合适的地方设定握手超时和重传参数，不要用默认值就上线，默认值往往不适合公网环境；第二，证书、私钥、指纹的加载必须走统一的配置入口，不要在代码里散落生成逻辑，否则你会在指纹问题上反复踩坑；第三，把所有失败分支都打出具体原因，哪怕只是SSL_get_error的返回值，也要记到日志里，later 排查能救命。

另外，如果你是在 libwebrtc 里定制 DTLS 行为，改动之前先确认你清楚每个上下文的调用线程。DTLS 的回调经常发生在网络线程，直接在里面做耗时操作或者加锁，很容易引发死锁或超时。我见过一个案例，开发者在握手回调里做了一次 DNS 查询，导致握手卡了几秒钟，看起来就像是 DTLS 超时。

5.3 最后一个建议

调试 DTLS 和调试 WebRTC 其他模块不太一样，它本身不复杂，但它叠加了 UDP 的不可靠性、SDP 的协商语义和 ICE 的状态依赖，所以一旦出错，表象往往很有迷惑性。我的体会是：不要凭感觉改配置，每次改动前先抓包、打日志、确认当前状态，改完再看结果。

如果你刚开始接触 DTLS，建议先自己写一个最小的握手 demo，让两端用自签名证书跑通，然后再叠加指纹校验、SDP 协商、ICE 衔接，每加一层就验证一次。把这个流程走通之后，再回头看那些“难缠的 BUG”，其实大部分都是角色、指纹、重传、MTU 这几个老问题在不同场景下的变体。把这些根基打牢，比收藏一百个排错模板都管用。