14、数据通道的安全性与加密：DTLS 握手、SRTP 与 DTLS 的关系、数据通道的加密特性
聊到 WebRTC 的数据通道，很多人第一反应是「哦，就是浏览器之间传数据嘛」。但有个问题你想想看——如果这些数据明文传输，那跟在大街上喊银行卡密码有什么区别？
WebRTC 在设计之初就把安全写进了基因里。数据通道的加密，说白了就是 DTLS 协议在背后撑腰。今天我就带你把这层「安全壳」拆开看看。
14.1 DTLS 握手：数据通道的「门禁系统」
DTLS，全称 Datagram Transport Layer Security。它是 TLS 的 UDP 版本。为什么不用 TLS？因为 WebRTC 的媒体和数据都是跑在 UDP 上的，TLS 是为 TCP 设计的，没法直接用。
DTLS 握手的过程，我习惯把它比作两个人见面互相验明正身：
- ClientHello：发起方说「你好，我支持这些加密套件」
- ServerHello：接收方回复「好的，我们用这套」
- 证书交换：双方互相出示数字证书
- 密钥协商：通过 Diffie-Hellman 算法生成共享密钥
- 完成：握手结束，开始加密通信
关键点：DTLS 握手是在 ICE 连接建立之后、数据通道打开之前完成的。也就是说，你的数据通道还没开始传数据，安全通道已经搭好了。
我在项目中遇到过一个问题：某些网络环境下 DTLS 握手会超时。后来发现是 MTU 太小，DTLS 的握手包被分片了。嗯，这里要注意——DTLS 握手包比普通数据包大，如果网络环境差，建议适当调大 ICE 的 stun 超时时间。
14.2 SRTP 与 DTLS 的关系：一对「双胞胎」
很多人搞不清 SRTP 和 DTLS 到底什么关系。我简单给你捋一捋：
| 协议 | 作用 | 加密对象 | 密钥来源 |
|---|---|---|---|
| DTLS | 握手 + 密钥协商 | 数据通道 | 自身握手产生 |
| SRTP | 媒体流加密 | 音频/视频 | DTLS 握手派生 |
说白了，DTLS 既负责数据通道的加密，也负责为 SRTP 提供密钥。这个机制叫做 DTLS-SRTP。WebRTC 标准里规定：媒体流的加密密钥必须通过 DTLS 握手来派生，不能单独协商。
为什么会这样设计？我个人的理解是——统一密钥管理。你想想看，如果数据通道和媒体流各自搞一套密钥，那维护起来多麻烦。DTLS 一次握手，两份密钥，干净利落。
避坑指南：我曾经调试过一个 bug，视频流能通但数据通道死活连不上。查了半天发现是 DTLS 指纹（fingerprint）不匹配。记住，SDP 里的 fingerprint 字段必须和本地证书的指纹一致，否则握手会失败。
14.3 数据通道的加密特性：到底有多安全？
数据通道的加密，我总结为三个层次：
- 传输加密：所有数据在 UDP 层之上就被 DTLS 加密了，抓包看到的全是乱码
- 端到端安全：密钥只在两端持有，中间节点无法解密
- 防篡改：DTLS 自带消息认证码（MAC），数据被改过就能检测出来
你可能会问：那数据通道和 HTTPS 比哪个更安全？
从加密强度上说，两者都是基于 TLS 的，安全性相当。但数据通道多了一层 P2P 特性——数据不经过服务器中转，减少了中间人攻击的风险。当然，前提是你的信令服务器没有泄露证书信息。
注意：数据通道的加密只保护传输过程。数据到达对端后，如果应用层没有妥善处理（比如明文写入磁盘），那加密就白费了。安全是一个链条，最弱的一环决定整体强度。
14.4 核心逻辑：一张图看懂
下面这张 SVG 图展示了 DTLS 握手、SRTP 和数据通道之间的关系。我建议你多看几遍，把流程刻在脑子里。
14.5 实战中的注意事项
最后，我分享几个实战中容易踩的坑：
- 证书管理：WebRTC 允许自签名证书，但生产环境建议使用受信任的 CA 证书。自签名证书在跨域场景下可能被浏览器拦截。
- 密钥更新：DTLS 支持密钥更新（Key Update），但 WebRTC 实现中很少主动触发。如果你的应用需要长时间保持连接，建议定期重新握手。
- 调试工具：Wireshark 可以解密 DTLS 流量，前提是你有私钥。调试时可以用这个功能验证加密是否生效。
一句话总结：数据通道的安全不是「附加功能」，而是 WebRTC 的内置特性。DTLS 握手是入口，SRTP 是邻居，两者共用一套密钥体系。理解了这个关系，你就能更好地排查连接问题。
好了，关于数据通道的安全加密就聊到这里。下一章我们换个口味，讲讲数据通道的带宽管理与流控——那可是实战中的硬骨头。
公众号:蓝海资料掘金营，微信deep3321