作者：Tsahi Levent-Levi（原文链接）
翻译：刘通
原标题：WebRTC Scaling Challenges
WebRTC直播流中，大规模所带来的挑战
1:1 != 1:1,000,000
只要是关于WebRTC的问题，规模有影响。
人们常常有这种想法，如果我能够运行一个1对1的视频通话，那么把它改进成一个三方视频通话也很简单。如果有了三方通话，那么距离四方通话也只有一步之遥了。假如我们已经到了四个人同时通话的地步，既然4和10之间没差多少，所以10个人通话肯定也是一样的。如果我们可以进行10人通话了，那么50人，甚至100人是不是也没问题了？
处理多用户之间的互动通话的做法放在实时广播方面也是正确的。
1对1的广播与1对100不同，当然与1比10,000与1比1,000,000也不同。
不同之处源于两点：
# 你需要投入多少基础设备
# 你要如何处理网络错误
在我开始详细解释这两点之前，需要说明高效的直播要求延时低于1秒。而这正是WebRTC所擅长之处。
1. 你需要投入多少基础设备
WebRTC需要最少两种服务器：信令服务器和NAT穿越服务器。
对于1对1直播，这就足够了。我们可以以端到端的形式进行对话。
上至1对100或者左右的通话需要媒体服务器。媒体服务器的重点是从广播者那接收媒体，然后将其路由给100个观众。
最终我们得到了这样的媒体路径：
对于一个服务器来说，将输入媒体推流给所有100个观众是小菜一碟的事。
但是当我们增加了听众数量之后呢？某些时候，只有一个服务器就不足以处理这些负载了。
这种情况中，我们将被迫“连接”或者“串联”我们的媒体服务器。所以对于10,000个关注着那种来说，你最终会需要类似于下图这样的拓扑结构：
我们的“原始”服务器要把数据路由给第二级服务器，然后由它们再传给观众。
这个结构可以很好的缩放规模，但是某些时候它会崩溃。在这里让我们假设一个单一的服务器可以处理100个媒体流的负载。所以我们的原始服务器就可以将视频发送给另外100个服务器，意味着我们可以将这一个流发送给10,000个观众。
所以我们只要增加我们的链到第三级，就可以处理一百万个观众了。
这里有两个很明显的事：
1. 存在没有与广播者或者观众直接相连的服务器。
2. 我们在链上加的级数越多，就会产生越多的延迟。
可以解决吗？当然。
好解决吗？不。
2. 你要如何处理网络错误
在我们有了自己的服务器之后，一个棘手的问题就是我们要如何处理网络错误。
1对1的情况很简单。我们不处理。我们让浏览器来帮我们做这件事。做这件事的WebRTC代码已经可用并且是免费的。
增加到1对100之后就比较困难了。
WebRTC处理网络错误（数据丢包）的方式有4种：
1. 识别他们作为起点
2. 它可以提高或者降低比特率来适应当前可用带宽
3. 它可以重传错误帧，在丢包的情况下重设视频流
4. 它可以决定在视频流中加入FEC
在1对1通话中，我们已经说过了这件事我们不用亲力亲为，但是一旦我们加入了媒体服务器之后，媒体服务器也要做出这些决定。在我们的例子中，它需要根据100个观众的表现来做决定。
超过100到10,000或者1,000,000会更加难处理。稍微想一下，假设每个用户平均只有0.1%的丢包率我们要做多少事情。
增加用户数量也会导致丢包率的增长。所以，对于1,000,000个用户来说，我们完全可以说广播者发送的每个数据包都会有至少一个观众接收不到。
我们忘了些什么？
还有其他一些头疼的问题我们需要面对，我在这里只列出一部分：
1. 观众并不是统一的。他们使用不同的设备，有着不同的性能，处于不同的网络环境之下。你要如何根据这些改变参数？
2. 观众会动态的加入和离开。你要怎么处理服务器来保证高质量的服务水平和用户体验度？
3. 观众可能来自于世界各地。你会想要将用户分配到离他们最近的服务器，也是另外一个需要考虑的部署问题。
4. 可能有不止一个广播者。每个广播者都有不同的观众数。你要如何将其纳入你的配置方案？
