技术分享| anyRTC服务单端口设计

传统的CDN比如RTMP直播，是基于tcp的服务，并不存在端口过多的情况；而RTC服务大多数用的是udp端口，这种Udp模式有很多的优点，但是相比于RTMP直播服务器单端口走天下，RTC服务动则要开几百个端口略显尴尬。

RTC绝大多数都是udp通讯，在进行互通的时候需要开放很多端口, 一个音/视频通道就要开启多个通道, 如果是多人音视频通话需要开通的端口更多. 对端口资源照成了很大的浪费, 一些防火墙会限制多udp端口的开放。如果要部署在服务端, 多端口的开发会给运维照成极大的不方便。

有的人会说，开放多个端口也没什么，实际场景中用着也没有出现问题。确实多端口本身没有问题，可以放心使用，我们只是在此基础上提出一种优化方案。

那么多端口到底有什么不足呢？

1）很多的网络出口防火墙对能够通过的UDP端口是有限制的。

2）对于服务端来说开辟这么多端口，安全性本身也有一定的问题，很容易被黑客扫描到进行攻击，特别是运维同学，更是拒绝。

3）开辟这么多的端口在Server端上，端口的开销和性能均有一定的影响。

4）行业特性要求，特别是金融、公安等对安全性要求特别高的行业，多端口是不可接受的。

如何减少RTC服务中端口的使用，甚至能否只使用1个端口呢？

目前为止已经有很多成熟的减少端口使用的策略:

1）Rtp/Rtcp复用端口的方案Rtcp-mux。

2）音视频的Boundle, 可以让音视频复用连接通道。

3）多路流复用单连接的plan b和unified plan方案；PS：WebRTC的M89版本正式废弃plan b，所有WebRTC标准都已经转向了unified plan。

这些策略都在不断的在消减端口的使用, 但即使上面的这些策略全部开启, 单个用户还是要占用最少一个端口, 如果一个RTC服务器要服务500个用户, 就要开启500个端口。

如何实现单端口，为我们需要了解一些技术点，这样实现起来思路就会更清晰：

1）SDP offer和answer里配置的ice-ufrag字段里面内容，STUN Binding Request里面的USERNAME字段就是由上Offer和answer的ice-ufrag内容拼接而成，这是用来作为stun数据包的鉴权的，因此可以作为一个标识为我们所用。

2）发送STUN Binding Request的客户端本地udp socket，与ice建连成功后发送媒体数据的udp socket是同一个，那么对于服务端来说，客户端的ip port是同一个。

让我们来看看实现细节是怎么样的：

1）在服务端给客户端的SDP Answer中设置 ice-ufrag为本服务上唯一的ID，其中ID可以设计成业务层分配的内容，也可用于区分每对通话以及参与者。接着做Ice candidate协商，客户端开始做连通性检测，也就是stun binding request里的USERNAME为SDP local和remote的ice-ufrag指定内容。

2）服务端收到stun binding request的客户端ip和端口，并正常回stun binding response。

3）服务端记录客户端地址与用户的信息的映射关系。

4）服务端收到一个rtp/rtcp媒体数据包，通过包的源ip和端口，查询映射表就可以识别这个包属于哪个连接的流。

这样就可以实现一个单端口模式的RTC服务，非常的简单。这里再给一个闭坑提示，在实际场景中，客户端的网络容易发生变化，比如手机的wifi切换成了4/5G网络，此时手机的外部出口ip端口已发生了变化，需要及时在服务端更新，否则会出现黑屏现象。