WebRTC → 传输技术解析

theme: channing-cyan
highlight: vs2015

协议简单分类

WebRTC同时支持传输音视频数据、自定义应用数据。这其中涉及了多种协议，包括RTP/SRTP、RTCP/SRTCP、UDP、DTLS、SCTP，简单总结分类为：传输音视频数据相关协议(UDP、DTLS、RTP/SRTP)和传输自定义应用数据相关协议(UDP、DTLS、SCTP)；

加密信道建立：UDP、DTLS

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

DTLS主要用途

• 让通信双方协商密钥，用来对数据进行加解密
  • 通信双方：通过DTLS握手，协商生成一对密钥
  • 发送方：对数据进行加密
  • 发送方：通过UDP传输加密数据
  • 接收方：对加密数据进行解密

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

• RTP实时传输协议，用来传输音视频数据
• RTCP：RTP传输控制协议，主要用来监控传输数据的质量，并给予数据发送方反馈

自定义应用数据传输：SCTP

SCTP(Stream Control Transmission Protocol)流控制传输协议，STCP依赖DTLS建立的加密信道，对于自定义应用数据的发送，流程如下

• 通信双方：通过DTLS握手，协商生成一对密钥
• 数据发送方：将自定义应用数据，通过密钥进行加密，生成SCTP包
• 数据发送方：通过UDP传输SCTP包

音视频数据发送过程概括

• 通信双方：通过DTLS握手，协商生成一对密钥
• 数据发送方：将音视频数据封装成RTP包，将控制数据封装成RTCP包
• 数据发送方：利用加密协议，对RTP包，RTCP包进行加密，生成SRTP包、SRTCP包
• 数据发送方：通过UDP传输SRTP包，SRTCP包

WebRTC在传递媒体流到对等端时，涉及到媒体信息协商、网络建立协商、网络传输等技术，这些技术不仅用于WebRTC底层，也广泛用于其他流媒体领域。
WebRTC使用安全实时传输协议(Secure Real-time Transport Protocol，SRTP)对RTP数据进行加密，消息认证和完整性以及重播攻击保护。

UDP和TCP的选择

选择依据浅析

在TCP/IP四层结构中，网络传输层是最为重要的一层协议，该层中包含了两种协议：TCP和UDP；

TCP浅析

• TCP是可靠传输协议，可以保证数据在传输过程中不丢失、不乱序、不抖动；
• TCP的缺点是实时性差
  • 其可靠性是以牺牲实时性为代价的
  • 按照TCP的原理，当出现极端的网络情况时，每个包的延时将达到秒级以上，而且是不断叠加的，对于音视频实时通信来说是不可接受的；
• TCP原理 – 缺点的原因
  • 为了实现数据传输的可靠性，采用的是发送→确认→丢包→重传的机制
  • 而且为了增加网络吞吐量，还采用了延迟确认和Nagle算法，这套机制是导致TCP产生延迟的根本原因
  • Nagle算法，将多个小包组成一个大包发送，组合包的大小不超过网络最大传输单元(最大数据单元是用来通知对方所能接受数据服务单元的最大尺寸)
    
  • 延迟确认机制
    • 为了增加吞吐量，接收端不必每个包都进行一次确认，而是对一段时间内收到的所有数据集体确认一次即可
    • 其原理就是在TCP在接收端启动一个定时器，一般为200ms，即每隔200ms确认一次接收到的数据
  • 丢包重传机制
    • TCP会在发送端也启动一个定时器，该定时器只是用来判别是否有丢包的情况，时长一般为一个RTO，如果在定时器超时后还是没有收到包的确认信息，则认为包丢失了，需要发送端重新发送丢失的包；
    • RTO（Retransmission Timeout），重传超时时长。其值约等于RTT的平均值，每次超时后以指数级增长。RTT表示一个数据包从发送端到接收端，然后再回到发送端所用的时长。
  • 上述两种机制存在的问题
    • 接收端发出的确认消息丢失后发送端并不会时时得到反馈，而是得等到发送端定时器超时后才可以进行将未确认的包重传；
    • 而另一种情况时接收端都接收到数据了，但是接收端发出的确认消息丢失了，这样还是会导致发送端出现上述的问题
    • 这两种情况在TCP传输中的时延要累加很多，且不可控
• TCP在极端的网络情况下，不能控制传输的延时大小，所以实时通信传输时首选UDP

UDP浅析

UDP属于不可靠传输协议，在数据传输过程中，不能保证数据能可靠到达，也不保证数据有序，但他的最大优点就是传输速度”快“

• UDP没有像TCP那样的一套保证数据可靠、有序的控制逻辑，因此实时性最高
• 解决UDP的丢包和抖动问题
  • WebRTC通过NACK、FEC、JitterBuffer以及NetEQ技术既可以解决丢包和抖动的问题，又不会产生影响服务质量的延时问题

RTP

UDP在传输一些有前后逻辑关系的数据时，会显得捉襟见肘，而音视频正是这样的数据，为了解决这些问题，在传输音视频数据时，通常在UDP之上加一个新协议，即RTP；
RTP属于应用层传输协议的一种，与HTTP/HTTPS处于同一级别；RTP的设计基于应用层框架和集成层处理的基本原理。它提供源和负载类型的标识，流同步、丢包和重新排序以及媒体流监控。

简介

RTP(Real-time Transport Protocol，实时传输协议)，通过IP网络实时传输音频和视频。RTP常用于流媒体服务的通信系统，如电话会议、视频会议、电话服务等；
RTP是专门为流媒体的端到端实时传输设计的，更关注信息的实时性，而为了避免因网络传输导致的质量下降的问题，可以使用合适的纠错算法使得用户无感知；
大多数RTP应用都是基于UDP创建的，并提供额外抖动补偿、包丢失检测和无序传递检测的功能；当然RTP也支持TCP，但是因为TCP是注重可靠性而不是实时性，所以很少使用TCP

解决的问题

• 定位丢的数据包
  
  • 希望在使用RTP传输音视频数据时，一旦有数据丢失，可以快速的定位到是哪个数据包丢失了
    • 在发送端，每产生一个RTP包，其Sequence Number字段中的值就被自动加一，以保证每个包的编号唯一且连续
    • 在接收端接收到RTP包时会对Sequence Number字段进行检查，当该字段不连续时就认为丢失或者乱序了
  • 区分同一个端口传输的不同类型的数据
    • 在网络应用中，通常会在同一个端口传输不同类型的数据，如音视频数据但接收端是如何进行区分的呢；RTP在协议头中设置了PT(PayloadType)字段，接收端可以依据该字段区分出具体的数据类型来；
    • 同理同一个端口不仅可以同时传输不同类型的数据包，还可以传输同一类型的不同源的数据包，如流媒体服务就可以将多个不同源的视频通过同一个端口转发给客户端，而客户端通过RTP中的另一个字段SSRC进行区分(每个源的SSRC必须是唯一的)

主要特点

• 具有较低延时 – 基于UDP，UDP注重实时性
• 数据包在传输过程中可能会丢失，且到达对等端的顺序可能也会发生变化，所以对等端收到RTP数据包后需要根据数据包的序列号和时间戳进行重新排列；
• 支持多播(multicast)，适合于海量用户通话的场景
• 可用于除音视频通话之外的场景，如实时数据流、状态实时更新、控制消息传输等连续数据的场景
• RTP的定位是低延时数据传输，本身并没有提供服务质量保障功能(Quality of Service，QoS)，所以在WebRTC中，RTP需要和RTCP结合使用
• RTP会为每个媒体流创建一个会话，即视频和音频使用单独的RTP会话，这样接收端可以选择性的接收媒体流
• RTP使用的UDP端口号为偶数，每个关联的RTCP端口为下一个较高的奇数，端口范围为1024~65535

RTP配置文件和载荷

RTP在设计之初就考虑到了在不修改标准的情况下携带多种媒体格式并允许使用新格式，所以，RTP标头数据中不包含媒体格式信息，而是在单独的RTP配置文件（profile）和有效载荷（payload）格式中提供，这种方式提供了更好的可扩展性;
RTP对每类应用(如音频和视频)都定义了一个配置文件和至少一个有效载荷格式；

• RTP配置文件包括以下三种
  • 音频和视频会议的RTP配置文件(RPC 3551)
    • 定义了一组静态有效载荷类型分配以及使用会话描述协议（SDP）在有效载荷格式和PT值之间进行映射的动态机制。
  • SRTP(RPC 3771)
    • 定义了一个RTP配置文件，该配置文件提供用于传输有效载荷数据的加密服务 ，WebRTC用的就是SRTP
  • 实验性控制数据配置文件
    • 用于机器对机器通信的RTP

RTCP

RTP通常在偶数UDP端口上发送，而RTCP消息将在写一个更高的奇数端口上发送

简介

RTCP(RTP Control Protocol)是实时传输协议(RTP)的姊妹协议和控制协议，RTCP可以对RTP进行丢包等控制，其基本功能和数据包结构在RFC 3550中定义；
RTCP主要功能是定期发送数据包计数、丢失数据包的信息、丢包率、数据包延迟变化以及往返延迟时间等统计信息，向媒体参与者提供媒体分发中的服务质量保障，应用程序在收到这些消息后，可以通过限制流量或更换编解码器格式的方式提升服务质量，同时RTCP的流量占用是很小的；

RTCP报告间隔是随机的，最小报告时间间隔为5s，通常发送RTCP报告的频率不应该低于5s/次；

RTCP支持的数据包

发送者报告(SR)

活跃发送者在会议中定期发送报告，报告该时间内发送的所有RTP数据包额发送和接收信息，发送者报告包含绝对时间戳，用于帮助接收方同步RTP消息

接受者报告(RR)

适用于不发送RTP数据包的被动参与者，用于通知发送者和其他接受者服务质量；此报告包含当前的丢包比率，接收到的最高序列号，并有助于计算往返时间

源描述(SDES)

用于将CNAME项发送给会话参与者，也可以用于提供其他信息

关闭流(BYE)

源发送BYE消息以关闭流，允许端点(endpoint)宣布即将离开会议

SRTP/SRTCP

WebRTC使用的就是SRTP，因为RTP没有内置安全机制

对于未加密的实时通信应用，可能会遇到多种形式的安全风险，如在传输途中可能会被第三方拦截窃取，RTP没有内置任何安全机制，因此不能保证数据的安全性，需要依靠外部机制进行加密

简介

SRTP是RTP的一个配置文件，旨在为单播和多播应用程序中的RTP数据提供加密、消息身份验证和完整性以及重放攻击保护等安全功能。SRTP有一个姊妹协议：安全RTCP（SRTCP），它提供了与RTCP相同的功能，并增强了安全性。
使用SRTP或SRTCP时必须启用消息身份验证功能，其他功能自选；SRTP和SRTCP默认的加密算法是AES，攻击者虽然无法解密数据，但可以伪造或重放以前发送的数据。因此，SRTP标准还提供了确保数据完整性和安全性的方法

TLS/DTLS

简介

安全套接层（Secure Socket Layer，SSL）是为网络通信提供安全保证及数据完整性的一种安全协议。SSL由网景公司（Netscape）研发，用于确保互联网连接安全，保护两个系统之间发送的敏感数据，防止网络犯罪分子读取和篡改传输信息。
IETF对SSL 3.0进行了标准化，并添加了一些机制，经过标准化的SSL更名为TLS（Transport Layer Security，安全传输层）协议。所以，可以将TLS理解为SSL标准化后的产物;

由于TLS是基于TCP，不能保证UDP上传输的数据的安全性，因此在TLS协议架构上进行了扩展，提出DTLS（Datagram Transport Layer Security，数据包传输层安全性）协议，使之支持UDP，DTLS即成为TLS的一个支持数据包传输的版本。DTLS使用非对称加密方法，对数据身份验证和消息身份验证提供完全加密。
DTLS协议内置在WebRTC的标准化协议中，并且是在Web浏览器、电子邮件和VoIP平台中始终使用的协议，这意味着基于Web的应用程序无须提前设置。

SDP

简介

SDP(Session Description Protocol)用于描述媒体信息的协议，以文本格式描述终端功能和首选项。SDP只包含终端的媒体元数据，不包含媒体数据内容，建立连接的双方通过交换SDP获取彼此的媒体信息，SDP广泛用于会话启动协议(SIP)、RTP和实时流协议(RSP)

• SDP包含的内容
  • 会话属性
  • 会话活动时间
  • 会话包含的媒体信息
  • 媒体编解码器
  • 媒体地址和端口号
  • 网络宽带信息
• SDP字段含义及格式
  

SDP示例

v=0
// 会话由用户jdoe创建 发起会话的源地址为10.47.16.5
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
//会话名称是SDP Seminar
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
// 指明了目标的IP地址为224.2.17.12 地址的TTL是127
c=IN IP4 224.2.17.12/127
// 指明了会话在2个小时内有效
t=2873397496 2873404696
a=recvonly // 表明只接收数据
//两个m字段指明都使用RTP音视频配置：第一个音频媒体流使用端口49170，载荷类型是0；第二个视频媒体流使用端口51372，载荷类型是99。 
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
// 指明了类型99使用的编码格式是h263-1998，编码时钟频率是90kHz
a=rtpmap:99 h263-1998/90000