12、数据传输安全：DTLS加密、SRTP与SCTP、如何确保数据传输的机密性与完整性
做WebRTC开发，最容易被忽视的就是安全层。
我记得刚入行那会儿，有个同事把音视频数据直接裸传出去，结果被安全审计打了个大红叉。嗯，从那以后，我对传输安全这块就特别上心。说白了，WebRTC之所以能成为实时通信的事实标准，安全机制功不可没。
今天我们就来拆解一下，WebRTC到底是怎么保证你的数据在传输过程中不被偷看、不被篡改的。
12.1 安全传输的三驾马车：DTLS、SRTP、SCTP
WebRTC的安全体系，可以理解为三层防护：
- DTLS：负责信令和密钥协商，相当于“握手阶段”的保镖
- SRTP：负责音视频媒体的加密，保证你说话的内容只有对方能听懂
- SCTP：负责数据通道的可靠/有序传输，配合DTLS一起工作
这三者不是孤立的。我习惯把它们看作一个流水线：DTLS先建立信任关系，然后SRTP和SCTP各自加密自己的数据流。
核心要点：WebRTC强制使用加密，没有“明文模式”这个选项。这是设计之初就定下的铁律。
12.2 DTLS：握手阶段的守护者
DTLS，全称是Datagram Transport Layer Security。你想想看，它其实就是TLS的“UDP版本”。
为什么需要DTLS？因为WebRTC底层用的是UDP，而标准TLS是为TCP设计的。UDP会丢包、会乱序，TLS那套握手协议在UDP上根本跑不起来。DTLS就是专门解决这个问题的。
我的经验：DTLS握手过程中，如果网络状况不好，可能会反复重传。我曾经在一个丢包率5%的Wi-Fi环境下调试，DTLS握手花了将近3秒才完成。后来加了ICE的nomination策略优化，才把时间压到1秒以内。
DTLS在WebRTC中的主要职责有两个：
- 身份验证：通过证书交换，确认对方就是你要通信的那个人
- 密钥协商：生成后续SRTP和SCTP加密用的密钥
具体流程是这样的：
- 双方交换自签名证书（WebRTC场景下常用）
- 通过Diffie-Hellman算法协商出一个共享密钥
- 用这个密钥派生出SRTP的加密密钥和SCTP的加密密钥
注意：自签名证书在WebRTC里是合法的，因为WebRTC不依赖CA（证书颁发机构）。但如果你要对接第三方服务，可能需要换成CA签发的证书。我在对接一个商业SIP网关时就踩过这个坑。
12.3 SRTP：音视频媒体的加密引擎
SRTP，全称Secure Real-time Transport Protocol。说白了，它就是RTP的加密版本。
RTP本身不提供任何安全机制，谁都能抓包看到你的音视频数据。SRTP在RTP的基础上，增加了加密和完整性校验。
SRTP使用了两把“钥匙”：
| 密钥类型 | 用途 | 算法示例 |
|---|---|---|
| 加密密钥 | 加密RTP负载（音视频数据） | AES-CTR, AES-GCM |
| 认证密钥 | 生成消息认证码（MAC），防止篡改 | HMAC-SHA1 |
这里有个细节：SRTP只加密RTP的负载部分，头部是明文的。为什么？因为中间的网络设备（比如路由器、防火墙）需要读取RTP头部信息来做路由和QoS。如果头部也加密了，这些设备就没办法工作了。
关键点：SRTP的加密密钥是从DTLS握手阶段派生出来的。也就是说，DTLS和SRTP是“父子关系”——先有DTLS的信任，才有SRTP的加密。
12.4 SCTP：数据通道的安全传输
SCTP，全称Stream Control Transmission Protocol。在WebRTC里，它负责DataChannel的数据传输。
你可能会问：SCTP不是传输层协议吗？为什么放在这里讲？
嗯，这是因为WebRTC中的SCTP是跑在DTLS之上的。也就是说，SCTP的数据包先被DTLS加密，然后再通过UDP发送出去。所以，SCTP本身不负责加密，它依赖DTLS来保证安全性。
SCTP在WebRTC中的特点：
- 多流支持：可以同时传输多个独立的数据流，互不干扰
- 可靠/不可靠模式：你可以选择可靠传输（类似TCP）或部分可靠传输（类似UDP）
- 有序/无序模式：数据可以按顺序到达，也可以乱序到达
我的建议：如果你用DataChannel传文件，用可靠+有序模式。如果你传游戏状态或实时消息，用不可靠+无序模式，延迟更低。我在做一个在线协作白板时，就用了不可靠模式，用户体验比可靠模式好很多。
12.5 如何确保数据的机密性与完整性
机密性和完整性，是安全传输的两个核心目标。我们分别来看：
机密性：防止数据被偷看
机密性靠的是加密。WebRTC使用对称加密算法（如AES）来加密数据。对称加密的特点是：加密和解密用同一个密钥。这个密钥就是通过DTLS握手协商出来的。
具体来说：
- 音视频数据：用SRTP的AES-CTR或AES-GCM加密
- DataChannel数据：用DTLS的TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256等密码套件加密
完整性：防止数据被篡改
完整性靠的是消息认证码（MAC）。发送方在数据包后面附加一个MAC值，接收方用同样的密钥计算MAC，如果匹配，说明数据没有被篡改。
SRTP使用HMAC-SHA1来生成MAC。DTLS使用更现代的AEAD（Authenticated Encryption with Associated Data）模式，比如AES-GCM，它同时提供加密和完整性校验。
一句话总结：机密性让你看不到内容，完整性让你改不了内容。两者缺一不可。
12.6 实战中的避坑指南
讲完了理论，我分享几个实际项目中踩过的坑：
我曾经踩过的坑：
- DTLS握手超时：在弱网环境下，DTLS握手可能失败。建议设置合理的超时时间（我一般用10秒），并做好重试逻辑。
- SRTP密钥更新：WebRTC支持密钥更新，但实现起来容易出错。我见过一个案例，密钥更新后接收方没有同步，导致所有后续包都解密失败。
- SCTP缓冲区溢出：如果DataChannel发送速度太快，接收方缓冲区可能溢出。建议使用流控机制，或者设置合理的缓冲区大小。
调试小技巧：用Wireshark抓包时，可以设置DTLS的预共享密钥（PSK）来解密流量。具体做法是在Wireshark的SSL/TLS配置里填入密钥日志文件路径。这样你就能看到加密后的数据长什么样了。
12.7 小结
WebRTC的安全体系，说白了就是“层层加密，环环相扣”。DTLS负责握手和密钥协商，SRTP负责音视频加密，SCTP依赖DTLS保证数据通道安全。三者配合，才实现了真正的端到端安全。
我个人觉得，理解这套机制最好的方式就是动手抓包看看。你打开Wireshark，过滤一下DTLS和SRTP的包，亲眼看看加密前后的数据差异，比看十篇文章都管用。
公众号:蓝海资料掘金营，微信deep3321