Page 324 - Web性能权威指南

一对一连接最容易处理和部署：两端直连即可，不需要进一步优化。可是，如果对
一个 N 方呼叫扩展这个策略，那么每一端都要分别连接到其他端（网状网络），即
每一端有 N-1 个连接，总共是 N×(N-1) 个连接！如果带宽有限，特别是上行速度更
低，那么这种架构下只需少数参与端就会消耗掉用户的大多数带宽。

网状网络虽然容易建立，但对多方流交换而言往往效率很低。为解决这个问题，替代
方案是使用“星形”拓扑，让每一端连接到一个“超级节点”，由它负责向连接各方
分发流。这样，只有一个节点需要处理和分发 N-1 个流，其他节点都与它直接对话。

超级节点可以是普通的参与端，也可以是一个为处理和分发实时数据而优化过的专
用服务器。至于哪个策略更合适，还得看使用场景和应用。最简单的情况下，发起
连接的一端可以作为超级节点——简单，但效果不可能太好。更好的办法则是选择
可用吞吐量最大的通信端，但这样又需要额外的“挑选”和发信机制。

挑选条件和过程由应用决定，而这本身又是一个难题。WebRTC 没有为此
提供任何辅助机制。

最后，超级节点可以是专用的，甚至还可以是第三方服务。WebRTC 能让我们实现
端到端的通信，但这并不意味着不能考虑集中式架构！如果每一端都与代理服务器建
立连接，那么既可以利用 WebRTC 提供的传输机制，又可以使用服务器提供的服务。

端到端优化即服务

很多现有的视频会议解决方案（比如谷歌的 Hangouts）都依赖“代理服务器”汇
聚个别的媒体流，然后合成，再将优化的版本分发给连接各端。只交付一个流可
以减少对每一端带宽和 CPU、GPU 资源的占用，因为每一端只看到一个流，而非
N-1 个！
类似地，一台游戏服务器可以汇聚所有玩家的更新，通过筛选，只分发必要的更
新。比如，不给处在视野之外的玩家发送更新，也不会影响其他玩家。

两端的流交换很简单，部署效率高，而多方架构则要求考虑很多，周密规划。
WebRTC 很大程度上是为端到端直接通信服务的，因此也催生了很多其他服务，
有商业的，也有开源的。这些服务反过来又会提升 WebRTC 应用的效率，丰富其
功能。

18.7.3 基础设施及容量规划

除了规划和预测每一端的带宽需求，WebRTC 应用还需要某些集中式基础设施来发
信、穿越 NAT 和防火墙、身份验证，以及其他服务。

314 ｜ 第 18 章