较早前，从WebRTC流的角度分析了Digital Ocean中标准服务器配置的可能性，我们注意到一台服务器最多可为2000名观众提供服务。 在现实生活中，经常会出现一台服务器不够用的情况。
假设德国的兴奋迷们观看了澳大利亚的实时赛马。 由于赛马不仅是马术运动，而且是按时下注的重大胜利，因此视频的播出应尽可能少地延误。
另一个例子。 一家全球性公司是FCMG市场的领导者之一，在欧洲，俄罗斯和东南亚设有子公司，该公司正在组织网络研讨会，以培训从地中海总部转播的销售经理。 观看者应实时查看和收听演示者。
这些示例结合了以下要求：以低延迟将媒体流交付给大量观众。 为此，您需要部署内容交付网络-CDN。
请注意，使用HLS的经典流传输技术不适用，因为它可能会延迟30秒，这对于实时显示至关重要。 想象一下，马匹已经到达终点线，结果已发布在网站上，而球迷们仍在检查比赛。 WebRTC技术剥夺了这个缺点，WebRTC技术可以在1秒内提供延迟，而现代的通讯渠道甚至在各大洲之间也可以实现。
首先，让我们看看如何部署最简单的CDN来交付WebRTC流，然后对其进行扩展。
CDN结构
CDN中的服务器可以执行以下角色之一：
- Origin是用于发布媒体流的服务器。 将流分发到其他服务器，也可以分发给订户。
- 转码器-专门用于对流进行转码的服务器。 从Origin服务器接收流，并将转码后的流分发到Edge。 我们将在下一部分中处理这个角色。
- Edge-旨在将流分发给订户的服务器。 它从Origin或Transcoder服务器获取流，而不将流分发到其他CDN服务器。
您可以将WebRTC和RTMP流发布到原始服务器，或通过RTMP，RTSP和其他可能的方法从其他来源捕获流。
订阅者可以通过WebRTC，RTMP，RTSP，HLS播放来自边缘服务器的流
在CDN服务器之间，希望通过WebRTC进行流传输以减少延迟。
在配置阶段将完整描述静态CDN。 实际上，设置静态CDN类似于设置负载平衡器：所有接收器都列在流源服务器的设置中。
例如，我们在法兰克福有一个Origin服务器，在纽约有一个Edge，在新加坡有一个
在这种情况下，Origin的配置如下：
<loadbalancer mode="roundrobin" stream_distribution="webrtc"> <node id="1"> <ip>edge1.thestaticcdn.com</ip> <wss>443</wss> </node> <node id="2"> <ip>edge2.thestaticcdn.com</ip> <wss>443</wss> </node> </loadbalancer>
这是静态CDN的第一个问题：为了将新的Edge服务器添加到此类CDN，或从CDN中删除服务器，您需要更改设置并重新启动所有Origin服务器。
在Origin上发布的流将广播到Edge设置中列出的所有服务器。 订户将连接到哪些边缘服务器的决定也由原始服务器决定。 这是第二个问题：例如，如果没有观众或观众很少，例如，在傍晚的新加坡和深夜，在纽约，流仍将广播到Edge1。流量是闲置的，根本不是免费的。
动态CDN可以解决这两个问题。
因此，我们要配置CDN而不重新启动所有原始服务器，也不想将流传输到没有订阅服务器的边缘服务器。 在这种情况下，您无需将CDN服务器的整个列表保留在设置中。 每个服务器本身必须创建一个这样的列表，为此，它必须在任何给定时间知道其他服务器的当前状态。
理想情况下，在设置中应该足以指定CDN从其启动的入口点。 在此入口点，每个服务器在启动时都应发送请求，并接收CDN节点列表和已发布流的列表作为响应。 如果入口点不可用，则服务器应期待来自其他服务器的消息。
服务器应将其状态的任何更改发送到CDN中的其他服务器。
最简单的CDN：在欧洲中心
因此，让我们尝试配置和运行动态CDN。 假设，对于初学者来说，我们需要向欧洲观众分发视频流，同时必须支持多达5,000个用户。 假设流量的来源也位于欧洲。
我们在欧洲数据中心部署了三台服务器。 我们将使用Flashphoner WebCallServer（WebRTC流视频服务器）作为构建CDN的元素。
设置：
cdn_enabled=true cdn_ip=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=origin
cdn_enabled=true cdn_ip=e-eu1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=edge
cdn_enabled=true cdn_ip=e-eu2.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=edge
动态CDN节点之间的消息传递是通过Websocket进行的，当然，还支持Secure Websocket。
在CDN内部，流是通过WebRTC广播的。 通常，UDP用作传输方式，但是如果需要确保服务器之间的通道质量不是很好，则可以切换到TCP。 las，在这种情况下，延迟增加了。
我们重新启动服务器，在o-eu1上打开“双向流”示例，发布带有倒数计时器的循环视频（从10分钟到0）
在e-eu1上打开Player示例，播放流
并在e-eu2上执行相同e-eu2
CDN有效！ 正如您在屏幕快照中所看到的，由于WebRTC和良好的频道，视频中的时间在发布端和观众中重合了一秒钟。
无处不在：连接美国
现在，我们将向美洲大陆的观众传递视频流，并且我们不会忘记该出版物。
在不禁用CDN欧洲部分的情况下，我们在美国数据中心部署了三台服务器
设置：
cdn_enabled=true cdn_ip=o-us1.flashponer.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=origin
cdn_enabled=true cdn_ip=e-us1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=edge
cdn_enabled=true cdn_ip=e-us2.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=edge
我们重新启动美国服务器，我们检查发布
和繁殖
同时，欧洲部分继续运作。 检查美国订阅者是否会看到欧洲发布的信息流。 我们在o-eu1上发布test_eu流
并在e-us1上播放
而且它也有效！ 至于延迟，我们在屏幕截图中再次观察到计时器在发布端的视频中以及在观看者中的计时器重合，直到一秒钟。
请注意，默认情况下，无法在原始服务器上直接播放在其他原始服务器上发布的流，但是如果需要，可以像这样配置它
cdn_origin_to_origin_route_propagation=true
待续
因此，我们部署了一个简单的CDN，然后将其成功扩展到两个大洲，发布并播放了低延迟的WebRTC流。 同时，我们没有在播放过程中更改流的参数，这在现实生活中经常是需要的：所有观众都拥有不同的频道，并且为了保持广播质量，有必要例如降低分辨率或比特率。 我们将在下一部分中做...
参考文献
低延迟WebRTC流CDN是基于 Web呼叫服务器的内容交付网络。