在 VoIP、WebRTC、实时音视频等系统中我们经常需要同时解决两个问题数据要实时传输不能因为可靠性机制产生太大的延迟数据传输又必须保证安全防止窃听、篡改和伪造对于基于 TCP 的通信通常可以使用 TLS但对于基于 UDP 的实时通信TLS 并不适用。这就是DTLSDatagram Transport Layer Security的作用。DTLS 可以理解为针对 Datagram数据报通常是 UDP设计的 TLS。它在尽可能保留 TLS 安全能力的同时适应 UDP 的无连接、无序、可能丢包等特性。1. 什么是 DTLSDTLS 全称是Datagram Transport Layer Security中文通常称为数据报传输层安全协议DTLS 的主要目标是在 UDP 等数据报协议之上提供类似 TLS 的安全能力包括身份认证数据加密数据完整性保护防止数据被篡改防止重放攻击可以简单理解为TCP │ └── TLS │ └── HTTPS UDP │ └── DTLS │ └── 安全的实时通信因此DTLS 并不是一种新的加密算法而是一个安全传输协议。2. 为什么 TLS 不能直接用于 UDP理解 DTLS 最重要的一点就是理解 UDP 和 TCP 的区别。TCP 本身具有有连接有序传输丢包重传流控制拥塞控制例如TCP Packet 1 Packet 2 Packet 3 Packet 4如果 Packet 2 丢失Packet 1 Packet 2 ← lost Packet 3 Packet 4TCP 会等待 Packet 2 重传。对于文件下载来说这非常合理。但是对于实时音频Audio 1 Audio 2 Audio 3 Audio 4 Audio 5如果 Audio 2 丢失等它几百毫秒以后重新传回来Audio 3、4、5 早就播放过去了。因此实时通信通常更倾向于UDP RTP而不是TCP RTP问题是TLS 是建立在可靠的字节流传输之上的。典型结构Application │ TLS │ TCP │ IP而 UDP 是Application │ UDP │ IPUDP 不保证数据一定到达数据按照顺序到达数据只到达一次因此需要一个专门适配 UDP 的安全协议这就是 DTLS。3. DTLS 的协议栈位置DTLS 位于应用层和 UDP 之间。例如Application │ DTLS │ UDP │ IP如果用于 WebRTC通常可以看到Application │ ├── DTLS │ ├── SRTP │ └── SCTP │ UDP其中一个非常重要的概念是DTLS 本身通常不是直接用来传输 RTP 音频数据的。在 WebRTC 中DTLS 的一个重要作用是通过 DTLS-SRTP 完成 SRTP 密钥协商。也就是说DTLS │ └── 协商 SRTP Key │ ▼ SRTP │ ▼ RTP Media这也是 VoIP/WebRTC 工程师经常遇到 DTLS 的原因。4. DTLS 和 TLS 的关系DTLS 并不是完全重新设计了一套安全协议。它大量继承了 TLS 的设计。例如CertificatePublic KeyPrivate KeyCipher SuiteHandshakeAuthenticationEncryptionMAC / AEADSession Key因此可以粗略理解为TLS │ ├── TCP │ └── Reliable Stream DTLS │ ├── UDP │ └── Unreliable Datagram最大的区别不是“加密算法不同”而是DTLS 必须处理 UDP 的丢包、乱序和重复问题。5. DTLS 最核心的问题UDP 不可靠假设 DTLS Handshake 发送ClientHello由于 UDP 不可靠Server 可能根本没有收到。因此 DTLS 必须增加一些机制来处理这种情况。例如Client Server ClientHello ─────────────────────── X packet lost ClientHello ─────────────────────── ServerHello ───────────────────────DTLS 会对某些 Handshake 消息进行重传。所以UDP ↓ 可能丢包 ↓ DTLS Handshake retransmission ↓ 保证 Handshake 最终完成但是这里需要注意DTLS 并不会把 UDP 变成 TCP。它只针对 DTLS 自己的协议消息提供必要的可靠机制。应用数据仍然保持 Datagram 的特性。6. DTLS HandshakeDTLS 最重要的过程就是 Handshake。一个简化的流程可以理解为Client Server ClientHello ─────────────────────────────── ServerHello Certificate ServerKeyExchange ServerHelloDone ─────────────────────────────── ClientKeyExchange ChangeCipherSpec Finished ─────────────────────────────── ChangeCipherSpec Finished ───────────────────────────────实际版本和 Cipher Suite 不同消息流程会有所变化。Handshake 的核心目标主要有三个6.1 协商协议参数例如DTLS Version Cipher Suite Extensions6.2 身份认证通常通过Certificate确认通信双方的身份。6.3 生成 Session Key最终双方需要获得相同的对称加密密钥Client │ ├── Handshake │ └── Session Key │ │ ▼ Encrypted Data ▲ │ │ Session Key └── Server后续大量数据不会继续使用昂贵的非对称加密而是使用协商出来的对称密钥进行加密。7. DTLS 为什么需要 Certificate这是 VoIP/WebRTC 中非常容易遇到的问题。DTLS 可以使用证书进行身份认证。例如Client Certificate Server Certificate证书里面包含Public KeySubjectIssuerValiditySignature但是 WebRTC 中还有一个非常重要的概念Fingerprint例如afingerprint:sha-256 12:34:56:78:...SDP 中可能出现asetup:actpass afingerprint:sha-256 12:34:56:78:...它表示对端应该使用这个 DTLS Certificate 的 Fingerprint 进行验证。因此在 WebRTC/SIP/SDP 场景中看到afingerprint通常就应该想到DTLS ↓ Certificate ↓ Fingerprint ↓ Identity verification8. DTLS-SRTP对于 VoIP 和 WebRTC最重要的组合之一就是DTLS-SRTP它可以简单理解为DTLS │ │ Key Agreement ▼ SRTP Key │ ▼ SRTP │ ▼ RTPDTLS 负责协商密钥SRTP 负责加密 RTP 音视频数据例如DTLS Handshake │ ▼ Derive SRTP Keys │ ▼ SRTP Encryption │ ▼ UDP因此不要简单地认为“RTP 使用 DTLS 加密”。更准确的说法是DTLS 用于建立安全的密钥协商机制而 SRTP 使用这些密钥保护 RTP Media。9. DTLS 和 SRTP 的区别可以用一个简单的表格理解技术主要作用UDP数据报传输RTP实时音视频传输DTLS安全握手、身份认证、密钥协商SRTPRTP 数据加密和完整性保护TLSTCP 上的安全传输典型 WebRTCWebRTC │ ┌──────┴──────┐ │ │ DTLS SRTP │ │ │ └── Audio / Video │ └── Key Agreement10. DTLS 的 Record LayerDTLS 也有类似 TLS Record Layer 的概念。应用数据经过 DTLS 后会被封装成 DTLS Record。概念上可以表示为------------------ | Content Type | ------------------ | Version | ------------------ | Epoch | ------------------ | Sequence Number | ------------------ | Length | ------------------ | Fragment | ------------------这里有一个特别重要的字段Sequence Number因为 UDP 可能乱序Packet 1 Packet 3 Packet 2 Packet 4DTLS 需要知道这个 packet 属于哪个 epoch 它的 sequence number 是多少这样才能进行正确的安全处理。11. Epoch 是什么DTLS 中经常会看到epoch sequence number例如Epoch 0 Sequence 100 Epoch 1 Sequence 200可以把 Epoch 理解成一次密钥状态切换后的新的安全阶段。例如 Handshake 完成后Epoch 0 │ │ Handshake ▼ Epoch 1 │ ▼ Encrypted Application Data不同 Epoch 对应不同的密钥状态。因此抓包分析 DTLS 时如果看到Epoch 0 Epoch 1通常意味着 DTLS 的安全状态已经发生变化。12. DTLS 抓包怎么看如果使用 Wireshark 分析 DTLS可以重点关注ClientHello ServerHello Certificate ServerKeyExchange ClientKeyExchange ChangeCipherSpec Finished Application Data一个典型流程Client │ │ ClientHello ▼ Server │ │ ServerHello │ Certificate │ ServerKeyExchange ▼ Client │ │ ClientKeyExchange │ Finished ▼ Server │ │ Finished ▼ Encrypted Data如果 Handshake 一直没有完成可以重点检查UDP 是否丢包DTLS Version 是否匹配Cipher Suite 是否匹配Certificate 是否正确Fingerprint 是否匹配Client/Server Role 是否正确NAT/防火墙是否影响 UDPMTU 是否导致 UDP FragmentationHandshake retransmission 是否正常13. SDP 中的 DTLS在 WebRTC 或某些 VoIP 场景中SDP 会携带 DTLS 相关信息。例如asetup:actpass afingerprint:sha-256 ...其中asetup用于确定 DTLS Role。常见值active passive actpass可以简单理解setup含义active主动发起 DTLSpassive等待对方发起 DTLSactpass可以 active也可以 passive例如Offer: asetup:actpassAnswer 可能选择asetup:active于是最终Offerer Answerer passive active │ │ │--DTLS---│14. DTLS 在 WebRTC 中的完整位置把 WebRTC 的流程串起来大致可以理解为WebRTC │ ┌────────┴────────┐ │ │ ICE DTLS │ │ │ Certificate / │ Fingerprint │ │ │ ▼ │ SRTP Keys │ │ └────────┬────────┘ │ UDP │ ▼ RTP实际建立连接时1. ICE 确定 UDP Candidate ↓ 2. 建立可用 UDP Path ↓ 3. DTLS Handshake ↓ 4. 验证 Certificate/Fingerprint ↓ 5. 派生 SRTP Key ↓ 6. SRTP 开始传输音视频这也是为什么 WebRTC 问题经常需要同时分析ICE STUN DTLS SRTP RTP SDP它们实际上是一个完整链路上的不同组件。15. DTLS 和 SIP/VoIP 的关系传统 SIP 系统中经常看到SIP │ ├── TLS │ └── TCP媒体RTP │ └── UDP如果媒体需要加密则可以使用SRTP而 DTLS-SRTP 提供了一种动态协商 SRTP Key 的方案SIP / SDP │ │ fingerprint ▼ DTLS │ │ Key ▼ SRTP │ ▼ RTP因此在 VoIP 系统中如果看到SDP afingerprint asetup UDP SRTP就很可能涉及 DTLS-SRTP。16. DTLS 和 TLS 的几个关键区别特性TLSDTLS底层传输TCPUDP数据模型StreamDatagram是否允许乱序不允许允许丢包TCP处理DTLS针对Handshake处理重传TCPDTLS Handshake典型应用HTTPSWebRTC/实时通信RTP不适合DTLS-SRTP延迟相对较高更适合实时通信最核心的区别可以总结成一句话TLS 假设底层是可靠的字节流而 DTLS 必须面对不可靠的数据报。17. DTLS 常见问题17.1 Handshake 一直失败优先检查ClientHello ↓ ServerHello ↓ Certificate ↓ Key Exchange ↓ Finished到底卡在哪一步。17.2 UDP 丢包导致 Handshake 失败DTLS 支持 Handshake Retransmission但如果ClientHello ServerHello X ClientKeyExchange中间的数据大量丢失最终仍然可能失败。可以结合tcpdump Wireshark查看 UDP packet 是否真正到达。17.3 Fingerprint 不匹配如果 SDPafingerprint:sha-256 ABCD...和实际 DTLS Certificate 计算出来的 Fingerprint 不一致就可能导致连接失败。这是 WebRTC 中非常典型的问题。17.4 MTU 问题DTLS Certificate 或 Handshake 数据可能比较大。如果 UDP Packet 太大DTLS Handshake │ ▼ Large UDP packet │ ▼ Fragmentation / Drop │ ▼ Handshake failure因此在实际生产环境中MTU 也是值得关注的问题。18. OpenSSL 中的 DTLS如果使用 OpenSSL可以看到类似DTLS_method()或者DTLS_client_method() DTLS_server_method()与 TLS 类似SSL_CTX SSL SSL_read SSL_write但是底层 Socket 通常是 UDP。概念上socket(AF_INET, SOCK_DGRAM, 0) │ ▼ UDP │ ▼ DTLS │ ▼ SSL_read/write对于 FreeSWITCH、媒体网关、WebRTC Gateway 等系统这类实现非常常见。19. 从工程角度如何理解 DTLS作为 VoIP 工程师我更推荐把 DTLS 分成三个层次理解。第一层安全回答数据怎么保证安全答案Encryption Authentication Integrity第二层Handshake回答双方怎么建立安全连接答案ClientHello ServerHello Certificate Key Exchange Finished第三层UDP 特性回答UDP 丢包、乱序怎么办答案Sequence Number Epoch Retransmission Fragmentation把这三个层次理解之后DTLS 的整体结构就会比较清晰。20. 总结DTLS 可以简单理解成TLS UDP Datagram 特性适配 DTLS它解决的是如何在 UDP 这种不可靠的数据报传输之上建立安全通信。在实时通信领域一个非常重要的组合是DTLS │ │ Key Agreement ▼ SRTP │ │ Encrypted Media ▼ RTP │ ▼ UDP因此在分析 WebRTC、SIP、VoIP、实时音视频问题时如果看到afingerprint asetup DTLS Handshake SRTP就可以把它们串成一条完整的链路SDP 提供 DTLS 参数 → DTLS 完成身份验证和密钥协商 → 生成 SRTP Key → SRTP 加密 RTP 媒体 → UDP 负责实际传输。理解这条链路是进一步分析WebRTC 音频不通、SRTP 解密失败、DTLS Handshake 失败、SDP 协商异常等问题的基础。