首页在实时音视频通信场景里，数据包的加密一直是个微妙的问题。传统的TLS协议工作在TCP之上，握手过程需要多次往返确认，这对延迟敏感的RTC应用来说完全不可接受。UDP虽然快，但缺少加密和身份认证机制。DTLS（Datagram Transport Layer Security）就是在这个背景下出现的。
DTLS本质上是把TLS的安全机制搬到了UDP上，让实时通信既能保持低延迟，又能获得端到端的加密保护。它保留了TLS 1.2的密码学核心：相同的加密套件、证书机制、密钥协商流程，但在记录层和握手层做了针对性改造，让这套安全机制能在UDP这种不可靠传输上正常工作。可以理解为：DTLS = TLS的安全能力 + UDP的传输特性。
一. DTLS解决了什么问题
WebRTC标准强制要求所有媒体流必须加密传输，浏览器不会发送未加密的音视频数据，这个限制直接催生了对DTLS的需求。
UDP是无连接协议，数据包可能乱序、丢失、重复。TLS的握手流程假设数据包按顺序可靠到达，直接套用会失败。DTLS在设计上做了几个关键调整：每个握手消息都带序列号，接收端可以识别并重组乱序到达的分片；握手消息会设置重传定时器，如果在规定时间内没收到响应就重发；记录层增加了显式的序列号字段，用于防重放攻击。
实际传输,DTLS握手通常能在1-2个RTT内完成。第一次握手时，客户端发送ClientHello，服务端回复ServerHello、证书、密钥交换参数等消息，客户端验证证书后发送自己的密钥材料，双方各自计算出会话密钥。后续连接如果使用会话恢复（Session Resumption），可以把这个过程缩短到1个RTT。
二. 密钥协商和加密套件
DTLS支持的加密套件基本继承自TLS 1.2，常见的有ECDHE-RSA-AES128-GCM-SHA256这类组合。ECDHE提供前向保密性，即使长期私钥泄露，历史会话数据也无法被解密。AES-GCM是认证加密算法，同时提供机密性和完整性保护。
密钥协商过程中，双方通过ECDHE算法交换临时公钥，计算出预主密钥（Pre-Master Secret），再结合握手过程中的随机数生成主密钥（Master Secret）。主密钥会派生出多个工作密钥：客户端写入密钥、服务端写入密钥、客户端MAC密钥、服务端MAC密钥。这样双向通信使用不同密钥，即使一方密钥泄露也不会影响另一方。
WebRTC里还有个特殊机制叫DTLS-SRTP。纯粹的DTLS加密所有数据会带来额外开销，而媒体流对延迟极度敏感。DTLS-SRTP的做法是：用DTLS完成握手和密钥协商，但实际的RTP媒体包不走DTLS记录层，而是用协商出的密钥材料派生SRTP密钥，直接在RTP层加密。这样既保证了密钥交换的安全性，又避免了DTLS记录层的协议开销。
三. 证书验证和指纹机制
DTLS握手需要证书，但WebRTC的点对点通信里，浏览器之间不可能有CA签发的证书。实际做法是双方各自生成自签名证书，然后通过信令通道交换证书指纹（Fingerprint）。
信令消息里会携带对端证书的SHA-256哈希值。DTLS握手时，收到的证书会立即计算哈希，跟信令里拿到的指纹对比。只要信令通道本身是可信的（比如通过HTTPS传输），就能确认对端身份。这个机制绕过了传统PKI体系，适应了P2P场景的特殊性。
有个容易踩的坑：证书生成时要设置足够长的有效期。浏览器生成的证书默认有效期通常是30天，如果设备时间不准确，可能导致证书验证失败。生产环境里会把有效期设置为几个月甚至一年，避免因时间偏移引发的连接问题。
四. 与SRTP的配合
RTP本身没有加密能力，SRTP（Secure RTP）是它的安全扩展。SRTP使用AES加密RTP载荷，用HMAC-SHA1验证完整性，但密钥从哪来？这就是DTLS-SRTP要解决的。
DTLS握手完成后，双方使用导出器（Exporter）功能，从主密钥中派生出SRTP的密钥材料。具体过程是调用TLS的PRF（伪随机函数），输入标签”EXTRACTOR-dtls_srtp”和一些上下文信息，输出足够长度的密钥数据。这段数据会被切分为客户端SRTP主密钥、服务端SRTP主密钥、客户端SRTP主盐值、服务端SRTP主盐值。
每个RTP包的加密密钥不是直接用主密钥，而是结合包的SSRC和序列号通过密钥派生函数计算。这样即使某个包的密钥泄露，也不会危及其他包。SRTP还支持密钥滚动（Key Rollback），长时间通话时可以定期更新密钥，进一步增强安全性。
五. 端到端加密的实现
标准DTLS-SRTP只保护客户端到服务器的传输。如果媒体流经过SFU转发，服务器需要解密才能路由，这对远程医疗、金融咨询等场景不够。
声网的端到端加密基于WebRTC Encoded Transform实现。发送端在视频编码后，通过RTCRtpSender获取编码帧，在Transform Stream里插入加密转换器。需要注意的是，VP8视频的关键帧前7字节、非关键帧前3字节必须保留不加密，否则解码器无法识别帧类型。
加密后的帧继续走DTLS-SRTP传输。SFU能解开SRTP层，但RTP载荷已是密文，无法解析实际内容。接收端用RTCRtpReceiver拿到载荷后，应用层解密再送解码器。
六. 性能和开销
DTLS的计算开销主要集中在握手阶段，RSA或ECDSA签名验证、密钥交换都需要非对称加密运算。现代CPU的AES-NI指令集可以硬件加速AES加密，对称加密部分的性能影响不大。实测中，DTLS握手的CPU占用峰值出现在证书验证环节，使用ECDSA证书比RSA证书快30%左右。
会话恢复机制可以跳过完整握手，直接用之前协商的会话参数。浏览器通常会缓存DTLS会话，重连时优先尝试恢复。对于频繁断线重连的移动网络场景，这个优化能明显改善连接建立速度。
数据包层面，DTLS记录头增加13字节，包括类型、版本、epoch、序列号、长度。SRTP的认证标签默认10字节。对于小包（比如音频帧）来说，这个开销占比不小。实际部署时会调整MTU，尽量让加密后的包不超过网络路径的MTU，避免IP分片。
七. 调试和排查
DTLS握手失败的常见原因：证书指纹不匹配、时间不同步导致证书过期、防火墙阻断UDP、MTU过小导致握手消息分片后丢失。抓包时可以用Wireshark的DTLS解析器，它能识别握手消息类型，显示证书链、密钥交换参数等细节。
如果握手卡在某一步，检查重传计时器的设置。默认重传间隔从1秒开始，每次翻倍，上限通常是60秒。网络抖动大的情况下，可能需要调整初始重传间隔或重传次数上限。
Chrome浏览器的chrome://webrtc-internals页面能看到DTLS状态机的转换过程，每个状态的时间戳、收发的握手消息类型都有记录。遇到连接问题时，这是第一个要看的地方。
总结
实时通信的加密需求和传统HTTPS有本质区别，DTLS通过适配UDP的特性，在保证安全的前提下把延迟开销压到了最低。理解它的工作机制，才能在出现问题时快速定位，也才能根据具体场景选择合适的加密方案。
