聊聊 WebRTC 网关服务器1:如何选择服务端端口方案?

《聊聊 WebRTC 网关服务器》系列文章系由 WebRTCon2018 中网易云信音视频技术专家的分享内容《从零开始构建音视频网关服务器》整理而成,该系列文章将和你们分享网易 NRTC 在 WebRTC 网关项目的自研过程当中遇到的一些问题,以及咱们最终的解决方法。

《聊聊 WebRTC 网关服务器》第一篇文章将和你们分享如何选择服务端的端口方案。git

标准 WebRTC 链接创建流程

在讨论如何选择服务器端的端口方案前,咱们先来看看标准 WebRTC 的链接创建流程,这为咱们理解这篇文章后续内容提供最基础的知识。github

图片描述
这里描述的是 Trickle ICE 过程,而且省略了通话发起与接受的信令部分。流程以下:web

  1. WebRTC A 经过 Signal Server 转发 SDP OFFER 到 WebRTC B。WebRTC B 作完本地处理之后,经过 Signal Server 转发 SDP ANSWER 到 A。
  2. A、B 同时向 STUN Server 发送 Binding request 请求自身的外网地址,并从 STUN Server 回包的 MAPPED-ADDRESS 中获得各自的外网地址;
  3. A、B 收集完内外网 ICE Candidate,并经过 Signal Server 发送给对方;
  4. 双方开始作 NAT 穿越,互相给对方的 ICE Candidate 发送 STUN Binding Request;
  5. NAT 穿越成功,A、B 之间的 P2P 链接创建,进入媒体互通阶段。在这个过程当中,咱们看到了有三个核心的部分,SDP 协商、ICE Candidate 交换、Stun Binding Req/Res 的连通性检查。

WebRTC网关链接创建流程

在了解了标准 WebRTC 的建连流程之后,咱们来看看 WebRTC 客户端如何与网关建连。算法

图片描述

首先,咱们网关的 Media Server 拥有公网 IP,所以 Server 就不须要经过 Stun Server 收集自身的公网 IP。WebRTC 客户端先与网关 Signal Server 协商 SDP,包括 ICE Candidate,Media Server 分配 IP 和端口做为网关的 ice candidate 发送给客户端。由于网关是公网 IP,因此客户端向这个 IP 发送 STUN Binding Request 会被服务器收到, 并回复 Response。接着客户端与网关媒体服务器进行 DTLS 握手与秘钥协商,在此基础上进一步进行 SRTP 的音视频通讯。至此,WebRTC 客户端与网关服务器建连成功。
好的,如今咱们已经具有了探讨服务器端端口选择的基础知识,接下来咱们来看看具体有哪些方案。安全

WebRTC 网关服务器媒体架构

图片描述

最简的服务器端端口方案是咱们能够为每一个客户端分配一个端口,服务器上使用这个端口区分每一个用户,就像图里描述的 A、B、C、D 四我的在 WebRTC 网关服务器上分别对应 UDP 端口 10001~1004。这种方案逻辑上很简单,不少开源的服务器都采用这个方案,如 janus。另一个缘由是使用了 libnice 库在服务器上来和客户端作 ice 建连,相似的作法都是采用多端口的架构。
那么多端口有什么不足呢?服务器

  1. 不少的网络出口防火墙对可以经过的 UDP 端口是有限制的;
  2. 对于服务端来讲开辟这么多端口,安全性自己也有必定的问题,特别是网易的运维同窗,更是拒绝;
  3. 开辟这么多的端口在 Server 端上,端口的开销和性能均有必定的影响。那可否用单端口?使用单端口前,核心要解决的一个问题是:如何区分每个 RTP/RTCP 包是属于哪个 WebRTC 客户端。

为了解决这个问题,咱们须要使用一些小技巧。首先,有几个基础知识点咱们先了解一下。以下图:微信

图片描述

  1. SDP offer 和 answer 里配置的 ice-ufrag 字段里面内容,原来是用来做为stun数据包的鉴权的,所以 STUN Binding Request 里面的 USERNAME 字段就是由上 Offer 和 answer 的 ice-ufrag 内容拼接而成。
  2. 发送 STUN Binding Request 的客户端本地 udp fd,与 ice 建连成功后发送媒体数据的 udp fd 是同一个,也就是说 Server 上看到的 ip port 是同一个。

有了上面的背景知识,聪明的大家确定已经大体有一个方案了。咱们来看看实现细节是怎么样的:网络

  1. 在服务器给 Web 端的 SDP Answer 中设置 ice-ufrag 为roomid/userid,其中 RoomID 和 UserID 是通话业务层分配的内容,用于区分每统统话以及参与这。接着作 Ice candidate 协商,Web端开始作连通性检测,也就是 stun binding request 里的USERNAME 为 SDP local 和 remote 的 ice-ufrag 指定内容。
  2. 服务器收到 stun binding request 的客户端 ip 和端口,并正常回 stun binding response。
  3. 记录客户端地址与用户的信息的映射关系。
  4. 服务器收到一个 rtp/rtcp 媒体数据包,经过包的源 ip 和端口,查询映射表就能够识别这个包属于哪一个用户。
在分享完服务端端口选择的方案后,你们都知道 WebRTC 客户端使用 PeerConnection 来表示不一样的媒体链接,这对于 WebRTC 来讲是基础也是核心,在《聊聊 WebRTC 网关服务器》第二篇文章将继续为你们介绍如何选择 PeerConnection 的方案。

随着音频处理和压缩技术的不断发展,效果更好、适用范围更广、性能更高的算法和新的技术必将不断涌现,若是你有好的技术或者分享,欢迎关注网易 MC 官方博客以及微信公众号:**架构

关注更多技术干货内容: 网易云信博客
欢迎关注 网易云信 GitHub
欢迎关注 网易云信官网

官网微信公众号:
图片描述运维

相关文章
相关标签/搜索