SRS4.0之RTMP转WebRTC06 ---- DTLS协议
角色协商
对于DTLS来说，有Client和Server之分，这里主要是通过sdp来协商的。
offer: a=fingerprint:sha-256 D4:50:20:EA:EE:A6:86:59:77:3B:88:84:95:69:8A:AE:79:1A:C0:35:D9:25:EE:3F:0E:02:CB:2B:AF:99:F5:9E a=setup:actpass answer: a=fingerprint:sha-256 06:5D:44:D5:6A:62:A9:2E:5F:C5:5E:1E:99:3A:9F:11:20:7B:71:B1:D3:DF:CA:70:2D:82:0F:7D:AC:DC:0C:CC a=setup:passive
setup:
- active，作为client，主动发起协商
- passive，作为server，等待发起协商
- actpass，作为client，主动发起协商；作为server，等待发起协商
fingerprint：证书的摘要签名，用来验证证书使用，DTLS收到证书后，基于相同的hash计算哈希值，同fingerprint比较，相等，则说明证书有效。
DTLS握手过
过程和TLS总体差不多，目的就是交换对称秘钥，实现后面的加密。
具体可以参考：https://mp.weixin.qq.com/s/tHW6sWRZUzkOtl2BsRbV1w
1. ClienHello 和 ServerHello ：协商DTLS 的 Version、CipherSuites、Random、以及 Extensions
Version：DTLS 1.2
CipherSuites: TLS_ECDHE_RSA_WITH_AES_128_GSM_SHA256
TLS：协议
ECDHE：秘钥交换
RSA：对消息摘要使用私钥RSA加密生成数字签名，客户端使用公钥解密
AES_256_GSM：对称加密算法，最终数据交换使用对称加密
SHA256：对个人信息和公钥进行HASH算法生成信息摘要
Random: aa2425b20f7cf9fcc72d9a031b4374c2c597e57832b62f1b59fa75c332f711aa
双方的随机数，参与到生成 MasterSecret。MasterSecret 会用来生成主密钥，导出 SRTP 密钥。详见 [导出 SRTP 密钥]
2. 身份验证-Certificate
Certificate: 308201153081bda00302010202045d24d118300906072a8648ce3d040130143112301006… (id-at-commonName=ossrs.net)
这里证书通过sha256之后等于sdp里面的fingerprint，这里是自签名证书，通过这个来保证安全
3. 密钥交换-KeyExchange
ServerKeyExchange和ClientKeyExchange，双方互相交换公钥，然后生成共享密钥。
4. 证书验证 - CertificateVerify
使用 ClientRequest 中描述的 Hash/Signature 算法，对收到和发送的 HandShake 消息签名发送个 Server。Server 端对签名进行校验。
5. 加密验证 - Finished
当 Server 和 Client 完成对称密钥的交换后，通过 ChangeCipherSpec 通知对端进入加密阶段，epoch 加 1。
随后 Client 使用交换的密钥，对 "client finished" 加密，使用 Finished 消息，发送给服务端。Server 使用交换的密钥，对 "server finished" 进行加密发送给客户端。一旦验证了 finished 消息后，就可以正常通信了。
SRS握手过程
1. 初始化：收到/rtc/v1/play/后，创建SrsDtls
2. 握手：SrsDtlsImpl::do_handshake()
3. 握手结束：SrsDtlsServerImpl::on_handshake_done()
参考：
