对网络协议来说,需要做的通常就两件事情:1、建立连接,2、传输数据,WebRTC也不例外。
假设WebRTC应用的两端已经建立了连接,那么,剩下就是如何传输数据的问题了。
WebRTC同时支持传输音视频数据、自定义应用数据。这其中,涉及多种协议,包括UDP、RTP/SRTP、RTCP/SRTCP、DTLS、SCTP。
这些协议名字比较相似,很容易让人混淆,简单总结下:
- 传输音视频数据相关协议:UDP、DTLS、RTP/SRTCP;
- 传输自定义应用数据相关协议:UDP、DTLS、SCTP;
下面就简单介绍下,这些协议是做什么的,有什么区别,存在什么联系。
加密信道建立:UDP、DTLS
对WebRTC应用来说,不管是音视频数据,还是自定义应用数据,都要求基于加密的信道进行传输。DTLS 有点类似 TLS,在UDP的基础上,实现信道的加密。
DTLS的主要用途,就是让通信双方协商密钥,用来对数据进行加解密。
- 通信双方:通过DTLS握手,协商生成一对密钥;
- 发送方:对数据进行加密;
- 发送方:通过UDP传输加密数据;
- 接收方:对加密数据进行解密;
音视频数据传输:RTP/SRTP、RTCP/SRTCP
首先,我们先来看下RTP、RTCP的大概用途:
- RTP(Realtime Transport Protocol):实时传输协议,主要用来传输对实时性要求比较高的数据,比如音视频数据。
- RTCP(RTP Trasport Control Protocol):RTP传输控制协议,跟RTP在同一份RFC中定义,主要用来监控数据传输的质量,并给予数据发送方反馈。
也就是说:
- RTP用来传输音视频数据;
- RTCP用来传输(质量)控制数据;比如监控传输的质量,并在会话双方之间进行同步,方便WebRTC根据传输质量进行动态调整,比如传输的速率、视频的码率等。
至于SRTP、SRTCP,分别在RTP、RTCP的基础上加了个S(Secure),表示安全的意思,这个就是DTLS做的事情了。
结合前面内容,总结一下音视频数据的发送过程:
- 通信双方:通过DTLS握手,协商生成一对密钥;
- 数据发送方:将音视频数据封装成RTP包,将控制数据封装成RTCP包;
- 数据发送方:利用加密密钥,对RTP包、RTCP包进行加密,生成SRTP包、SRTCP包;
- 数据发送方:通过UDP传输SRTP包、SRTCP包;
备注:SRTP/SRTCP包中,除了加密数据,还有其他信息,这里不展开细节。
自定义应用数据传输:SCTP
SCTP(Stream Control Transmission Protocol):流控制传输协议。
之前介绍过,RTP/RTCP主要用来传输音视频,是为了流媒体设计的。而对于自定义应用数据的传输,WebRTC中使用了SCTP协议。
同样的,SCTP依赖DTLS建立的加密信道,对于自定义应用数据的发送,流程如下:
- 通信双方:通过DTLS握手,协商生成一对密钥;
- 数据发送方:将自定义应用数据,通过密钥进行加密,生成SCTP包;
- 数据发送方:通过UDP传输SCTP包;
写在后面
为了便于讲解,跳过了很多协议的细节,有些地方可能会不够严谨,感兴趣的同学可以进行进一步研究,比如以下问题:
- 传输层用了UDP,UDP本身是不可靠的,那么,音视频数据、自定义用户数据的时序、质量是如何保证的?
- RTP用来传递音视频数据,为什么还需要有RTCP?
- 为什么说RTP不适合传输自定义用户数据?
- SCTP如何从协议层面兼顾传输的效率和质量?如何实现自定义数据的高效传递?
- 其他
相关链接
RTP: A Transport Protocol for Real-Time Applications
https://tools.ietf.org/html/rfc3550
Stream Control Transmission Protocol
https://tools.ietf.org/html/rfc4960
Datagram Transport Layer Security
https://tools.ietf.org/html/rfc4347