webrtc cdn_低延迟WebRTC流的动态CDN

webrtc cdn

Having analyzed earlier the capacity of standard server configurations in Digital Ocean in terms of WebRTC streaming, we have noticed that one server can cover up to 2000 viewers. In real life, cases when one server is insufficient are not uncommon.

前面已经根据WebRTC流分析了Digital Ocean中标准服务器配置的容量，我们注意到一台服务器最多可以覆盖2000个观众。 在现实生活中，一台服务器不足的情况并不罕见。

Assume gambling amateurs in Germany are watching real-time horse races in Australia. Given that horse races are not only a sports game but also imply big gains on condition that field bets are made at the right time, the video has to be delivered with lowest possible latency.

假设德国的赌博业余爱好者正在澳大利亚观看实时赛马。 鉴于赛马不仅是一场体育比赛，而且意味着在适当的时间进行现场下注的情况下获得巨大收益，因此必须以尽可能低的延迟来交付视频。

Another example: A global corporation, one of FCMG market leaders with subsidiaries in Europe, Russia and Southeast Asia, is organizing sales manager training webinars with live streaming from the headquarters in the Mediterranean. The viewers must be able to see and hear the presenter in real time.

另一个例子：一家全球性公司是FCMG市场领导者之一，在欧洲，俄罗斯和东南亚设有子公司，该公司正在组织销售经理培训网络研讨会，并通过地中海总部进行实时直播。 观众必须能够实时查看和收听演示者。

These examples put forward the same requirement: deliver low latency media streams to a great number of viewers. This will require deploying a content delivery network — CDN.

这些示例提出了相同的要求：向大量观众提供低延迟的媒体流。 这将需要部署内容交付网络-CDN。

It should be noted that the conventional stream delivery technology using HLS is not well-suited as it can add up to 30 second delays, which are critical for a real-time show. Imagine that the horses have already finished, the results have been published on the website, while the fans are still watching the end of the race. WebRTC technology is free from this disadvantage and can guarantee less than 1 second delays, which is possible even across continents thanks to modern communication channels.

应该注意的是，使用HLS的传统流传输技术不太适合，因为它可能会增加多达30秒的延迟，这对于实时显示至关重要。 想象一下，马匹已经完成，结果已经发布在网站上，而车迷们仍在观看比赛的结束。 WebRTC技术摆脱了这一缺点，可以保证不到1秒的延迟，这得益于现代的通讯渠道，即使在各大洲也可以实现。

To begin with, we will see how to deploy the simplest CDN for delivering WebRTC streams and how to scale it afterwards.

首先，我们将看到如何部署最简单的CDN来交付WebRTC流，以及随后如何扩展它。

CDN原则 (CDN principles)

A server in CDN can play one of the following roles:

CDN中的服务器可以扮演以下角色之一：

• Origin is the server built for publishing media streams. It shares streams to other servers as well as users.
  Origin是为发布媒体流而构建的服务器。 它共享流到其他服务器以及用户。
• Transcoder is the server dedicated for transcoding streams. It pulls streams from the Origin server and passes transcoded streams to Edge. We will look at this role in the following part.
  代码转换器是专用于代码流转换的服务器。 它从Origin服务器提取流，并将转码后的流传递到Edge。 在下面的部分中，我们将研究这个角色。
• Edge is the server designed for sharing streams to users. It pulls streams from Origin or Transcoder servers and does not pass them to other CDN servers.
  Edge是设计用于向用户共享流的服务器。 它从Origin或Transcoder服务器提取流，并且不将其传递到其他CDN服务器。

Origin server allows publishing WebRTC and RTMP streams or capturing streams from other sources via RTMP, RTSP or other available methods.

原始服务器允许发布WebRTC和RTMP流，或通过RTMP，RTSP或其他可用方法从其他来源捕获流。

Users can play streams from Edge servers via WebRTC, RTMP, RTSP, HLS.

用户可以通过WebRTC，RTMP，RTSP，HLS播放来自边缘服务器的流。

In order to minimize latency, it is desirable to transmit streams among CDN servers using WebRTC.

为了最小化等待时间，期望使用WebRTC在CDN服务器之间传输流。

Static CDN is entirely described at the configuration stage. In fact, the setup of a static CDN is similar to the setup of a load balancer: all the receivers are listed in the settings of the stream source server.

静态CDN在配置阶段进行了完整描述。 实际上，静态CDN的设置类似于负载平衡器的设置：所有接收方都列在流源服务器的设置中。

For example, we have one Origin server in Frankfurt, one Edge in New York and one in Singapore

例如，我们在法兰克福有一台Origin服务器，在纽约有一台Edge，在新加坡有一台

In this case Origin will be set up more or less like this:

在这种情况下，将按以下方式设置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>

Here comes the first issue with the static CDN: in order to include into this kind of CDN a new Edge server or exclude a server out of a CDN, it is required to modify the settings and restart all Origin servers.

静态CDN的第一个问题是这样的：为了在这种CDN中包括新的Edge服务器或从CDN中排除服务器，需要修改设置并重新启动所有Origin服务器。

The streams published on Origin are broadcast to all Edge servers listed in the settings. The decision on which Edge server the user will connect to is also taken on Origin server. Here comes the second issue: if there are few or no viewers — for example, in Singapore it’s early evening while in New York it’s the middle of the night — the streams will be broadcast to Edge 1 anyway. The traffic is being wasted to no purpose, and it is not free of charge.

在Origin上发布的流将广播到设置中列出的所有Edge服务器。 用户将连接到哪个边缘服务器的决定也由原始服务器决定。 这是第二个问题：如果观众很少或没有观众(例如，在新加坡，这是傍晚，而在纽约，这是深夜)，无论如何，这些流都将广播到Edge 1。 交通浪费是没有目的的，它不是免费的。

These two issues can be solved using Dynamic CDN.

使用动态CDN可以解决这两个问题。

Now, we want to set up the CDN without restarting all Origin servers and do not want to transmit streams to Edge servers with no users connected. In this case, there is no need to keep the whole list of CDN servers somewhere in the settings. Each server must create such a list independently. In order to do this, it must know the current status of the other servers at any specific time.

现在，我们希望在不重新启动所有原始服务器的情况下设置CDN，并且不想在没有用户连接的情况下将流传输到边缘服务器。 在这种情况下，无需将CDN服务器的整个列表保留在设置中。 每个服务器必须独立创建这样的列表。 为此，它必须在任何特定时间知道其他服务器的当前状态。

Ideally, specifying the entry point — the server which begins the CDN — in the settings should be enough. During startup each server must send a request to this entry point and get in response the list of CDN nodes and published streams. If the entry point cannot be accessed, the server must wait for messages from other servers. The server must communicate any changes in its status to other servers in the CDN.

理想情况下，在设置中指定入口点(启动CDN的服务器)就足够了。 在启动过程中，每个服务器必须向该入口点发送请求，并作为响应获得CDN节点和已发布流的列表。 如果无法访问入口点，则服务器必须等待来自其他服务器的消息。 服务器必须将其状态的任何更改传达给CDN中的其他服务器。

最简单的CDN：在欧洲中心 (The simplest CDN: in the centre of Europe)

Now we are going to try setting up and starting a dynamic CDN. Assume first we need to deliver media streams to viewers in Europe covering up to 5000 users. Suppose the stream source is also located in Europe

现在，我们将尝试设置并启动动态CDN。 首先假设我们需要向欧洲的观众提供多达5000个用户的媒体流。 假设流源也位于欧洲

We are going to deploy three servers in a data center based in Europe. We will use Flashphoner WebCallServer (WebRTC stream video server) instances as CDN assembly components

我们将在欧洲的数据中心中部署三台服务器。 我们将使用Flashphoner WebCallServer(WebRTC流视频服务器)实例作为CDN组件

Setup:

建立：

• Origin EU
  欧盟原产地

cdn_enabled=true
cdn_ip=o-eu1.flashponer.com
cdn_nodes_resolve_ip=false
cdn_role=origin

• Edge 1 EU
  优势1欧盟

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

• Edge 2 EU
  Edge 2欧盟

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

Message exchange between dynamic CDN nodes is implemented via Websocket, and Secure Websocket is certainly also supported.

动态CDN节点之间的消息交换是通过Websocket实现的，当然也支持Secure Websocket。

The streams inside CDN are broadcast via WebRTC. Usually UDP is used as transport, but if it is necessary to ensure good streaming quality with the channel between the servers being not so good, it is possible to switch to TCP. Unfortunately, in this case, the latency increases. Restart the servers, open the Two Way Streaming example on the o-eu1 server, publish the cyclical 10 minutes to 0 countdown timer video

CDN内部的流通过WebRTC广播。 通常将UDP用作传输，但是如果必须确保服务器之间的通道不太好而又要确保良好的流传输质量，则可以切换到TCP。 不幸的是，在这种情况下，等待时间增加了。 重新启动服务器，在o-eu1服务器上打开“双向流”示例，将周期性10分钟发布为0倒数计时器视频

Open the Player example on the e-eu1 server, play the stream

在e-eu1服务器上打开Player示例，播放流

and do the same thing on e-eu2

并在e-eu2上做同样的事情

The CDN is working! As you can see on the screenshots, the timing in the video coincides to the second both on the publishing part and on the viewing part thanks to WebRTC and good channels.

CDN正在运行！ 正如您在屏幕截图中所看到的，由于WebRTC和良好的频道，在发布部分和观看部分中，视频的时间与第二时间一致。

超越我们：连接美国 (And beyond we go: connecting America)

Now we are going to deliver streams to viewers on the American continent keeping in mind as well the publishing

现在，我们要牢记发布的同时，向美洲大陆的观众提供视频流

We will deploy three servers in an American data center without shutting the European part of the CDN down

我们将在美国数据中心部署三台服务器，而不会关闭CDN的欧洲部分

Setup:

建立：

• Origin US
  原产美国

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

• Edge 1 US
  Edge 1美国

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

• Edge 2 US
  Edge 2美国

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

Restart the American servers, check the publishing

重新启动美国服务器，检查发布

and the playback

和播放

Note that the European segment keeps working. We are going to check if the American users will be able to see the stream published from Europe. Publishing the test_eu stream on the o-eu1 server

请注意，欧洲部分继续运作。 我们将检查美国用户是否能够看到来自欧洲的信息流。 在o-eu1服务器上发布test_eu流

and playing it on e-us1

并在e-us1

And this is also working! As for the latency, the screenshots demonstrate again the synchrony of the timer in the video on the publishing part and on the viewing part to the second.

而且这也有效！ 至于等待时间，屏幕截图再次显示了计时器在发布部分和观看部分中的视频与第二部分之间的同步。

Note that playing on an Origin server the streams published on another Origin server is not possible by default, but if necessarily needed, this can be set up accordingly.

请注意，默认情况下，不可能在原始服务器上播放在另一台原始服务器上发布的流，但是如果需要，可以相应地进行设置。

cdn_origin_to_origin_route_propagation=true

未完待续 (To be continued)

In summary, we have deployed a simple CDN and then have successfully scaled it to two continents publishing and playing low latency WebRTC streams. For this purpose, we did not modify the stream parameters at playback, which is quite often needed in real life: all the viewers have different channels, and in order to maintain the streaming quality it is needed, for example, to reduce the resolution or the bitrate. We will deal with this in the following part...

总之，我们已经部署了一个简单的CDN，然后将其成功扩展到两个大洲，以发布和播放低延迟的WebRTC流。 为此，我们没有在回放时修改流参数，而这在现实生活中经常是需要的：所有观众都有不同的频道，并且为了保持流质量，例如，需要降低分辨率或比特率。 我们将在以下部分中对此进行处理...

相关链接 (Related links)

Flashphoner WebCallServer image in DigitalOcean Marketplace — image of Web Call Server in DigitalOcean.

DigitalOcean Marketplace中的Flashphoner WebCallServer图像 — DigitalOcean中的Web Call Server图像。

CDN for low latency WebRTC streaming — Web Call Server-based content delivery network.

用于低延迟WebRTC流的CDN-基于Web呼叫服务器的内容交付网络。

翻译自: https://habr.com/en/company/flashphoner/blog/477304/

webrtc cdn