You need to enable JavaScript to run this app.
导航
视频直播
  • 文档首页
    • /视频直播/超低延时直播/超低延时直播技术白皮书/信令传输
信令传输
最近更新时间：2023.02.14 14:38:36首次发布时间：2022.03.11 19:36:52
我的收藏

本章节介绍 HTTP、UDP 和 QUIC 信令交互。

HTTP 信令交互

  • 方案优势：兼容性优秀，支持浏览器/客户端互通，信令传输可靠性优秀。
  • 方案弊端：在 RTT 较大或网络信号不稳定等弱网环境下，HTTP 信令建联成功率不理想；导致播放请求响应缓慢或超时，特指基于信令数据包庞大且发生 TCP 重传导致的信令响应速度不理想。
  • 传输手段：基于 HTTP 应用层超文本传输协议传输标准 SDP 信令，在客户端/服务端完成数据传输。

HTTP SDP 信令交互流程如下图所示。

alt

信令请求流程

  1. 客户端生成 offer SDP；
  2. 客户端将 offer SDP 通过 HTTP 协议向信令服务器发送数据请求 offer request ；
  3. 服务端收到 offer SDP 请求，对指定媒体数据源进行回源处理，查询到音视频的媒体信息，生成标准的应答 SDP；
  4. 服务端将应答 SDP 通过 HTTP 协议向发起请求客户端发送数据响应 answer response；
  5. SDP 双方协商完毕，进行 ICE 建联；客户端向服务器查询网络地址，并与服务器双方沟通完毕，完成握手；
  6. 按照传统 P2P 建联流程，开始 RTP 数据传输，播放开始。

停止播放流程

停止播放流程有 2 种选择，详细说明请参见媒体传输结束处理。

  • 推荐：利用 RTCP 媒体反馈通道，向媒体服务器发送停止命令 RTCP Bye 消息；
  • 备选：利用 UDP socket 向信令服务器发送停止命令（stop command），信令服务器控制媒体服务器，停止传输数据；

说明

腾讯云、阿里云和火山引擎均支持 2 种停止播放流程。

UDP 信令交互

UDP 信令交互分为 UDP 标准模式和 UDP 快速模式 2 种。

UDP 标准模式

  • 方案收益：降低首帧渲染时间，提高播放秒开率和成功率。
  • 方案劣势：在强制使用加密鉴权地区安全性合规问题无法有效保证，Web 浏览器无法支持。
  • 传输手段：采用 MiniSDP 压缩信令方式利用 UDP 网络传输；预期单个 UDP 数据包请求即可完成 SDP 完整压缩信息的传输。

MiniSDP 信令交互流程

alt

信令请求流程

  1. 客户端生成 offer SDP；
  2. 客户端将标准 SDP 按照指定协议压缩成 MiniSDP；
  3. 客户端将 MiniSDP（offer SDP）通过 UDP socket 向信令服务器发送数据请求（offer request）；
  4. 服务端收到 MiniSDP 请求，按照指定协议解压缩还原成标准 SDP；
  5. 服务端根据标准 SDP 进行 FLV 数据的回源，查询到音视频的媒体信息，生成标准的 SDP；
  6. 服务端将标准 SDP 按照指定协议压缩成 MiniSDP；
  7. 服务端将 MiniSDP（answer SDP）通过 UDP socket 向发起请求客户端发送数据响应 answer response；
  8. 客户端将 MiniSDP 按照指定协议解压缩还原成标准 SDP；
  9. 按照传统 P2P 建联流程，开始 RTP 数据传输，播放开始。

停止播放流程

与 HTTP 信令交互停止播放流程相同，详情请参见停止播放流程。

UDP 快速模式

UDP 快速模式通过信令和媒体数据传输通道复用的方式，将 ICE 建联过程的时间从首帧渲染的开销计算中移除。

信令请求流程

与 UDP 标准模式不同，快速模式下，交互式连接建立过程与媒体数据传输解码并行。即在 ICE 建联时，服务端同步发送媒体数据给客户端进行解码渲染。

  • UDP 标准方案：等待 ICE 建联完成之后， 服务端才会向客户端发送媒体数据 RTP Packet；
  • UDP 快速方案：复用 UDP 信令通道。信令成功后，在 ICE 建联之前，服务端直接通过信令通道发送媒体数据 RTP Packet；当 ICE 建联完毕之后，服务端将切换成新的 socket 媒体通道，继续发送 RTP Packet。

UDP 快速模式的信令请求流程如下图所示。

alt

  1. 客户端通过 MiniSDP 与服务端建立信令通道；
  2. 服务端将 remote answer 传递给客户端；
  3. 客户端进行 ICE 建联，同时服务端将包含音视频数据的 RTP 数据包下发给信令套接字 socket；
  4. 客户端激活 WebRTC，客户端内部（PeerConnection）的视频接收引擎 video_recv_pipeline 使 RTP 数据包能顺利进入传输模块 transport 中；
  5. ICE 建联完毕之后，服务器将 RTP 数据包下发给传输模块的套接字 socket。

QUIC 信令交互

QUIC 信令交互为安全性补充版本。QUIC 和 HTTP/UDP 方案存在如下差异。

  • 标准化 SDP 信令 HTTP/HTTPS 传输 CDN 支持度最好，但是信令建联时间最长，成功率在弱网下不高；
  • 现有 MiniSDP 信令裸 UDP 通道传输性能最优秀，但是安全性无法保证，弱网成功率有提升；
  • MiniSDP over QUIC 预期安全性优秀，信令建联时间预期在 HTTP 和 UDP 指标中间位置，弱网成功率相比 UDP 无显著负向；
  • QUIC 最终收益：提升互联网的传输安全。因为 QUIC 传输的内容默认都是加密的，这对人们的隐私保护非常重要。

QUIC 标准模式

MiniSDP Over QUIC 信令交互流程如下图所示。

alt

QUIC 首次连接

  1. 客户端生成 offer SDP。
  2. 客户端将标准 SDP 按照指定协议压缩成 MiniSDP 。
  3. 客户端发送 inchoate hello 给服务端，询问服务端公钥。
  4. 服务端返回 rejection，带上服务端的公钥、证书和随机数。
  5. 客户端验证证书，计算对称密钥 K1，发送 full hello，带上客户端的公钥和随机数，以及被对称密钥 K1 加密的 MiniSDP offer，利用 HTTP/1.1 的 POST 方法在建连好的 QUIC 通道上发送 MiniSDP data buffer (MiniSDP over QUIC)。
  6. 服务端再次收到客户端应答，按照指定协议将接收的 MiniSDP 解压缩还原成标准 SDP。
  7. 服务端根据标准 SDP 进行媒体数据的回源，查询到音视频的媒体信息，生成标准的 answer SDP。
  8. 服务端将标准 SDP 按照指定协议压缩成 MiniSDP 。
  9. 服务端生成临时的 server 公钥 2，计算前向安全的对称密钥 K2，返回 server hello，以及被对称密钥 K2 加密的 MiniSDP answer。
  10. 客户端将 MiniSDP 按照指定协议解压缩还原成标准 SDP。
  11. 按照传统 P2P 建联流程，开始 RTP 数据传输，播放开始。

QUIC 非首次连接

  1. 客户端生成 offer SDP。
  2. 客户端将标准 SDP 按照指定协议压缩成 MiniSDP。
  3. 客户端发送 full hello，带上客户端的公钥和随机数，以及用保存下来的 server config（包含 server 公钥）计算出来的对称密钥 K1 加密的 MiniSDP offer（MiniSDP over QUIC）。
  4. 服务端再次收到客户端应答，按照指定协议将接收的 MiniSDP 解压缩还原成标准 SDP。
  5. 服务端根据标准 SDP 进行媒体数据的回源，查询到音视频的媒体信息，生成标准的 answer SDP。
  6. 服务端将标准 SDP 按照指定协议压缩成 MiniSDP。
  7. 服务端生成临时的 server 公钥 2，计算前向安全的对称密钥 K2，返回 server hello，以及被对称密钥 K2 加密的 MiniSDP answer。
  8. 客户端将 MiniSDP 按照指定协议解压缩还原成标准 SDP。
  9. 按照传统 P2P 建联流程，开始 RTP 数据传输，播放开始。

QUIC 失败降级

客户端与服务端进行 QUIC 连接时设置超时等待时间，超时后根据设置的重试次数发起重连尝试，数次尝试失败后降级到其它拉流方式如 HTTP-FLV 或者 HLS。

  • 首次连接（1-RTT-signaling）：客户端保存服务端公钥，服务端也保存自己的 server 公钥。服务端保存的 server 公钥一个星期过期，客户端保存的 server 公钥不过期。
  • 非首次连接（0-RTT-signaling）：客户端 0-RTT 连接时，如果返回 server hello，则 0-RTT 连接成功；如果返回 rejection，重新开始 1-RTT 的连接过程。
  • QUIC 数据发送（MiniSDP）：服务端开通支持 QUIC 协议的端口，客户端通过域名访问监听某个 UDP 端口的 QUIC 服务器，MiniSDP 的数据通过 HTTP/1.1 的 POST 方法，在 QUIC 通道上将请求发送至对端 (HTTP/HTTPS类型包装)。

QUIC 快速模式

QUIC 快速模式通过信令和媒体数据传输通道复用的方式，将 ICE 建联过程的时间从首帧渲染的开销计算中移除。

信令请求流程

与 QUIC 标准模式不同，快速模式下，交互式连接建立过程与媒体数据传输解码并行。即在 ICE 建联时，服务端同步发送媒体数据给客户端进行解码渲染。

  • QUIC 标准方案：等待 ICE 建联完成之后， 服务端才会向客户端发送媒体数据 RTP Packet；
  • QUIC 快速方案：复用 UDP（quic-minisdp）信令通道。信令成功后，在 ICE 建联之前，服务端直接通过信令通道发送媒体数据 RTP Packet；当 ICE 建联完毕之后，服务端将切换成新的 socket 媒体通道，继续发送 RTP Packet。

QUIC 快速模式的信令请求流程如下图所示。

alt

  1. 客户端通过 QUIC 协议与客户端建立信令通道；
  2. 服务端将 remote answer 传递给客户端；
  3. 客户端进行 ICE 建联，同时服务端将视频 RTP 数据包下发给信令套接字 QUIC。
  4. 客户端激活 WebRTC 客户端内部的视频接收引擎 video_recv_pipeline，使 RTP 数据包能顺利进入传输模块 QUIC-transport 中；
  5. ICE 建联完毕之后，服务器将 RTP 数据包下发给传输模块 transport 的套接字 socket。

QUIC 规范说明

QUIC-minisdp 信令交互白皮书采用 gQUIC，后续会继续演进支持 IETF QUIC。