Nachdem wir zuvor die Kapazität von Standardserverkonfigurationen in Digital Ocean im Hinblick auf WebRTC-Streaming analysiert haben, haben wir festgestellt, dass ein Server bis zu 2000 Zuschauer abdecken kann. Im wirklichen Leben sind Fälle, in denen ein Server nicht ausreicht, keine Seltenheit.
Angenommen, Glücksspielamateure in Deutschland verfolgen in Australien Pferderennen in Echtzeit. Da Pferderennen nicht nur ein Sportspiel sind, sondern auch große Gewinne mit sich bringen, sofern Feldwetten zum richtigen Zeitpunkt abgeschlossen werden, muss das Video mit der geringstmöglichen Latenz geliefert werden.
Ein weiteres Beispiel: Ein globales Unternehmen, eines der Marktführer von FCMG mit Tochterunternehmen in Europa, Russland und Südostasien, organisiert Webinare für Vertriebsmanager-Schulungen mit Live-Streaming von der Zentrale im Mittelmeer. Die Zuschauer müssen den Moderator in Echtzeit sehen und hören können.
In diesen Beispielen wird dieselbe Anforderung gestellt: Medienströme mit geringer Latenz für eine große Anzahl von Zuschauern bereitzustellen. Dies erfordert die Bereitstellung eines Content Delivery-Netzwerks (CDN).
Es ist zu beachten, dass die herkömmliche Stream Delivery-Technologie unter Verwendung von HLS nicht gut geeignet ist, da sie Verzögerungen von bis zu 30 Sekunden verursachen kann, die für eine Echtzeitshow kritisch sind. Stellen Sie sich vor, dass die Pferde bereits fertig sind und die Ergebnisse auf der Website veröffentlicht wurden, während die Fans noch das Ende des Rennens verfolgen. Die WebRTC-Technologie ist frei von diesem Nachteil und kann Verzögerungen von weniger als 1 Sekunde garantieren, die dank moderner Kommunikationskanäle auch über Kontinente hinweg möglich sind.
Zunächst wird gezeigt, wie Sie das einfachste CDN für die Bereitstellung von WebRTC-Streams bereitstellen und anschließend skalieren können.
Cdn-Prinzipien
Ein Server im CDN kann eine der folgenden Rollen spielen:
- Origin ist der Server zum Veröffentlichen von Medienströmen. Es gibt Streams an andere Server sowie Benutzer weiter.
- Transcoder ist der Server, der für das Transcodieren von Streams reserviert ist. Es zieht Streams vom Origin-Server und leitet transkodierte Streams an Edge weiter. Wir werden uns diese Rolle im folgenden Teil ansehen.
- Edge ist der Server, der zum Freigeben von Streams für Benutzer entwickelt wurde. Streams werden von Origin- oder Transcoder-Servern abgerufen und nicht an andere CDN-Server weitergeleitet.
Origin Server ermöglicht das Veröffentlichen von WebRTC- und RTMP-Streams oder das Erfassen von Streams aus anderen Quellen über RTMP, RTSP oder andere verfügbare Methoden.
Benutzer können Streams von Edgeservern über WebRTC, RTMP, RTSP, HLS abspielen.
Um die Latenz zu minimieren, ist es wünschenswert, Streams zwischen CDN-Servern unter Verwendung von WebRTC zu übertragen.
Statisches CDN wird in der Konfigurationsphase vollständig beschrieben. Tatsächlich ähnelt das Setup eines statischen CDN dem Setup eines Lastenausgleichs: Alle Empfänger werden in den Einstellungen des Stream-Quellservers aufgelistet.
Zum Beispiel haben wir einen Origin-Server in Frankfurt, einen Edge in New York und einen in Singapur
In diesem Fall wird Origin ungefähr so eingerichtet:
<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>
Hier kommt das erste Problem mit dem statischen CDN: Um einen neuen Edgeserver in diese Art von CDN aufzunehmen oder einen Server von einem CDN auszuschließen, müssen die Einstellungen geändert und alle Origin-Server neu gestartet werden.
Die in Origin veröffentlichten Streams werden an alle Edgeserver gesendet, die in den Einstellungen aufgeführt sind. Die Entscheidung, zu welchem Edgeserver der Benutzer eine Verbindung herstellen soll, wird auch auf dem Origin-Server getroffen. Hier kommt die zweite Ausgabe: Wenn es nur wenige oder keine Zuschauer gibt - zum Beispiel in Singapur ist es früher Abend, während es in New York mitten in der Nacht ist - werden die Streams trotzdem an Edge 1 gesendet. Der Verkehr wird zu keinem Zweck verschwendet und ist nicht kostenlos.
Diese beiden Probleme können mit Dynamic CDN gelöst werden.
Jetzt möchten wir das CDN einrichten, ohne alle Origin-Server neu zu starten, und keine Streams an Edgeserver senden, bei denen keine Benutzer verbunden sind. In diesem Fall muss die gesamte Liste der CDN-Server nicht irgendwo in den Einstellungen gespeichert werden. Jeder Server muss eine solche Liste unabhängig erstellen. Zu diesem Zweck muss der aktuelle Status der anderen Server zu einem bestimmten Zeitpunkt bekannt sein.
Im Idealfall sollte es ausreichen, den Einstiegspunkt - den Server, auf dem das CDN beginnt - in den Einstellungen anzugeben. Während des Startvorgangs muss jeder Server eine Anfrage an diesen Einstiegspunkt senden und als Antwort die Liste der CDN-Knoten und veröffentlichten Streams erhalten. Wenn auf den Einstiegspunkt nicht zugegriffen werden kann, muss der Server auf Nachrichten von anderen Servern warten.
Der Server muss Änderungen seines Status anderen Servern im CDN mitteilen.
Das einfachste CDN: in der Mitte Europas
Jetzt werden wir versuchen, ein dynamisches CDN einzurichten und zu starten. Angenommen, wir müssen zunächst Medienströme für Zuschauer in Europa bereitstellen, die bis zu 5000 Benutzer abdecken. Angenommen, die Stream-Quelle befindet sich ebenfalls in Europa
Wir werden drei Server in einem Rechenzentrum in Europa bereitstellen. Wir werden Flashphoner WebCallServer-Instanzen (WebRTC-Stream-Video-Server) als CDN-Assembly-Komponenten verwenden
Setup:
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
Der Nachrichtenaustausch zwischen dynamischen CDN-Knoten wird über Websocket implementiert, und Secure Websocket wird sicherlich auch unterstützt.
Die Streams im CDN werden über WebRTC übertragen. Normalerweise wird UDP als Transport verwendet. Wenn jedoch eine gute Streaming-Qualität mit einem nicht so guten Kanal zwischen den Servern sichergestellt werden muss, kann auf TCP umgeschaltet werden. Leider erhöht sich in diesem Fall die Latenz.
Starten Sie die Server neu, öffnen Sie das Two Way Streaming-Beispiel auf dem o-eu1 Server und veröffentlichen Sie das zyklische 10-Minuten-Countdown-Timer-Video
Öffnen Sie das Player-Beispiel auf dem e-eu1 Server und spielen Sie den Stream ab
und mache dasselbe auf e-eu2
Das CDN funktioniert! Wie Sie auf den Screenshots sehen können, stimmt das Timing im Video dank WebRTC und guter Kanäle sowohl im Publishing-Teil als auch im Viewing-Teil mit der Sekunde überein.
Und darüber hinaus: Amerika verbinden
Jetzt werden wir den Zuschauern auf dem amerikanischen Kontinent Streams liefern und dabei auch die Veröffentlichung berücksichtigen
Wir werden drei Server in einem amerikanischen Rechenzentrum bereitstellen, ohne den europäischen Teil des CDN herunterzufahren
Einrichtung:
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
Starten Sie die amerikanischen Server neu, und überprüfen Sie die Veröffentlichung
und die Wiedergabe
Beachten Sie, dass das europäische Segment weiter funktioniert. Wir werden prüfen, ob die amerikanischen Benutzer den aus Europa veröffentlichten Stream sehen können. Veröffentlichen des test_eu auf dem Server o-eu1
und spiele es auf e-us1
Und das funktioniert auch! In Bezug auf die Latenz zeigen die Screenshots erneut die Synchronität des Timers im Video auf dem Veröffentlichungsteil und auf dem Betrachtungsteil auf der Sekunde.
Beachten Sie, dass das Abspielen der auf einem anderen Origin-Server veröffentlichten Streams auf einem Origin-Server standardmäßig nicht möglich ist. Bei Bedarf kann dies jedoch entsprechend eingerichtet werden.
cdn_origin_to_origin_route_propagation=true
Fortsetzung folgt
Zusammenfassend haben wir ein einfaches CDN bereitgestellt und es dann erfolgreich auf zwei Kontinente skaliert, die WebRTC-Streams mit geringer Latenz veröffentlichen und wiedergeben. Zu diesem Zweck haben wir die Stream-Parameter bei der Wiedergabe nicht geändert, was im wirklichen Leben häufig erforderlich ist: Alle Zuschauer haben unterschiedliche Kanäle, und um die Streaming-Qualität aufrechtzuerhalten, ist es beispielsweise erforderlich, die Auflösung zu verringern oder die Bitrate. Wir werden uns im folgenden Teil damit befassen ...
Flashphoner WebCallServer-Image im DigitalOcean Marketplace - Image des Web Call Servers in DigitalOcean.
CDN für WebRTC-Streaming mit geringer Latenz - Web Call Server-basiertes Netzwerk für die Bereitstellung von Inhalten.