WebRTC → WebRTC与直播相关原理_video 播放 arraybuffer 直播流

1、前置知识

1.1 WebRTC前世今生

在线教育、在线会议、在线面试、在线社交、在线医疗、金融证券在线开户、智能家居都已经非常普及了，将常见的线下场景转至线上，而WebRTC就是实现这些场景的主要手段；

WebRTC的使命是使丰富、高质量的RTC应用程序可以为浏览器、移动平台和loT设备开发，并允许所有人通过一组通用的协议进行通信

1.2 WebRTC解决的问题(主要相对于RTC)

• 互联网网络复杂

  • 不同的NAT、防火墙对媒体P2P的建立带来了很大的挑战；而WebRTC为浏览器提供了端到端的直接通信；

  • WebRTC技术包含了STUN、TURN、ICE、RTP-over-TCP的关键NAT和防火墙穿透技术，并支持代理

  • WebRTC里面有P2P打洞的开源项目libjingle、支持STUN、TURN等协议

• 延时敏感

  • 早期的RTC技术中，由于TCP技术的缺陷，只能需要UDP传输，需要开发者解决重传、乱序等问题

  • WebRTC提供了NACK、PEC技术，不再需要通过服务器进行路由，减少了延迟和宽带消耗

  • 直接通信可以提高数据传输和文件共享的速度

• 流畅性

  • 网络中存在不稳定性，例如网络的抖动等问题，此时就需要一套自适应的算法来应对网络拥塞、平滑发送等问题

  • WebRTC中提供了TCC+SVC+PACER+JitterBuffer等技术解决这些问题

• 语音清晰

  • 由于终端设备和环境的问题，会有噪声、回声等干扰，WebRTC提供了3A算法+NetEQ，让实时环境中的声音处理以及互动体验得到了极大的提升

1.3 WebRTC的安全问题

所有WebRTC媒体数据都必须经过加密

WebRTC不是一个插件，也不依赖于任何插件，因此所有应用都可以在浏览器的沙箱中运行，并不用再额外创建新进程，正因为如此，WebRTC有效的阻止了恶意软件进入用户系统

• WebRTC的媒体处理

  • 对于WebRTC的媒体处理上，已经使用了DTLS-SRTP技术，使用DTLS类似的SSL证书方式来协商加解密密钥，使用SRTP实现对于媒体(音视频)数据加密和完整性保护，实现媒体传输的安全保护

• 信令协商

  • 也需要采取TLS/DTLS进行信令数据传输的保护，当然是取决于各厂商的具体实现方式(如HTTPS、SIPS)

  • 针对信令服务器，其信令通信都是对互联网开放的，其受攻击的基本都是DOS/DDOS攻击(如TCP半链接攻击，HTTP Flood攻击)，目的就是破坏性的让信令服务器无法提供服务

  • 信令协议本身就有挺多的缺陷的，针对单用户的攻击，SIP这种通用的RTC协商信令协议，有很多方法可以使得攻击者将合法用户禁掉

• WebRTC潜在的危险

  • 针对信令服务器

    • 进行针对用户设备的DOS暴力破解攻击

    • 攻击者快速频繁且反复地发送注册请求

    • 伪造报文将用户去注册

    • 伪造结束报文非法结束用户的通话

  • 针对媒体服务器/媒体终端

    • 由于媒体地址和媒体端口都是通过SDP协商的，SDP消息如果被恶意篡改，就会导致媒体处理者的媒体报文自我循环，从而造成媒体处理方无法提供服务

    • 终端与媒体服务器之间是加密的(如SRTP加密)，但在媒体服务器中解密的处理会存在媒体明文暴露点，也就存在了安全风险

  • 其他风险

    • 交换公钥时存在被黑客截取到的风险

      • WebRTC利用DTLS协议就可以有效的解决各端之间交换公钥时被窃取的问题

        • 进行DTLS协商，交换公钥证书以及协商密码相关信息，同时通过fingerprint对证书进行验证，确认其没有在传输中被篡改

        • 可以通过「指纹」的方式对证书进行加解密操作，实现数据的校验和验证

          • 「指纹」是指：用来判断公钥证书在传递过程中有没有被篡改，进行证书完整性判断，通过哈希算法对证书内容进行计算从而获取到指纹

          • 在获取到「指纹」后，在发送前需要进行指纹加密，生成数字签名，然后和公钥一起发送给对等端，对等端通过该公钥和对应的哈希算法进行解密，然后再对比从而判断证书是否正确

        • WebRTC安全机制

      • 但还有一个问题是不能确定对方是不是冒充的

        • 解决该问题可以利用STUN协议进行身份认证，从而拦截黑客冒充的身份进行交互窃取信息

      • 安全描述的作用

        • 进行网络连通性检测时，对用户身份进行验证

        • 收发数据时，对用户身份的认证，以免受到对方的攻击

• WebRTC使用两种标准的加密协议

  • 加密的首选方法是在DTLS(数据报传输层安全性)捂手中使用PFS密码来安全的交换关键数据

    • 对于音视频传输，可以使用密钥数据生成AES(高级加密标准)密钥，然后由SRTP(安全实时传输协议)使用AES密钥对媒体进行加密和解密

  • 数据报传输层安全性(DTLS)

    • 浏览器内置的标准化协议。是基于传输层协议(TLP)的数据流加密

    • 由于DTLS使用用户数据协议(UDP)，因此保留了传输的语义

    • 他是安全套接字层(SSL)的拓展，任何SSL协议均可用于保护WebRTC数据，从而允许端到端加密

  • 安全实时传输协议(SRTP)

    • 用于媒体流加密

    • 是对实时传输协议(RTP)的拓展，该协议没有任何内置的安全性机制

    • 为实时传输协议(RTP)提供加密、完整性保证和消息身份验证

      • 但是不会对表头进行加密，只会对RTP数据包加密

可以说如果 WebRTC 直接拿过来商用的话，几乎是不太可能的，当下普遍的解决方案是自研，根据自身的业务场景进行二次定制开发，或者更简单一点使用第三方 SDK。Agora WebSDK 是基于 WebRTC 封装的API集合，极致简单，对开发者更加友好，能十行之内完成一个简单的 demo 并上线；

• 媒体协商拓展

  • 基本步骤

    • 呼叫端 Amy 创建 Offer(createOffer)并将 offer 消息（内容是呼叫端 Amy 的 SDP 信息）通过信令服务器传送给接收端 Bob,同时调用 setLocalDesccription 将含有本地 SDP 信息的 Offer 保存起来

    • 接收端 Bob 收到对端的 Offer 信息后调用 setRemoteDesccription 方法将含有对端 SDP 信息的 Offer 保存起来，并创建 Answer(createAnswer)并将 Answer 消息（内容是接收端 Bob 的 SDP 信息）通过信令服务器传送给呼叫端 Amy

    • • 呼叫端 Amy 收到对端的 Answer 信息后调用 setRemoteDesccription 方法将含有对端 SDP 信息的 Answer 保存起来

  • 完成P2P通信过程的媒体协商之后，通过信令服务器将各自的网络信息(Candidate)发送给对等端之后就可以打通P2P通信的网络通道，并通过监听onaddstream事件拿到对方的视频流进而完成整个过程的视频通话

2、即时通信(IM)和实时通信(RTC)

2.1 简介

即时通信(IM)和实时通信(声网Agora.io)都是一套网络通信系统，其本质都是对信息进行转发，其最大的特点就是对信息传递的时间规定

• 时通信(IM：Instant Messaging)：