作者：Tsahi Levent-Levi（原文链接）
翻译：刘通
原标题：Do I Need a Media Server for a One-to-Many WebRTC Broadcast?
一个字回答：要。
这是我这个星期经常被问到的问题。答案也很简单—是的，需要。
接着我收到了一个没有预料到的提问：
为什么需要？
这有点让我措手不及。倒不是因为我不知道答案。而是因为我不知道如何用简短的文字来回答他。我想这也不是一个简单的问题。
简单的答案是资源的限制，以及我们不控制大部分这些资源的事实。
硬性上限
无论何时我们想要将两个浏览器使用流直接连接，都需要创建并使用对等连接。
Chrome 65版本包含了用于垃圾收集目的的上限。Chrome不允许超过500个并发对等连接同时存在。
500是一个非常大的数字了。如果你准备使用多余10个的并发对等连接，那么你应该是知道自己在做什么的人之一（并且不需要本篇文章的帮助）。对于所有我能记得参与过的用例来说，超过50的基本上都是一个坏主意。
你需要认清楚资源是有限的。免费并在浏览器中实施并不意味着不会产生任何相关费用，或者不需要在实现过程中出人出力。
比特率，速度以及反馈
这应该是你无法使用WebRTC或者任何其他技术进行广播的主要原因了。
我们正在触碰的是WebRTC中充满挑战的部分。媒体处理很难。而实时媒体处理更难。
假设我们想以低VGA分辨率广播一个视频。我们已经检查并确定了500kbps的比特率可以满足我们的需求。
如果我们向10个人播放我们的数据流，会发生什么？
将我们的数据流广播到10个人，需要5Mbps的上行链路比特率。
如果我们使用的是ADSL连接，那么我们只有1-3Mbps的上行链路，所以我们将无法向我们的10个观众广播该流。
大部分情况下，我们无法控制广播者的目标。是通过ADSL？还是无线WiFi？还是连接不畅的3G网络？当我们开始处理广播时，我们需要做出这些假设。
这是关于10个观众的。那如果我们要面对的是100个观众？1000个？或者100万个？
使用媒体服务器，我们要决定网络的连接性，服务器的机器类型等等。我们可以决定把媒体服务器级联起来以扩大我们的广播规模。我们对这种情况会有更多的控制。
所以广播WebRTC媒体流需要媒体服务器。
发送端一致性
这点在网格状群组通话中很常见，但是在广播中也同样重要。
当我们将WebRTC用于广播类型的服务时，很多决定最终都会发生在媒体服务器中。如果观众所处的网络环境不好，则会导致丢包，报告给媒体服务器。那么媒体服务器在这种情况下会做什么呢？
虽然没有一个简单的答案来回答这个问题，但是其中包括了这些选项：
# 要求广播者发送一个新的I-帧，这会影响所有的观众，并在不就的将来增加带宽使用。
# 要求广播者降低比特率和媒体质量以适应丢包，这不仅仅会影响不良网络上的观众，也会影响到所有收看者
# 忽略丢包的问题，牺牲部分观众给其他人提供“更好”的服务
# 使用同播或SVC，并将观众转移到较低媒体质量的较低“层”，而不会影响其他用户。
你不能在浏览器中完成大部分操作。浏览器倾向于使用相同的单一编码流发送给所有其他用户，并且在多用户方面正确估计带宽做得不好。这不是设计成或者实施成这样的。
你需要一个媒体服务器
在大多数情况下，某些时候你需要一个媒体服务器。
如果你正在广播，那么媒体服务器是强制性的。谷歌不提供这样的美俄费服务，甚至不提供针对该用例的开源代码。
这不意味着媒体服务器不能拥有—只是需要你更加努力。
