Bei der Analyse der Möglichkeiten von Standard- Serverkonfigurationen in Digital Ocean im Hinblick auf WebRTC-Streaming haben wir bereits festgestellt, dass ein Server bis zu 2000 Zuschauer bedienen kann. In der Praxis gibt es oft Fälle, in denen ein Server nicht ausreicht.
Sagen wir, Fans der Aufregung in Deutschland schauen sich in Australien Pferderennen in Echtzeit an. Da Pferderennen nicht nur Pferdesport ist, sondern auch große Gewinne mit pünktlichen Wetten, sollte das Video mit der geringstmöglichen Verzögerung geliefert werden.
Ein weiteres Beispiel. Ein globales Unternehmen, eines der führenden Unternehmen auf dem FCMG-Markt mit Tochterunternehmen in Europa, Russland und Südostasien, organisiert Webinare, um Vertriebsleiter mit Übersetzungen vom Hauptsitz im Mittelmeerraum aus zu schulen. Die Zuschauer sollten den Moderator in Echtzeit sehen und hören.
Diese Beispiele kombinieren die Anforderungen: Bereitstellung von Medienströmen für eine große Anzahl von Zuschauern mit geringer Latenz. Dazu müssen Sie ein Content Delivery-Netzwerk (CDN) bereitstellen.
Beachten Sie, dass die klassische Technologie der Stream-Zustellung mit HLS nicht geeignet ist, da es zu Verzögerungen von bis zu 30 Sekunden kommen kann. Dies ist für Echtzeit-Shows von entscheidender Bedeutung. Stellen Sie sich vor, die Pferde haben bereits die Ziellinie erreicht, die Ergebnisse werden auf der Website veröffentlicht und die Fans inspizieren das Rennen noch immer. Diesem Nachteil wird die WebRTC-Technologie vorenthalten, die Verzögerungen innerhalb von 1 Sekunde bereitstellen kann. Mit modernen Kommunikationskanälen ist dies sogar zwischen Kontinenten möglich.
Lassen Sie uns zunächst sehen, wie Sie das einfachste CDN für die Bereitstellung von WebRTC-Streams bereitstellen und anschließend skalieren.
CDN-Struktur
Ein Server in einem CDN kann eine der folgenden Rollen übernehmen:
- Origin ist ein Server zum Veröffentlichen von Medienströmen. Verteilt Streams an andere Server und kann auch an Abonnenten verteilt werden.
- Transcoder - Ein Server, der sich der Transcodierung von Streams widmet. Nimmt Streams von Origin-Servern auf und verteilt transkodierte Streams an Edge. Wir werden uns im nächsten Teil mit dieser Rolle befassen.
- Edge - ein Server, der zum Verteilen von Streams an Abonnenten entwickelt wurde. Es werden Streams von Origin- oder Transcoder-Servern verwendet und keine Streams an andere CDN-Server verteilt.
Sie können WebRTC- und RTMP-Streams auf dem Origin-Server veröffentlichen oder Streams aus anderen Quellen über RTMP, RTSP und andere mögliche Methoden erfassen.
Abonnenten können Streams von Edgeservern über WebRTC, RTMP, RTSP, HLS wiedergeben
Zwischen CDN-Servern ist es wünschenswert, über WebRTC zu streamen, um die Latenz zu verringern.
Eine statische CDN wird in der Konfigurationsphase vollständig beschrieben. Das Einrichten eines statischen CDN ähnelt dem Einrichten 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 ist Origin folgendermaßen konfiguriert:
<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 ist das erste Problem mit einem statischen CDN: Um einem solchen CDN einen neuen Edgeserver hinzuzufügen oder den Server aus dem CDN zu entfernen, müssen Sie die Einstellungen ändern und alle Origin-Server neu starten.
In Origin veröffentlichte Streams werden an alle Server gesendet, die in den Edge-Einstellungen aufgeführt sind. Die Entscheidung, zu welchem der Edgeserver der Abonnent eine Verbindung herstellen soll, wird ebenfalls auf dem Origin-Server getroffen. Hier ist das zweite Problem: Wenn es keine oder nur sehr wenige Zuschauer gibt, zum Beispiel in Singapur an einem frühen Abend und in New York mitten in der Nacht, werden die Streams immer noch an Edge 1 gesendet. Der Verkehr wird im Leerlauf und überhaupt nicht kostenlos ausgegeben.
Dynamic CDN kann diese beiden Probleme lösen.
Wir möchten also CDN konfigurieren, ohne alle Origin-Server neu zu starten, und wir möchten keine Streams zu den Edge-Servern übertragen, auf denen keine Abonnenten vorhanden sind. In diesem Fall müssen Sie nicht die gesamte Liste der CDN-Server in den Einstellungen speichern. Jeder Server selbst muss eine solche Liste erstellen und dafür den aktuellen Status der anderen Server zu einem bestimmten Zeitpunkt kennen.
Idealerweise sollte es in den Einstellungen ausreichen, den Einstiegspunkt, den Server, von dem das CDN gestartet wird, anzugeben. An diesem Einstiegspunkt sollte jeder Server beim Start eine Anforderung senden und als Antwort eine Liste der CDN-Knoten und eine Liste der veröffentlichten Streams erhalten. Wenn der Einstiegspunkt nicht verfügbar ist, sollte der Server Nachrichten von anderen Servern erwarten.
Der Server sollte alle Änderungen an seinem Status an andere Server im CDN senden.
Das einfachste CDN: in der Mitte Europas
Versuchen wir also, ein dynamisches CDN zu konfigurieren und auszuführen. Nehmen wir zunächst an, wir müssen Videostreams an europäische Zuschauer verteilen, während bis zu 5.000 Benutzer unterstützt werden müssen. Angenommen, die Quelle der Ströme liegt ebenfalls in Europa.
Wir setzen drei Server im europäischen Rechenzentrum ein. Wir werden Flashphoner WebCallServer (WebRTC Streaming Video Server) als Elemente für die Erstellung eines CDN 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
Messaging zwischen dynamischen CDN-Knoten erfolgt über Websocket, und Secure Websocket wird natürlich auch unterstützt.
Innerhalb des CDN werden Streams über WebRTC übertragen. In der Regel wird UDP als Transport verwendet, Sie können jedoch auf TCP umschalten, wenn Sie die Broadcast-Qualität mit einem nicht sehr guten Kanal zwischen Servern sicherstellen möchten. Leider nehmen in diesem Fall die Verzögerungen zu.
Wir starten die Server neu, öffnen das Two Way Streaming-Beispiel auf dem o-eu1 und veröffentlichen ein zyklisches Video mit einem Countdown-Timer von 10 Minuten bis 0 Minuten
Öffnen Sie das Player-Beispiel auf dem e-eu1 und spielen Sie den Stream ab
Und machen Sie dasselbe mit e-eu2
CDN funktioniert! Wie Sie in den Screenshots sehen können, fällt die Zeit im Video dank WebRTC und guter Kanäle auf der Veröffentlichungsseite und in den Zuschauern bis zu einer Sekunde zusammen.
Überall weiter: Amerika verbinden
Jetzt werden wir den Zuschauern auf dem amerikanischen Kontinent Streams liefern und die Veröffentlichung nicht vergessen.
Ohne den europäischen Teil des CDN zu deaktivieren, stellen wir drei Server im amerikanischen Rechenzentrum bereit
Setup:
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
Wir starten die amerikanischen Server neu, wir überprüfen die Publikation
und Reproduktion
Gleichzeitig arbeitet das europäische Segment weiter. Überprüfen Sie, ob amerikanischen Abonnenten der Stream aus Europa angezeigt wird. Wir veröffentlichen den Stream test_eu auf dem o-eu1
und spiele es auf e-us1
Und es funktioniert auch! Was die Verzögerung angeht, so beobachten wir in den Screenshots erneut das Zusammentreffen des Timers im Video auf der Veröffentlichungsseite und in den Zuschauern bis zu einer Sekunde.
Bitte beachten Sie, dass auf einem anderen Origin-Server veröffentlichte Streams standardmäßig nicht direkt vom Origin-Server abgespielt werden können. Wenn Sie dies jedoch benötigen, können Sie es folgendermaßen konfigurieren
cdn_origin_to_origin_route_propagation=true
Fortsetzung folgt
Daher haben wir ein einfaches CDN bereitgestellt und anschließend erfolgreich auf zwei Kontinente skaliert, um WebRTC-Streams mit geringer Latenz zu veröffentlichen und wiederzugeben. Gleichzeitig haben wir die Parameter der Streams während der Wiedergabe nicht verändert, was im wirklichen Leben häufig erforderlich ist: Alle Zuschauer haben unterschiedliche Kanäle, und um die Qualität der Sendung aufrechtzuerhalten, ist es beispielsweise erforderlich, die Auflösung oder die Bitrate zu verringern. Dies werden wir im nächsten Teil tun ...
Referenzen
WebRTC-Streaming mit geringer Latenz CDN ist ein auf Web Call Server basierendes Netzwerk für die Bereitstellung von Inhalten.