WebRTC基础传输技术
2021-07-12 16:21:55 1 举报AI智能生成
WebRTC基础传输技术相关协议
作者其他创作
大纲/内容
WebRTC基础传输技术架构
WebRTC基础传输技术架构
RTP/SRTP、SCTP用于传输媒体流，提供拥塞和流控制功能
SDP、ICE、STUN、TURN用于建立和维护网络连接
DTLS则用于保护传输数据的安全
安全要求
在WebRTC规范中，加密是强制要求的，并在包括信令机制在内的所有组件上强制执行。
通过WebRTC发送的所有媒体流都通过标准化的加密协议进行安全加密。
在选择加密协议时，具体取决于通道类型；通过RTCDataChannel发送的数据流使用DTLS协议加密；通过RTP传输的音视频媒体流则使用SRTP加密。
RTP
Real-time Transport Protocol，实时传输协议
主要特点
具有较低的延时。
数据包在网络传输的过程中可能会丢失，到达对等端的顺序也可能发生变化。对等端收到RTP数据包后，需要根据数据包的序列号和时间戳进行重新组合。
支持多播（multicast），尽管目前WebRTC还没有使用这个特性，但是在海量用户通话场景，这个特性就变得很重要。
可用于音视频通话之外的场景，如实时数据流、状态实时更新、控制信息传输等连续数据传输场景。
尽管RTP的定位是低延时场景数据传输，但它本身并没有提供服务质量保障功能（Quality ofService，QoS），所以在WebRTC中，RTP需要和RTCP结合使用。
RTP数据包标头
RTP数据包标头域
RTCP
RTP Control Protocol，实时传输协议（RTP）的姊妹协议
RTCP为RTP会话提供带外统计信息和控制信息，与RTP协作提供多媒体数据的传输和打包功能，其本身不传输任何媒体数据。
RTP使用的端口号为偶数，每个关联的RTCP端口为下一个较高的奇数，端口号范围为1024～65535。
RTCP数据包标头
RTCP数据包标头
SRTP/SRTCP
SRTP是RTP的一个配置文件，旨在为单播和多播应用程序中的RTP数据提供加密、消息身份验证和完整性以及重放攻击保护等安全功能。
SRTCP（安全RTCP）是的SRTP一个姊妹协议，它提供了与RTCP相同的功能，并增强了安全性。
WebRTC规范明确禁止使用未加密的RTP。出于增强安全性的考虑，WebRTC使用的是SRTP。
TLS/DTLS
SSL
安全套接层（Secure Socket Layer，SSL）是为网络通信提供安全保证及数据完整性的一种安全协议。
IETF对SSL 3.0进行了标准化，并添加了一些机制，经过标准化的SSL更名为TLS（Transport Layer Security，安全传输层）协议。
SSL 3.0对应着TLS 1.0版本。
由于TLS是基于TCP，不能保证UDP上传输的数据的安全性，因此在TLS协议架构上进行了扩展，提出DTLS（Datagram Transport Layer Security，数据包传输层安全性）协议，使之支持UDP，DTLS即成为TLS的一个支持数据包传输的版本。
DTLS协议内置在WebRTC的标准化协议中，并且是在Web浏览器、电子邮件和VoIP平台中始终使用的协议，这意味着基于Web的应用程序无须提前设置。
SDP
Session Description Protocol，是用于描述媒体信息的协议，以文本格式描述终端功能和首选项。
WebRTC使用SDP交换双方的网络和媒体元数据，当遇到连接失败、黑流等问题时，分析SDP往往是查找问题最为有效的方法。
SDP各个字段的含义及格式
SDP字段含义及格式
ICE
Interactive Connectivity Establishment，交互式连接建立协议
用于提案/应答模式的NAT（网络地址转换）传输协议，主要用于在UDP协议下建立多媒体会话。
对于采用Mesh结构的WebRTC应用程序，当通信双方尝试建立P2P连接时，如果有一方（或者双方）位于NAT网络内部，则直接建立P2P连接会失败，这时候必须有一种能够突破NAT限制的技术，这个技术就是ICE协议。
使用ICE技术建立网络连接的步骤
第一次尝试：ICE首先尝试使用本地网卡地址与对等方建立P2P连接，此地址通常为内网地址。如果连接双方位于同一个内网，则成功建立连接。
第二次尝试：如果第一次尝试失败（这对于双方都位于NAT网络内部的情况是不可避免的，由于网络的复杂性，也可能会由其他原因导致连接失败），则ICE将使用STUN服务器获取NAT设备的公网IP地址及映射端口，并尝试使用该IP地址建立连接。对于只有一方位于NAT网络内部，或者双方都位于非对称NAT网络内的情况，连接通常会成功建立。
第三次尝试：如果第二次尝试失败，意味着双方无法直接建立P2P连接，这时需要通过一个中介进行数据中转，这个中介即TURN服务器。也就是说，第三次尝试是直接与TURN服务器建立连接，而随后的媒体数据流将通过TURN中继服务器进行转发。
NAT
NAT是一种实现内网主机与互联网通信的方法。
优点
共享上网：NAT技术通过地址和端口映射，使用少量公网IP即可实现大量内网IP地址共享上网。
提高网络安全性：不同的内网IP地址映射到少量公网IP地址，对外隐藏了内网网络结构，从而防止外部攻击内网服务器，降低了网络风险。
方便网络管理：通过改变映射关系即可实现内网服务器的迁移和变更，便于对网络进行管理。
节省成本：使用了少量公网IP地址，节省了IP地址的注册及使用费用。
按照地址转换方法分类
全锥形NAT（Full cone NAT）
一旦一个内网地址（ip1:port1）映射到公网地址（ip2:port2），所有发自ip1:port1的包都经由ip2:port2向外发送。任意外部主机都能通过向ip2:port2发包到达ip1: port1。
地址受限锥形NAT（Address-Restricted cone NAT）
只接收曾经发送到对端IP地址的数据包。
一旦有一个内网地址（ip1:port1）映射到公网地址（ip2:port2），所有发自ip1:port1的包都经由ip2:port2向外发送。任意外部主机（hostAddr:any）都能通过向ip2:port2发包到达ip1:port1，但前提是ip1:port1之前有向hostAddr:any发送过包，any表示端口不受限制。
端口受限锥形NAT（Port-Restricted cone NAT）
类似地址受限锥形NAT，但是端口也受限制。
一旦有一个内网地址（ip1:port1）映射到外网地址（ip2:port2），所有发自ip1:port1的包都经由ip2:port2向外发送。一个外部主机（hostAddr:port3）能够发包到达ip1:port1的前提是ip1:port1之前有向hostAddr:port3发送过包。
对称NAT（Symmetric NAT）
映射的外网地址端口号不固定，会随着目的地址的变化而变化。
同一内网主机、同一端口号，对于锥形NAT，无论与哪一个外网主机通信，都不改变所分配的端口号；而对于对称NAT，同一内网主机、同一端口号，每一次与不同的外网主机通信，就重新分配一个端口号。
对称NAT的这个特性使得位于该网络下的WebRTC用户无法使用STUN协议建立P2P连接。
STUN与TURN
STUN（Session Traversal Utilities for NAT）
一种公网地址及端口的发现协议，客户端向STUN服务发送请求，STUN服务返回客户端的公网地址及NAT网络信息。
TURN（Traversal Using Relays around NAT）
通过数据转发的方式穿透NAT，解决了防火墙和对称NAT的问题。TURN支持UDP和TCP协议。
网络模型
单独使用STUN与结合使用STUN和TURN的对比
使用STUN建立的是P2P的网络模型，网络连接直接建立在通信两端，没有中间服务器介入。
使用TURN建立的是流量中继的网络模型，用户两端都与TURN服务建立连接，用户的网络数据包通过TURN服务进行转发。
ICE候选者
ICE候选者描述了用于建立网络连接的网络信息，包含网络协议、IP地址、端口等
如果设备上有多个IP地址，那么每个IP地址都会对应一个候选
ICE候选者在SDP中的语法
SDP中的ICE候选者
foundation：创建标识。
component-id：值为1表示RTP协议，值为2表示RTCP协议。
transport：传输协议，可以使用UDP和TCP，由于UDP性能好，故障恢复快，推荐使用UDP。
priority：优先级，综合考虑延时、带宽开销、丢包等因素，候选类型的优先级一般是host>srvflx>prflx>relay。
connection-address：IP地址。
port：端口。
cand-type：候选类型，UDP候选类型取值有host（本机候选）、srflx（映射候选）、relay（中继候选）和prflx（来自对称NAT的映射候选）。
ICE配对
将本地ICE候选项和对等端ICE候选项进行一一对应，每一组称为一个ICE候选对。
步骤
建连协商
在进行ICE建连协商时，ICE层将从两端选择一个作为控制代理（controlling agent），另外一端作为受控代理（controlled agent）。
控制代理负责决定建立连接使用的ICE候选对，并将最终结果发送给受控代理，受控代理只需要等待结果。
尝试建立连接
控制代理通常会为同一个ICE会话选择多个候选对，每选择一个候选对都会通知受控代理，两端同时使用新的候选对尝试建立连接。
当控制代理发送完所有的候选项时，需要通知对等端，做法是将RTCIceCandidate.candidate属性设置为空字符串，调用addIceCandidate()方法将RTCIceCandidate加入ICE连接。
协商完成
当ICE协商完成后，当前正在使用的候选对即为最终配对结果。
如果出现ICE重新协商，则重新开始配对。
由于网络连接配置可能发生变化（如切换网络），每次最终配对的结果可能不同。
ICE Trickle
解决的问题
在实际使用过程中，ICE技术呼叫建连很慢，原因是ICE协商过程耗费了过多时间。
解决方法
把连通性检测提前，即ICE Trickle方案。
客户端一边收集候选一边发送给对方，比如本地候选不需要通过STUN服务获取，直接就可以发起，这样节省了连通性检测的时间。
实际操作
在对象RTCPeerConnection监听事件icecandidate，WebRTC完成本地ICE候选者的搜集后，会触发该事件，该事件对象中包含candidate属性，然后使用信令服务器将candidate传送给对等端。
WebRTC使用ICE Trickle
0 条评论
下一页
为你推荐
查看更多
