对网络协议来说,需要做的通常就两件事情:1、建立连接,2、传输数据,WebRTC也不例外。

假设WebRTC应用的两端已经建立了连接,那么,剩下就是如何传输数据的问题了。

WebRTC同时支持传输音视频数据、自定义应用数据。这其中,涉及多种协议,包括UDP、RTP/SRTP、RTCP/SRTCP、DTLS、SCTP。

这些协议名字比较相似,很容易让人混淆,简单总结下:

  1. 传输音视频数据相关协议:UDP、DTLS、RTP/SRTCP;
  2. 传输自定义应用数据相关协议:UDP、DTLS、SCTP;

下面就简单介绍下,这些协议是做什么的,有什么区别,存在什么联系。

加密信道建立:UDP、DTLS

对WebRTC应用来说,不管是音视频数据,还是自定义应用数据,都要求基于加密的信道进行传输。DTLS 有点类似 TLS,在UDP的基础上,实现信道的加密。

DTLS的主要用途,就是让通信双方协商密钥,用来对数据进行加解密。

  1. 通信双方:通过DTLS握手,协商生成一对密钥;
  2. 发送方:对数据进行加密;
  3. 发送方:通过UDP传输加密数据;
  4. 接收方:对加密数据进行解密;

音视频数据传输:RTP/SRTP、RTCP/SRTCP

首先,我们先来看下RTP、RTCP的大概用途:

  1. RTP(Realtime Transport Protocol):实时传输协议,主要用来传输对实时性要求比较高的数据,比如音视频数据。
  2. RTCP(RTP Trasport Control Protocol):RTP传输控制协议,跟RTP在同一份RFC中定义,主要用来监控数据传输的质量,并给予数据发送方反馈。

也就是说:

  1. RTP用来传输音视频数据;
  2. RTCP用来传输(质量)控制数据;比如监控传输的质量,并在会话双方之间进行同步,方便WebRTC根据传输质量进行动态调整,比如传输的速率、视频的码率等。

至于SRTP、SRTCP,分别在RTP、RTCP的基础上加了个S(Secure),表示安全的意思,这个就是DTLS做的事情了。

结合前面内容,总结一下音视频数据的发送过程:

  1. 通信双方:通过DTLS握手,协商生成一对密钥;
  2. 数据发送方:将音视频数据封装成RTP包,将控制数据封装成RTCP包;
  3. 数据发送方:利用加密密钥,对RTP包、RTCP包进行加密,生成SRTP包、SRTCP包;
  4. 数据发送方:通过UDP传输SRTP包、SRTCP包;

备注:SRTP/SRTCP包中,除了加密数据,还有其他信息,这里不展开细节。

自定义应用数据传输:SCTP

SCTP(Stream Control Transmission Protocol):流控制传输协议。

之前介绍过,RTP/RTCP主要用来传输音视频,是为了流媒体设计的。而对于自定义应用数据的传输,WebRTC中使用了SCTP协议。

同样的,SCTP依赖DTLS建立的加密信道,对于自定义应用数据的发送,流程如下:

  1. 通信双方:通过DTLS握手,协商生成一对密钥;
  2. 数据发送方:将自定义应用数据,通过密钥进行加密,生成SCTP包;
  3. 数据发送方:通过UDP传输SCTP包;

写在后面

为了便于讲解,跳过了很多协议的细节,有些地方可能会不够严谨,感兴趣的同学可以进行进一步研究,比如以下问题:

  1. 传输层用了UDP,UDP本身是不可靠的,那么,音视频数据、自定义用户数据的时序、质量是如何保证的?
  2. RTP用来传递音视频数据,为什么还需要有RTCP?
  3. 为什么说RTP不适合传输自定义用户数据?
  4. SCTP如何从协议层面兼顾传输的效率和质量?如何实现自定义数据的高效传递?
  5. 其他

相关链接

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

07-17 14:22