乐趣区

关于架构:技术实践-聊聊网易云信的信令网络库实践

jiezi

导读：信令作为实时音视频技术架构中的重要一环，是对建设实时音视频通信起到要害桥梁性的作用。本文将从信令的概念着手，分享在网易云信新一代音视频技术架构下，信令的根本交互流程设计以及信令网络库的模块设计和重连优化等。

什么是信令

咱们都晓得，WebRTC 是通过 RTCPeerConnection 来做到端与端之间的实时音视频通信的，那他们是怎么晓得对方网络地位（网络数据）？反对何种编解码器（媒体元数据）？何时关上或敞开通信（会话管制）的呢？

这就须要建设一条通道来替换这些信息，而这协商的信息就是 信令 ，这条通道也就是 信令通道。咱们这里所说的信令网络库的作用就是为端和信令服务器替换信令提供网络传输的通道。那信令的作用到底是什么？

在实时通信中，信令的次要作用体现在以下四个方面：

  • 媒体性能的协商和设置。
  • 标识和验证会话参与者的身份（替换 SDP 对象中的信息：媒体类型、编解码器、带宽等元数据）。
  • 管制媒体会话、批示进度、更改会话和终止会话。
  • 当会话单方同时尝试建设或更改会话时，施行双占用合成。

总之，信令就是协调音视频实时通信的过程，一旦信令服务建设好了，两个客户端之间建设了连贯，实践上它们就能够进行点对点通信了。而值得注意的是，WebRTC 规范自身没有规定信令替换的通信形式，信令服务依据本身的状况实现。这也为咱们自定义信令服务器提供了可能。

单 PeerConnection 计划

2020 年，在疫情的冲击下，音视频通信市场失去了爆发式的增长，在视频会议、在线教育、线上金融、云游戏等各个领域都失去了长足的倒退。同时，客户也对各种利用场景下的音视频的高性能、低延时等方面提出了更高的要求。

在 2020 年 11 月，网易云信公布了 新一代音视频技术架构（简称 NERTC），具体内容可查看文末介绍，为了晋升产品性能，咱们从高可用、高并发、高性能、高扩大等方向进行了全流程的技术升级，包含新一代音视频交融通信服务端零碎、新一代音视频 SDK 以及新一代音视频引擎，其中就包含单 PeerConnection 的重构计划。

单 PeerConnection 计划波及了信令服务器的重构。其根本设计准则是次要是：

  • iOS/Android/windows/Mac/Web 多端协定统一，均采纳 Websocket 交互, 节俭服务器资源，简化服务器代码逻辑。
  • 端侧只创立 2 个 Peerconnection，一个只负责发送(sendonly)，一个只负责接管(recvonly)。
  • 采纳自定义信令协定进行交互。
  • 简化协商流程，缩小首屏工夫。

单 PeerConnection 计划根本的信令交互流程如下：

WebSocket 通信简介

前文可知，为了达到多端 (Web) 信令协定交互一致性，所以采纳了 WebSocket 作为信令传输。那 WebSocket 有什么特点？

说到 WebSocket，就离不开 HTTP。HTTP 个别限度每次连贯只解决一个申请，服务器解决完客户的申请，并收到客户的应答后，即断开连接，不过 HTTP 也有 Keep-Alive 性能放弃连贯，使得单次连贯内能够发送屡次申请。

WebSocket 是基于 HTTP 协定的，而区别于 HTTP 的最大特点在于服务器能够被动向客户端推送信息，客户端也能够被动向服务器发送信息，是真正的双向平等对话；而 HTTP 只能从端侧发动申请。从下图能够清晰看出 HTTP 与 WebSocket 之前的区别。

握手（Handshake）

WebSocket 是建设在 TCP 长连贯根底之上的，为了实现 WebSocket 的通信，借用 HTTP 协定实现了一次握手过程。具体的握手过程是这样的：

  1. 客户端发动握手申请
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
  1. 服务器返回应答
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat

这样示意握手胜利。握手胜利之后，客户端和服务器就建设了双向的数据通道，能够互发音讯（数据），不须要客户端每次都发动申请。

连贯放弃

惯例做法大家都晓得，那就是心跳机制，通过判断心跳是否有响应来判断链接是否可用。WebSocket 也不例外，其协定规定了 ping/pong 机制来放弃连贯。咱们能够看下 ping/pong 在 RFC6455 具体是怎么规定的。

5.5.2. Ping
The Ping frame contains an opcode of 0x9.
A Ping frame MAY include “Application data”.
Upon receipt of a Ping frame, an endpoint MUST send a Pong frame in response, unless it already received a Close frame. It SHOULD respond with Pong frame as soon as is practical. Pong frames are discussed in Section 5.5.3.
An endpoint MAY send a Ping frame any time after the connection is established and before the connection is closed.
NOTE: A Ping frame may serve either as a keepalive or as a means to verify that the remote endpoint is still responsive.

5.5.3. Pong
The Pong frame contains an opcode of 0xA.
Section 5.5.2 details requirements that apply to both Ping and Pong frames.
A Pong frame sent in response to a Ping frame must have identical “Application data” as found in the message body of the Ping frame being replied to.
If an endpoint receives a Ping frame and has not yet sent Pong frame(s) in response to previous Ping frame(s), the endpoint MAY elect to send a Pong frame for only the most recently processed Ping frame.
A Pong frame MAY be sent unsolicited. This serves as a unidirectional heartbeat. A response to an unsolicited Pong frame is not expected.

由上可知，一端通过发送 ping 帧，对端收到 ping 帧后，响应一个 pong 帧，这样就实现了一次连贯的检测，并且它是单向的。

敞开连贯

当敞开 WebSocket 通信的时候，发动端须要发送一个敞开帧，对方收到敞开帧，如果未曾发送过敞开帧，则须要发送一个敞开帧作为响应。敞开帧能够携带利用数据，用来阐明敞开的起因。最初等到底层 TCP 连贯敞开后，整个 WebSocket 通信就齐全敞开了。

在 NERTC 中的利用

网易云信在新一代音视频技术架构中，是如何应用这些技术来实现信令的传输通道呢？上面咱们先从模块设计方面和重连方面的设计做一些介绍。

一个根本准则：应用层不须要关怀音讯失落、乱序、重发等问题。家喻户晓，TCP 提供牢靠的传输服务，通过 TCP 连贯传送的数据无差错、不失落、不反复且按序达到。TCP 通过校验、重传管制、序号标识、滑动窗口、确认应答来实现牢靠传输，如丢包时的重发管制，还能够对秩序乱掉的分包进行顺序控制。这样，咱们只须要解决的就是重连和重发问题。

网络库架构设计

下图是 NERTC 的网络库架构图设计：

咱们简略介绍其中的几个模块：

  • API 局部定义的是网络库模块的对外接口，由应用层调用。
  • Transport 模块次要形象了音讯收发和连贯治理的性能，ws/wss 以及将来的 quic 协定扩大等都基于其虚接口实现。
  • Message 模块治理 WebSocket 子协定的组包和解包。
  • SendBuffer 治理 Message 的缓存和重发。
  • Peer 作为外围模块，实现对 Transport、Message 等所有模块的管制。

接下去咱们看下快连贯快重试和重连设计优化。

疾速连贯和重连设计

上面咱们按不同的场景来介绍下网络库是如何运作以及做了哪些工作，局部场景能够联合下图来了解。

  • 场景一：首次连贯时的退却策略。当应用层（简称 SDK）首次尝试连贯时，如果 WebSocket 连贯胜利，则返回 SDK，SDK 发动信令协商；如果连贯失败，应用每隔 200/400/600ms 的疾速重试屡次连贯的策略。如果最终都失败的话，则回调给应用层 onFail 事件。
  • 场景二：连贯胜利后的断开重连策略。如果曾经连贯胜利，因为网络起因或者服务器等起因导致连贯断开，则触发此策略。触发形式分为两种，一种形式是，WebSocket 告诉了 onClose 事件；另外一种是被动探测的形式，通过 ping/pong 机制来触发重连。后者通过发送 ping 帧三次，每次距离 3s，超时 1.5s，如果三次均无奈失去 pong 帧，则认为网络或者服务器异样，触发此场景的重连策略。具体的策略是，每隔 2/4/6s 触发一次连贯尝试，如果最终还是失败的话，回调给应用层 onDisconnected 事件。
  • 场景三：应用层收到 onDisconnected 事件，会切换新的 server 地址，从新通过网络库尝试连贯，直到 server 用尽，退出当次通话。
  • 场景四：当网络切换或者复原可用时，应用层会被动触发重连。
  • 场景五：服务器被动敞开连贯时，网络库清空音讯缓存，并且不再尝试重连。

重连场景如下图所示：

音讯缓存和重发

其实下面的时序图曾经蕴含了音讯发送和重发的机会。音讯分为两种：

  • Request 类型音讯，须要期待服务器的 Response，须要缓存。
  • Notification 类型音讯，不进入音讯缓存，当然也有可能是服务器发送过去的告诉。

咱们这里只讲端侧的音讯发送。音讯的发送和重发都只在连贯胜利后触发。

每一条音讯都会先进入发送缓存队列（即 SendBuffer），如果以后连贯失常，则间接发送，如果连贯断开则会暂停发送，期待连贯或重连胜利之后才会复原发送。因为依赖于 TCP 的牢靠传输，所以音讯的重发均只产生在重连胜利之后。当连贯被服务器 kick off 或者应用层被动敞开时，peer 对象会清空所有缓存音讯，不再做发送或重发的尝试。

弱网下的体现

在弱网下，咱们的测试数据发现，最多能抗 50% 的丢包率。在实测场景中，高丢包率状况下，媒体流 的 QoS 激进策略下会发送大量的冗余包和重传包，从而导致带宽资源几近耗尽。这会导致什么呢？

WebSocket 连贯可能会失败，音讯可能无奈收发。咱们都晓得 TCP 是通过滑动窗口和拥塞窗口来做的流控。当已发字节数等于对方的接管窗口字节数时，就会导致发送窗口满（TCP Window FULL）了，从而无奈再发送数据。有趣味的同学能够理解 TCP 相干的概念。这种状况下根本只能通过触发断开重连的机制，敞开老的连贯，新建连贯进行音讯的重发。

将来布局

为了加强弱网状况下的抗性，咱们会思考 UDP 作为优化的方向，比如说 QUIC(Quick UDP Internet Connection)协定等，目前也根本曾经靠近产品化阶段，这里就不再赘述，敬请期待 QUIC 版本的体现。

总结

本文从信令的基本概念以及作用动手，简要地讲述了网易云信新一代音视频技术架构中信令网络库根本交互流程、模块化设计思路以及网络库根本运作形式。另外，也对连贯重试和重连的设计和优化做了一些阐述。同时，也十分欢送跟咱们交换更多对于信令网络库的实现。

作者简介

丁永锋，网易云信资深客户端开发工程师，始终致力于客户端跨平台开发，目前负责音视频客户端跨平台 SDK 开发，曾负责 Unity&Cocos2dx SDK 以及网易云信 IM SDK 的跨平台开发工作。

延长浏览

  • 网易云信流媒体首席架构师：新一代音视频技术架构如何构建？
  • 聊聊 WebRTC 网关服务器 2：如何抉择 PeerConnection 计划？

更多技术干货，欢送关注【网易智企技术 +】微信公众号

退出移动版