NATトラバーサルを達成することができるならば、それ自体が、STUN / TURNの補助で、1通信モデル1が設けられているのWebRTC、2つのブラウザは、直接メディアデータを交換することができる。NATトラバーサルが達成されない場合、のみを介してTURNサーバーの通信は、データ転送を実現します。ここでは、学習と基礎研究のためのGoogleのオープンソースプロジェクトは、1対1の通信STUN / TURNのに基づいています。
あなたが達成したい場合は - のWebRTCによる多くの通信を、どのように？
実際には、のWebRTCのオープンソースプロジェクト - 多くのリアルタイム通信に基づいて、多くの人が一緒に、そこにある、マルチパーティ通信アーキテクチャは、以下次の3つのオプションよりも何もありません。
- メッシュ構造を形成するために対で接続されている複数の端末間で、すなわち、実施例メッシュ。そのようなA、B、Cの三多くの通信端末として、Aは（例えばオーディオ、ビデオなど）の共有メディアしたいとき、それは、それぞれ、B及びCにデータを送信する必要があります。同様に、共有メディアへのBほしいですが、それは別にAに必要であり、Cは、データを送信し、というように。このアプローチは、各端末の帯域幅が比較的高いが必要です。
- サーバと複数の端末星形構造から成るMCU（マルチポイント会議ユニット）方式。各端末は、混合されたすべての端末でストリーミングサーバに彼らのビデオとオーディオストリームは、サーバは、オーディオとビデオの同じ部屋になります共有したい、そして最終的に混合されたオーディオストリームを生成し、そのように各その、各端末に配信されますターミナルあなたが見ることができます/オーディオとビデオのもう一方の端を聞きます。実際には圧力がサーバー側のオーディオおよびビデオ・ミキサーで、このプログラムは非常に大規模なサーバーになります。
- 組成によってサーバと複数の端末であるが、MCUは異なるSFU（選択的転送ユニット）方式、後、SFUないミックスされたオーディオおよびビデオは、端末は、直接オーディオ及びビデオストリームのシェアを受け取ります部屋のもう一方の端へのオーディオおよびビデオストリーム。これは、実際に映像と音声のルーティングフォワーダです。
上記の後、いくつかの通信インフラを学び、その後、我々はアーキテクチャのこれらのタイプについて説明します。
1対1通信
前に、多くのアーキテクチャモデルは、我々は最初の場所に反映されているだけで1対1の通信モデルは非常に明確であるので、我々は最終的に多くの通信モデルには多くの複雑さを知ることができ、モデル1対1通信のWebRTCを確認する必要があります。
1対1通信、二つの端末間のP2P直接通信を介してのWebRTC最初の試みかどうか、それが直接通信できない場合、以下に示すように、STUN / TURNサーバを介して通過することになります。
WebRTC 1対1のオーディオおよびビデオのリアルタイムコール概略図
現時点では、我々は非常に精通し把握する必要があります。実際には、1対1の通信モデルの主な目的は、二つの端子が直接接続されているようにしようするように設計されているので、それは、サーバーのリソースを節約することができ、またサービス品質のオーディオとビデオを向上させることができます。
クライアントとクライアントとの間の直接通信は、その後、STUN / TURNサーバ上の画像の効果は、単に各端末種別reflx候補のために収集した場合。端部間の端末と直接通信しない場合は、STUN / TURNサーバは、中継サーバになり、それは、クライアントとクライアント間のデータ転送のために使用することができます。
メッシュプログラム
1対1の通信モデルでは、2つの端子は、我々はより多くのそれを伝えるよりも、達成するために相互に接続された複数の端子を有することができるかどうかを、相互に接続することができますか？
理論的にはこれは完全に実現可能です。メッシュ構造のスキームを以下に示します。
ソリューションアーキテクチャ図をメッシュ
上記の図では、B1、B2、B3、B4はまた、STUN / TURNサーバとのデータ転送を行うことができないこの場合、STUN / TURNサーバに（接続されている4つのブラウザペアワイズがその間に接続表し、又は状況は、このようにメッシュトポロジーを形成し、）非常に複雑になります。
ブラウザは、オーディオとビデオのストリーミングを共有したい場合は、メディアストリームは、人々がコミュニケーションを実現するように、他の三つのブラウザに送信されている共有することになります。
この構造の利点は次のとおりです。
- サーバーは、NATトラバーサルのための唯一の責任転送データ、STUN / TUTNする必要はありませんので、既存のWebRTCの通信モデルを使用すると、メディアサーバを開発する必要なしに達成することができます。
- クライアントの帯域幅のリソースをフルに活用。
- 保存サーバリソース、サーバーの帯域幅は、それが高価であり、多くの場合、緑であるので、このプログラムは、十分に制御することができ、コストので。
当然，有优势自然也有不足之处，主要表现在：
- 共享端共享媒体流的时候，需要给每一个参与人都转发一份媒体流，这样对上行带宽的占用很大。参与人越多，占用的带宽就越大。除此之外，对 CPU、Memory 等资源也是极大的考验。一般来说，客户端的机器资源、带宽资源往往是有限的，资源占用和参与人数是线性相关的。这样导致多人通信的规模非常有限，通过实践来看，这种方案在超过 4 个人时，就会有非常大的问题。
- 另一方面，在多人通信时，如果有部分人不能实现 NAT 穿越，但还想让这些人与其他人互通，就显得很麻烦，需要做出更多的可靠性设计。
MCU 方案
MCU 主要的处理逻辑是：接收每个共享端的音视频流，经过解码、与其他解码后的音视频进行混流、重新编码，之后再将混好的音视频流发送给房间里的所有人。
MCU 技术在视频会议领域出现得非常早，目前技术也非常成熟，主要用在硬件视频会议领域。不过我们今天讨论的是软件 MCU，它与硬件 MCU 的模型是一致的，只不过一个是通过硬件实现的，另一个是通过软件实现的罢了。MCU 方案的模型是一个星形结构，如下图所示：
MCU 方案架构图
我们来假设一个条件，B1 与 B2 同时共享音视频流，它们首先将流推送给 MCU 服务器，MCU 服务器收到两路流后，分别将两路流进行解码，之后将解码后的两路流进行混流，然后再编码，编码后的流数据再分发给 B3 和 B4。
对于 B1 来说，因为它是其中的一个共享者，所以 MCU 给它推的是没有混合它的共享流的媒体流，在这个例子中就是直接推 B2 的流给它。同理，对于 B2 来说 MCU 给它发的是 B1 的共享流。但如果有更多的人共享音视频流，那情况就更加复杂。
MCU 主要的处理逻辑如下：
那 MCU 的优势有哪些呢？大致可总结为如下几点：
- 技术非常成熟，在硬件视频会议中应用非常广泛。
- 作为音视频网关，通过解码、再编码可以屏蔽不同编解码设备的差异化，满足更多客户的集成需求，提升用户体验和产品竞争力。
- 将多路视频混合成一路，所有参与人看到的是相同的画面，客户体验非常好。
同样，MCU 也有一些不足，主要表现为：
- 重新解码、编码、混流，需要大量的运算，对 CPU 资源的消耗很大。
- 重新解码、编码、混流还会带来延迟。
- 由于机器资源耗费很大，所以 MCU 所提供的容量有限，一般十几路视频就是上限了。
SFU 方案
SFU 像是一个媒体流路由器，接收终端的音视频流，根据需要转发给其他终端。SFU 在音视频会议中应用非常广泛，尤其是 WebRTC 普及以后。支持 WebRTC 多方通信的媒体服务器基本都是 SFU 结构。SFU 的拓扑机构和功能模型如下图：
SFU 方案架构图
在这个图中，B1、B2、B3、B4 分别代表 4 个浏览器，每一个浏览器都会共享一路流发给 SFU，SFU 会将每一路流转发给共享者之外的 3 个浏览器。
下面这张图是从 SFU 服务器的角度展示的功能示意图：
SFU 功能示意图
相比 MCU，SFU 在结构上显得简单很多，只是接收流然后转发给其他人。然而，这个简单结构也给音视频传输带来了很多便利。比如，SFU 可以根据终端下行网络状况做一些流控，可以根据当前带宽情况、网络延时情况，选择性地丢弃一些媒体数据，保证通信的连续性。
目前许多 SFU 实现都支持 SVC 模式和 Simulcast 模式，用于适配 WiFi、4G 等不同网络状况，以及 Phone、Pad、PC 等不同终端设备。
SFU 的优势有哪些呢？：
- 首先 由于是数据包直接转发，不需要编码、解码，对 CPU 资源消耗很小。
- 其次是 直接转发也极大地降低了延迟，提高了实时性。
- 最后 带来了很大的灵活性，能够更好地适应不同的网络状况和终端类型。
同样，SFU 有优势，也有不足，主要表现是：
由于是数据包直接转发，参与人观看多路视频的时候可能会出现不同步；相同的视频流，不同的参与人看到的画面也可能不一致。
参与人同时观看多路视频，在多路视频窗口显示、渲染等会带来很多麻烦，尤其对多人实时通信进行录制，多路流也会带来很多回放的困难。总之，整体在通用性、一致性方面比较差。
通过上面的分析和比较，综合它们各自的优劣情况，我们可以得出 ，SFU 是三种架构方案中优势最明显而劣势又相对较少的一种架构方案。
无论是从灵活性上，还是音视频的服务质量、负载情况等方面上，相较其他两种方案，SFU 都有明显的优势，因此这种方案也被大多数厂商广泛采用。
另外，在上面介绍 SFU 方案时，我们还提到了视频的 Simulcast 模式和 SVC 模式，他们是什么呢，又对 SFU 架构来说都带来了哪些好处呢。
1. Simulcast 模式
所谓 Simulcast 模式就是指视频的共享者可以同时向 SFU 发送多路不同分辨率的视频流（一般为三路，如 1080P、720P、360P）。而 SFU 可以将接收到的三路流根据各终端的情况而选择其中某一路发送出去。例如，由于 PC 端网络特别好，给 PC 端发送 1080P 分辨率的视频；而移动网络较差，就给 Phone 发送 360P 分辨率的视频。
Simulcast 模式对移动端的终端类型非常有用，它可以灵活而又智能地适应不同的网络环境。下图就是 Simulcast 模式的示意图：
Simulcast 模式示意图
2. SVC 模式
SVC 是可伸缩的视频编码模式。与 Simulcast 模式的同时传多路流不同，SVC 模式是在视频编码时做“手脚”。
它在视频编码时将视频分成多层——核心层、中间层和扩展层。上层依赖于底层，而且越上层越清晰，越底层越模糊。在带宽不好的情况下，可以只传输底层，即核心层，在带宽充足的情况下，可以将三层全部传输过去。
如下图所示，PC1 共享的是一路视频流，编码使用 SVC 分为三层发送给 SFU。SFU 根据接收端的情况，发现 PC2 网络状况不错，于是将 0、1、2 三层都发给 PC2；发现 Phone 网络不好，则只将 0 层发给 Phone。这样就可以适应不同的网络环境和终端类型了。
SVC 模式示意图
小结
以上我主要和大家分享了三种多方通信的架构，分别是 Mesh、MCU 和 SFU。
整体来看，由于各方面限制，Mesh 架构在真实的应用场景中几乎没有人使用，一般刚学习 WebRTC 会考虑使用这种架构来实现多方通信。
MCU 架构是非常成熟的技术，在硬件视频会议中应用非常广泛。像很多做音视频会议的公司之前都会购买一套 MCU 设备，这样一套设备价格不菲，最低都要 50 万，但随着互联网的发展以及音视频技术越来越成熟，硬件 MCU 已经逐步被淘汰。
当然现在也还有公司在使用软 MCU，比较有名的项目是 FreeSWITCH，但正如我们前面所分析的那样，由于 MCU 要进行解码、混流、重新编码的操作，这些操作对 CPU 消耗是巨大的。如果用硬件 MCU 还好，但软 MCU 这个劣势就很明显了，所以真正使用软 MCU 架构方案的公司也不多。
SFU 是最近几年流行的新架构，目前 WebRTC 多方通信媒体服务器都是 SFU 架构。从上面的介绍中你也可以了解到 SFU 这种架构非常灵活，性能也非常高，再配上视频的 Simulcast 模式或 SVC 模式，则使它更加如虎添翼，因此各个公司目前基本上都使用该方案。
然后我们目前的阶段性目标就是先实现Mesh方案，再逐步深入。