前置知识
STUN、TURN和ICE
- STUN(SessionTraversalUtilitiesforNAT，NAT会话穿越应用程序)
- 是一种服务器，允许位于NAT之后的客户端找出自己的公网地址，查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端端口
- 一句话概括就是告诉我们
公网IP地址和端口是什么 - 不路由媒体，只是在防火墙和NAT上打洞
- TURN(Traversal Using Relays around NAT)
- 意味着中继你的媒体，并非用于所有的会话，可以在所有连接上保留TURN服务器，因为只会在需要的时候使用
- 是STUN/RFC5389的一个拓展，主要添加了Relay的功能
- 直白点就是在STUN分配公网IP失败后，可以通过TURN服务器请求公网IP地址作为中继地址，这种方式的宽带由服务器端承担 → 当两个设备之间无法直接连接时会用到TURN服务器
- 当终端在NAT之后，在某些情况下，有可能使得终端无法和其他对等端(peer)进行直接的通信，此时就需要一个公网的服务器作为一个中继，对来往的数据进行转发，这个转发的协议就被定义为TURN
- 在国内，至少一半的网络是无法直接穿透打通连接的，这种情况下只能借助TURN服务器中转
- 好的TURN服务器是非常昂贵的，在自己的项目中应该使用自己的服务器或者付费TURN服务器
- TURN上中继WebRTC数据的方式有IPv4(推荐)和IPv6、UDP(推荐)、TCP或TLS进行连接
- UDP是最有效的，因为WebRTC最了解何时以及如何关联网络拥塞以及是否使用重传，但存在失败的可能，因此有可能会使用TCP或TLS
- ICE
- ICE和STUN、TURN不一样，不是一种协议，是一个框架，其整合了STUN和TURN
- 在WebRTC中，用来描述网络信息的术语叫做
Candidate，用来描述媒体信息的术语叫做SDP - 比较TURN、STUN和ICE
- TURN、STUN是一个服务器，而ICE不是，ICE是一个协议，这是WebRTC决定是否在会话中使用TURN的方式
- 推荐文献
拓展补充
- 信令服务器不只是用来交换媒体信息SDP和网络信息Candidate的，还用来管理房间、管理人员进出房间等
- 在对等连接的iceServers配置中，不要放置超过3-4个服务器(意味着1个STUN、一个TURN/UDP、一个TURN/TCP、一个TURN/TLS)，过多的服务器意味着更多的连接检测和更多的时间，直到将所有的东西连接起来
- 对于典型的WebRTC媒体服务器，建议是配置TURN/TCP和TURN/TLS传输并且删除TURN/UDP选项 → 因为可以直接访问媒体服务器的公网IP地址，所以没必要使用TURN/UDP，但只是建议，因为在某些情况下还是会被连接阻止，如随机端口会被阻止，而UDP端口443是保持打开的状态
- 将会话连接到WebRTC媒体服务器后还需要TURN服务器的
- 原因是：WebRTC媒体服务器不支持TLS类型的传输，有时会通过ICE-TCP支持TCP，对于无法通过其他方式连接呼叫的情况，将需要使用TURN/TCP或TURN/TLS
连接WebRTC会话的3种方式
- 通过本地网络直接连接
- 如果两个设备都在本地网络上，那么就可以不通过任何特别的工作就可以直接建立连接
- 大多数情况下都不是这样的
- 通过Internet使用公共IP地址直接连接
- 直接通过STUN获取的公网IP地址连接WebRTC
- 当设备不在同一个网络中时，可以STUN服务器告知询问的设备“自己的公网IP地址”是什么
- 上述步骤成功后就可以 通过公网IP地址让设备相互连接
- 据统计：大约80%的连接可以通过使用本地IP地址或使用STUN和公网IP地址来解决
- 通过WebRTC TURN服务器路由媒体
- 当知道公网IP地址后由于NAT和防火墙有可能还是会失败，或者没有获取到公网IP，这两种情况下可以通过TURN的中间服务器来实现交互
- 某些防火墙会阻止某些类型的流量，大多只是阻止UDP，有些甚至可能会阻止TCP
实时互动关键技术
实时互动关键技术包括专有基础设施、专业组件和重要共生技术，
- 专有基础设施
- 是面向实时互动场景的，其核心包括实时网络、传输协议、边缘计算、算力支撑和终端适配等；
- 实时网络RTN
- 智能路由与智能调度
- 软件定义时的实时网络
- 传输协议
- 弱网兼容与抵抗
- 通常将高丢包、高延迟、高抖动的网络称为弱网
- 弱网对抗技术主要包括
抗丢包、拥塞退避、宽带估计、抗抖动四个方面 - UDP协议
- 无连接传输层协议、提供面向事务的简单不可靠信息传送服务
- 不提供数据包分组、封装、排序、不产生额外的数据 → 数据传输时间短、实时性高
- RTP实时传输协议
- 定义流媒体数据在互联网上传输的数据包格式
- RTCP实时传输控制协议(媒体质量反馈协议)
- 负责可靠传输、流量控制和拥塞控制等服务质量保证
- IETF的RTP/RTCP协议是实时互动通信的基石，该两个模块作为传输模块的一部分；
- 负责对发送端采集到的媒体数据进行封包，然后交给上层网络模块分发
- 接收端在RTP/RTCP模块收到上层模块的数据包后，对媒体数据进行解包操作，最后把负载发送到解码模块
- 弱网兼容与抵抗
- 边缘计算
- 容器化
- 混合部署
- 云原生技术
- 终端适配
- 感知设备
- 网络连接能力
- 交互技术和设备
- 计算能力
- 通用计算(由CPU进行)
- 图形渲染(由GPU进行)
- 图像处理(用于采集图像)
- 视频编解码(Codec，用于图像/视频的压缩与还原)
- 神经网络/AI处理(用于终端AI硬件加速)
- 专业组件
- 是在专用基础设施上，用于处理实时音视频等数据的音视频引擎、云加速、实时信令、数据处理、人工智能等技术
- 音视频引擎
- 音视频编解码技术
- 将数字音视频数据进行压缩和解压缩的算法与工程技术，解决了数据传输中的低采样率、低编解码还原度、低编解码算法、高丢包率等的问题，同时保证了实时音视频的稳定传输
- API编解码技术
- 指基于人工智能的音视频编解码算法与工程技术结合，提高实时音视频互动和并发数和低宽带情况下的音视频质量
- 音频3A技术
- 语音增强前处理，主要负责拾取近端环境中的目标声音，同时抑制包括回声和噪声在内的干扰信号，提高通话、录音、识别等场景上的上行音频信号质量
- 空间音频技术
- 网络体验数据
- 多种网络技术和算法相结合的工程技术，包括ARQ自动重传请求、FEC前向纠错、NetEQ音频网络抖动缓冲器、JitterBuffer视频网络抖动缓冲器、GCC拥塞控制算法等
- 音视频编解码技术
- 实时信令
- 支持超低延迟、数以亿计的高并发场景，分布式的实时信令技术不仅可以传输实时控制指令和消息、同时也可以实时同步用户自定义的状态等
- 提供可靠、高并发的实时分布式信令控制技术，丰富实时互动场景的沉浸感
- 实时控制指令
- 实时消息
- 实时状态同步
- 数据处理
- 实时数据检测与分析工具
- 分布式数据库
- 人工智能
- AI推理引擎降低了AI算力的需求，实现了提效降费
- 语音合成、自动语音识别
- 实时变声技术、背景分割技术
- 美颜、手势、表情、姿势识别
- 数字孪生与虚拟替身
- 重要共生技术
- 是指实时互动应用过程中，为解决重要的衍生问题而诞生的技术
- 低代码
- 基于低代码平台标准化交付的组件、模版与数据连接器
- 可视化编辑工具
- 安全方面
- 基础设施安全
- 网络传输安全
- 通过资源隔离、频道隔离、加密传输、身份认证、SDK安全等控制措施为开发者及用户提供安全稳定的服务
- 数据安全
- 最小化的数据采集原则、数据脱敏、数据保护和加密传输、数据使用和存储
- 运营安全
超低延时的协议对比
WebRTC
WebRTC支持音频和视频的实时，双向通信，主要负责音视频的推流和分发，其端到端的延迟在300~600ms之间
- 理论上WebRTC可以通过连接两个浏览器客户端(P2P)建立视频会议系统，然而现实的视频架构并不是如此简单
- 通常终端并不是直接连接互联网，而是要经过几个网络层，比如NAT、防火墙或者代理等
- 为了解决上述的问题，WebRTC允许使用ICE(Interactive Connectivity Establishment，交互连接建立)协议，该协议可以帮助找到让两台机器通信的最直接路径，并穿过不同的网络层
- 为此需要使用STUN/TURN服务器来获取用户的外部地址并在无法直接连接时负责通信数据转发
- 在大部分的WebRTC通信中，WebRTC协议需要(除了自身的多媒体服务器基础设施外)一组STUN/TURN服务器支持高质量的通信
- WebRTC协议要求端到端之间所有通信数据必须加密(音频、视频和数据应用)
- 因此需要内嵌一些安全协议来填补使用UDP协议时的空白;
- 如DTLS(Datagram Transport Layer Security，数据包传输层安全协议)用于生成签名证书来进行加密信息的协商(用于Peer之间加密媒体数据以及应用数据的安全传输)
- SRTP(Secure Real-Time Transport，安全实时传输协议)用于音频和视频的加密传输
- SCTP(Stream Control Transport Protocol，流控制传输协议)用于应用数据的加密传输
- 因此需要内嵌一些安全协议来填补使用UDP协议时的空白;
- WebRTC协议支持多种网络架构服务模型，每种架构对应一种特定的应用场景，且有自己的优劣势
- SFU(Selective Forwarding Unit，选择性转发单元)是比较流行的架构
低延迟HTTP ABR流媒体传输协议
与P2P的WebRTC协议相比，基于HTTP的流媒体协议需要使用服务器且在标准的HTTP上进行通信，构建于Web最基础的部分之上；
- HLS（HTTP Live Streaming）/LL-HLS协议用于向全球范围内的观众传输直播和点播的内容，与2009年由Apple推出，其特色是延迟较大的超大规模音视频分发技术，平均延迟在15s左右，但HLS的延迟却达到了30s~1min，不过其依然是最受欢迎的ABR流媒体协议，成功的原因在于强大的设备兼容性以及支持多种高级的功能，如影藏字幕、广告、使用AES加密或DRM的内容保护等
- 可以实现视频的推流，但常用于视频的分发，一般与之配合的是使用RTMP协议进行推流
- LL-HLS是基于HLS协议的拓展，在保证了HLS自身可拓展的同时，还可以利用子切片和这些切片的动态传输来实现低延迟视频和直播
- HLS的所有功能在LL-HLS中都可以找到，本身依然保持着对http2协议的依赖
- LL-HLS在实现低延迟做出的重要更新
- 子切片(Partial Segments)：一个切片在原有的基础上被分割成多个子切片，为了减少宽带，一旦产生完整的切片，与其相关的切片就会从播放列表中移除
- 预加载提示（Preload hints）：媒体播放列表有一个“预加载提示”标签，它可以使播放器预知将有哪些新的子切片，以便于服务器在数据可用时立即响应播放器的新切片请求
- 播放列表增量更新（Playlist Delta Updates）：通过使用新的EXT-X-SKIP标签，播放器可以仅请求媒体播放列表的更新部分，从而节省已有数据的传输成本
拓展阅读
教育行业的直播技术
实现屏幕内容广播的方案
所谓屏幕广播就是指将计算机的屏幕情况发送给多台电脑，使得那些电脑也可以显示出指定计算机的电脑桌面，一般是在电子教室之类的教学软件中使用；一般采用UDP进行传输
- 采用UDP协议理由
- UDP中有一种多播的技术，UDP多播通过向一个多播组中发送一个数据，那么只要是这个组中的主机都会收到同样的一份副本，因此如果需要向10个主机发送一个100KB的图片，只需要向一个多播组发送100KB的图片即可，其他主机都会收到这个数据，这样就大大减少了数据传输量
- 使用TCP时，就需要将该数据分别传输到目标的所有主机上，加大了数据传输量
- 基本思路
- 创建UDP套接字
- 加入多播组
- 每个主机只能加入一个多播组一次，后续的都会失败
- 开始发送/接收数据
- 数据不保证完整正确的到达接收方
- 数据包大小有限制，所以当传输较大文件时，就需要进行分割成若干部分进行发送，但是不保证数据有序到达对方，也可能出现丢包或者乱序的情况，网络上一般的解决方案都是将出现问题的数据通知请求方重新发送，但是不适用于屏幕广播这种情况
- 适用于屏幕广播的方案：利用了UDP数据包的数据结构
- 发送方只关注数据的发送，其他的由接收方执行
- 发送方工作：将数据进行切割成多个包，并打上相应的字段信息进行标识
- 接收方工作：根据自身维护的「期望收到的数据包序号」进行数据接收与维护
- 参考文献：屏幕广播的实现
- 拓展 → 无线多播传输解析方案
- 无线多播传输利用了无线信道的广播特性，将在传输过程中对特定资源有相同需求的所有用户作为一个多播组，并将所有相同信息同时送达所有的多播用户，也可以显著提高系统的频谱效率
- 利用无线多播“点到多点”的传输特性，可以满足同一业务的多个数据请求并利用同一频谱资源传输
- 存在的问题是多播用户间的无线信道存在波动，质量不同，存在解码失败的情况，因此如何提高传输可靠性是无线多播业务面临的重要技术挑战
- 基于单播传输方案
- 点对点的传输
- 最简单的传输就是点对点的传输，也称单播，分为单向和双向两种方式，这种传播方式可以用于视频文件的传输和音频文件的传输；
- 视频点播就是一种单向的视频传输，通常是一个视频文件单独为一个用户服务
- 双向就是在两个网络终端之间进行传输，如网络电话
- 双向传输的方式比单向可能消耗更多的网络宽带，导致网络的使用率降低
- 最简单的传输就是点对点的传输，也称单播，分为单向和双向两种方式，这种传播方式可以用于视频文件的传输和音频文件的传输；
- 单点对无限多点传输
- 这是一种全体的广播方式，如发送音视频的服务器，通常是将音视频发送到与之连接的所有节点
- 好处是不需要控制音视频传输的路由，每个接受者都可以接收到
- 缺点是非个性化服务，容易造成流量泛滥
- 单点对预先选定的多点传输
- 属于多播，是将用户按照需求分成很多组，只将音视频传输到某个需要该音视频服务的用户
- 好处是节省了网络资源
- 缺点是需要复杂的组成员登记操作和完善的视频多播路由选择、建立与维护机制
- 多点对多点的传输
- 是会议的形式，如网络会议
- 网络会议是指两个或两个以上的不同地方的人或群体通过传输路线及多媒体设备将声音、影像及文字资料互传，达到即时互动的沟通
- 处于该传播网络中的每一方都可以发送自己的视频，也可以接收任一方传输的数据
- 是会议的形式，如网络会议
- WLAN的重传和确认机制：WLAN为了解决丢包的问题，减轻物理层丢包引起的传输层的处理延迟，设计了重传和确认机制，从而确保了数据的及时并可靠到达
- 有限制条件是：只针对传输数据是单个接收设备的情况
- 因此，使用单播方案时，讲师主机需要将每一帧屏幕的数据分别分发给每一个平板设备，每一台设备都可以收到完整的视频帧数据，画面画质优异
- 优点是：画面质量高
- 缺点是：需要更高性能的路由和平板设备，且屏幕内容分享的延时较大
- 点对点的传输
- 基于多播传输方案
- 单播传输方案中，当接收者变多时，需要将每一帧视频数据分别分发给每个设备，会加大物理层宽带的压力，因此引入了多播传输方案
- 物理层广播的数据可以同时被多个终端接收，接收设备过多时也不会对物理层产生明显的变化
- 广播数据在物理层无重传和确认机制，因此在无线信号受到干扰时存在视频帧丢失或花屏的问题
- 优点是：对设备性能要求低，网络时延低
- 缺点是：存在视频帧丢失或花屏的问题
- 低性能设备上多用户时可以达到高视频质量和低时延方案
- 主要问题分析
- 如何减少对WLAN物理层宽带的需求且保证传输可靠性
- 在所有设备都通过WLAN进行数据交换时，物理层宽带传输将受到极大的影响(平板从10增加到60时，从无线路由器到平板的传输数据宽带降低近50%)
- 如何提高视频的压缩效率
- 传统的视频编解码都是通过捕获摄像头的视频数据，其视频帧率的采集和编码是固定的，但在屏幕内容广播时屏幕内容表现出不同的信号特征且屏幕内容变化慢一般都是部分区域的变化，因此传统的采集和视频编解码方式效率低下
- 如何减少对WLAN物理层宽带的需求且保证传输可靠性
- 解决方案一 → 可靠的双通道混合传输方案
- 组合使用TCP协议和UDP的组播协议进行屏幕内容数据传输
- TCP协议在WLAN的物理层对应为单播传输，只有一个设备接收对应的数据，可靠性高
- UDP的组播在WLAN的物理层对应广播传输，可以有多个设备接收数据，通过UDP组播发送一次视频帧数据
- 若有个别设备未能接收到完整的数据则使用TCP重新补发，从而保证了所有设备都可以完整可靠的接收的视频数据帧数据
- 但未能正确接收数据的设备毕竟是极少数的，因此可以节省大量的物理层宽带需求
- 组合使用TCP协议和UDP的组播协议进行屏幕内容数据传输
- 解决方案二 → 端到端的视频编码优化方案
- 可进一步减少网络宽带的需求
- 提高编码效率的手段
- 手段一：采用可变帧率编码方式：当检测到屏幕内容变化后再编码，无变化时无需编码，从而减少相同的编码帧，降低网络宽带，减少网络时延
- 手段二：采用屏幕内容编码技术
- 最开始的屏幕内容编码是通过HEVC的拓展实现的，而常见的AVC和HEVC编码器没有内置这个拓展，需要自己实现屏幕内容的编码端和解码端，导致了这个过程只能在自有的封闭系统里运行，不能与业界互通；
- 新一代的AV1和VVC编码标准，已经将屏幕内容编解码作为标准的一部分，内置于WebRTC开源平台，被基于Chromium的浏览器原生支持
- 主要问题分析
- 针对超高清直播所面临的视频高质量编码、音频清晰采集和音视频低延时传输等问题的创新技术合集
- 在WebRTC框架和RFC7798标准，新添加压缩率更高的视频格式支持，可以有效的提高画面质量
- WebRTC在实时音视频方面继承了优秀的算法来解决弱网问题、丢包问题和网络抖动等问题；
- 通过向WebRTC引入新的视频压缩编码格式技术，提升了WebRTC的视频质量，减少了网络宽带和设备性能的要求
- 通过对AI技术的引入，可以实现对音频的3A增强处理，甚至实现空间音频、语音定向增益，实现大空间的任意位置的语音采集
- WebRTC本身在视频编解码方面对视频格式支持有限，原生的都是使用软件进行编解码，当视频分辨率增大到4K，码率增加到25Mbps时，编解码时延超过150ms
- 业界大多开源项目都是基于特定的硬件来实现自身平台的视频硬件编解码，通过对视频编解码的抽象，支持了业界所有的GPU型号，并与WebRTC对接，从而加快了视频编解码的速度，降低了端到端的时延
- 在WebRTC框架和RFC7798标准，新添加压缩率更高的视频格式支持，可以有效的提高画面质量
