使用串联SFUs方式提高WebRTC媒体服务器处理性能

　　对WebRTC来说，部署媒体服务器最大的挑战来自于两个方面：一个是对于单点服务器的拓展，另外一个挑战是如何优化会议用户的语音时延。一些简单的处理方式，例如简单分片处理的方式是通过横向拓展方式来实现。这样的方式可能导致语音路径和时长失去控制，语音质量和时延问题仍然不能解决，或者可能导致更为严重的语音时延。因此，它们这种方式对于优化媒体时延仍然是一个大问题。

　　着名的开源视频会议服务器开发商Jitsi的核心开发人员Boris Grozev和他的团队利用了更加智能的方式Cascading SFUs的方式处理语音时时延问题，通过对比测试，测试结果取得了比较好的效果。Cascadiing（串联？） SFU的实现来自于基本的网络资源查询的原理，就是通过算法路由到距离客户最近的媒体服务器。以下内容是官方开发人员的具体介绍，更多完整文档参考文章链接。

　　现在的很多语音业务和会议服务器都部署在云端，用户则可能部署在世界各地，网络的稳定性会严重影响语音质量，时延，抖动，丢包，或者视频影像不清晰等问题。因此，在用户用户之间选择一个最佳的媒体路径是非常至关重要的。在WebRTC的环境中，有时是用户之间通过ICE 或者TRUN 来实现，这种场景事实上是非常简单的场景，可以支持少量用户的视频会议。但是，如果视频会议人数很多的时候，一个单点服务器很难处理大量用户的会议场景。因此，使用一种智能的方法，例如SFU是非常有必要的。下面介绍两种方式的处理机制和其策略，以及测试结果的优化。

　　首先，让我们看看使用Star的处理方式，如果三个用户在不同的地方，他们需要实现视频会议的话，可能需要经过两个服务器的处理流程，同时每个呼叫方都需要和另外两个互相连接，而且会议中的成员加入的顺序不同，可能导致连接错误或者无效的连接，这样就会浪费很多服务器和网络资源，如下图例所示，可能用户A和用户B都连接了服务器 2 而不是服务器1。

　　串联SFU的桥接方式

　　让我们看看如何使用串联的方式来解决智能选择路由和服务器的方式。通过串联的方式来处理的话，用户A 就会通过服务器1，然后对接服务器2，呼叫服务器2的用户C。这样的话，两台服务器就会被充分利用，减少了资源浪费。

　　往返时延的影响

　　连接SFU的桥接有其优势也有其劣势。其劣势是增加了多个跳转，但是如果进行了优化以后，大大减少了语音数据的往返时延。关于此策略的实现，参考链接论文有详细介绍。对于WebRTC来说，通常情况下使用RTP来传输数据，其本身具有不可靠性。如何实现视频的重新传输也是一个很大的挑战。使用单机服务器的往返时延如下，需要多次不同对象的处理。

　　使用SFU桥接的往返时间的话，重新传输仅限于本地服务器传输。例如，如果丢包发生在用户A和服务器1之间，服务器1要求用户A重传。如果丢包发生在用户C和服务器2之间，服务器2则要求用户C之间重传；如果两个服务器之间发生丢包，则要求两个服务器之间重传数据包。用户终端可以通过设置jitter buffer来缓存视频播放。根据作者结论，理论上来说，虽然，端对端的整个往返时间长于外部服务器部署方案的时间，但是端对端的时延降低。