Jetzt scheint es unmöglich zu sein, einen Messenger ohne die Anruffunktion zu finden. Dies ist praktisch für Benutzer, da alle Kommunikationen in einer Anwendung durchgeführt werden können. Wenn wir alle in den Medien verfügbaren Statistiken zusammenfassen, stellt sich heraus, dass die Menschen mehr als eine Milliarde Minuten pro Tag über das Internet sprechen. Und mit der Entwicklung der Technologie wächst der Anteil der Videokommunikation, da Video die Emotionen des Gesprächspartners besser vermittelt und es Ihnen ermöglicht, den Effekt der Präsenz zu erzeugen.

Eine neue Herausforderung für den Videoanrufdienst besteht darin, in einer Konferenz die ganze Familie oder eine Gruppe von Freunden in verschiedenen Teilen der Welt oder Kollegen, die an demselben Projekt arbeiten, für die Planung zusammenzubringen.

Der Entwicklungsleiter der Video- und Tape-Plattformen, Alexander Tobol ( alatobol ), wird zeigen, dass es unter der Haube einen Videoanrufdienst gibt, mit welchen Technologien und Hacks Ihr Konferenzserver erstellt wird und wie Videos korrekt übertragen werden. Lernen Sie, wie Sie einen Einzelgesprächsdienst auf Gruppengespräche für 100 Personen übertragen und warum Sie für so viele Teilnehmer Unterstützung benötigen.


Der Artikel basiert auf einem Bericht über HighLoad ++ Sibirien , in dem Alexander Tobol versucht, ein vollständiges Bild zu vermitteln. Wenn Sie bereits mit anderen Materialien zum Thema vertraut sind (z. B. mit den Funktionen der Videoübertragung und Netzwerkprotokollen ), können Sie den theoretischen Teil überspringen und direkt zur Lösung übergehen .

Die Gliederung des Artikels:

• Verlauf und Geräteaufrufe.
• Übergang von Einzelgesprächen zu Gruppengesprächen.
• DIY Gruppenrufservice.
• Conferencing Server: Entdecken Sie Konkurrenten und verbessern Sie sie.

Verlauf aufrufen

Die erste bekannte Anwendung für Anrufe, und mit dem Video, war Skype, es erschien im Jahr 2006. In Odnoklassniki haben wir in den Jahren 2010-2012 Anrufe auf der Basis einer Lösung von Adobe gestartet ... Vor ein paar Jahren haben wir sie in WebRTC komplett überarbeitet (mehr zu diesem Start hier ). Letztes Jahr haben wir Gruppenanrufe hinzugefügt. Dieser Übergang wird im Artikel besprochen.

Warum kann ich Ihnen wohl sagen, wie das geht? Weil unser monatliches Publikum, das Anrufe tätigt, 10 Millionen Menschen übersteigt und wir mehr als 2 Millionen Anrufe pro Tag haben . Darüber hinaus geschieht mehr als die Hälfte davon über mobile Plattformen.

Gruppengespräche sind der am schnellsten wachsende Dienst und unser Ziel sind 100 Konferenzteilnehmer gleichzeitig. Warum so viel? Erstens möchten Sie manchmal eine schöne Aufnahme mit Ihren Freunden und Klassenkameraden teilen oder ein Seminar abhalten. Zweitens kann sich alles ändern, auch wenn Sie der Meinung sind, dass Ihr Service nichts benötigt.

Jetzt scheint es, dass Videokonferenzen für 100 Teilnehmer nicht erforderlich sind, und vor fünf Jahren haben sie mich gefragt, warum wir Video in 4K starten. Jetzt ist ein 4K-Fernseher an der Tagesordnung und wir waren 2014 bereit.

Der Punkt ist nicht der Zeit voraus. Wenn Sie einen guten Service leisten möchten, legen Sie die Messlatte höher.

Wenn Sie gut funktionierende Anrufe für 50 bis 100 Personen tätigen können, funktioniert für 6 bis 10 Benutzer alles einwandfrei.

Jeder Anrufdienst hat 4 relativ unabhängige Komponenten:

• Signalisierung Die Aufgabe besteht darin, den Teilnehmer anzurufen, Anfangsdaten auszutauschen, zu informieren, was jeder Teilnehmer tun kann, und dann einen Kanal einzurichten, über den Videodaten übertragen werden können.
• Video / Audio. Video- und Audiodaten werden mit Codecs komprimiert.
• Netzwerk. Es ist notwendig, die Arbeit in schlechten Netzwerken sicherzustellen, Paketwiederherstellung, P2P-Verbindungen usw. zu implementieren.
• Topologie - bei Gruppenrufen hinzugefügt.

Sie können über jeden dieser Teile separat sprechen. Aber ich möchte einen Überblick über die Funktionsweise von Anrufen geben. Deshalb werde ich versuchen, alles in eine Geschichte zu integrieren.

Bevor Sie mit der Arbeit am Service beginnen, müssen Sie die Anforderungen identifizieren:

• Stellen Sie schnell eine Verbindung her, sodass die Verbindung sofort hergestellt wird, nachdem der Gesprächspartner den Hörer abgenommen hat.
• Hohe Anrufqualität, damit das Video nicht bröckelt und nicht einfriert.
• Die Anzahl der Teilnehmer am Anruf , damit Sie in Chats anrufen können, in denen bis zu 100 Teilnehmer teilnehmen.
• Geringe Latenz zwischen Anrufern. Eine Latenz von 1,3 s als Polycom passt überhaupt nicht zu uns.

Hier sind die spezifischen Bedeutungen, in denen diese Anforderungen für Gruppenanrufe ausgedrückt werden: Beginn eines Anrufs nicht länger als 1 Sekunde; ein Netzwerk, in dem 300-Kbit / s-Video stabil funktioniert; Latenz vom Anrufer zum Hörer nicht länger als 0,5 Sekunden; 100 Benutzer in einem Anruf.

Was ist im Weg?

Wie Sie wissen, werden Daten in Netzwerken in Paketen übertragen: Es gibt einen Socket, Sie senden einen Datenstrom dorthin, alles fliegt davon, als ob es in einer Blackbox zusammengesetzt wäre und funktioniert.

Die Netzwerke sind jedoch unterschiedlich. Die Hälfte der Anrufe wird über Mobilfunknetze getätigt und sieht nicht immer wie eine Autobahn aus.

Netzwerke können überlastet sein, dann gehen die Daten verloren und sie müssen wiederhergestellt werden, wodurch das Netzwerk weiter geladen wird. Es gibt Netzwerke, in denen alles in Ordnung zu sein scheint, aber Pakete immer noch verschwinden - zum Beispiel, weil sich der WLAN-Router hinter einer Stahlbetonwand befindet.

Netzwerkfunktionen

Wir werden die Hauptmerkmale analysieren, die die Qualität des Netzwerks beschreiben.

RTT

Roundtrip-Zeit - die Zeit zwischen dem Server, der die Daten an den Client sendet und die Bestätigung zurückerhält.

Denken Sie daran, wir möchten in 1 Sekunde eine Verbindung herstellen. Wenn die Umlaufzeit 200 ms beträgt, können beim Verbindungsaufbau, z. B. über TCP, plus TLS, nur 500 ms für die Verbindung verloren gehen . Es verbleiben nur 500 ms, d.h. Noch ein paar Anfragen, nach denen die Verbindung aufgebaut werden soll. Daher müssen Sie bei zusätzlichen Anfragen mit RTT sehr sorgfältig arbeiten.

Ein Beispiel:

$ ping google.com 64 bytes from 173.194.73.139: icmp_seq=5 ttl=44 time=211.847 ms round-trip min/avg/max/stddev = 209.471/220.238/266.304/19.062 ms RTT = 220ms $ curl -o /dev/null -w "HTTP time taken: %{time_connect}\nHTTPS time taken: %{time_appconnect}\n" -s https://www.google.com HTTP time taken: 0.231 HTTPS time taken: 0.797 HTTP = 230ms HTTPS = 800ms 

Bei RTT = 220 ms dauert der Empfang einer Antwort über https bis zu 800 ms. Wenn Sie also eine sichere Web-Socket-Verbindung haben, wird mit einem solchen Ping die ganze Sekunde vergehen.

Die Tabelle zeigt die in Mobilfunknetzen gemessenen Handshake-Verzögerungen (in diesem Bericht werden weitere Details zum Betrieb von Anwendungen in Mobilfunknetzen aufgeführt).

Durchsatz

Sie können Pakete an das Netzwerk senden, wie Sie möchten: in Stapeln oder sofort alle in den Puffer hämmern, werden sie immer noch gleichmäßig an den Client gelangen. Die Anzahl der Pakete oder Daten pro Sekunde ist die Bandbreite oder Bandbreite.

Das Problem ist, dass sich die Bandbreite in Mobilfunknetzen ständig ändert . Wenn es stark abfällt und die Daten mit derselben Bitrate übertragen werden, gehen sie offensichtlich mit Verlusten durch, und der Anruf des Benutzers wird "hängen". Dies muss auch bekämpft werden.

Paketverlust

Bei der Übertragung von Daten kann das Paket verloren gehen. In diesem Fall haben Sie die Wahl: Überspringen Sie entweder einen Teil der Pakete und erhalten Sie Verzerrungen, oder versuchen Sie, die Pakete erneut zu übertragen und ein Standbild zu erhalten.

Jitter

Tatsache ist, dass Pakete nicht gleichmäßig nacheinander eintreffen, sondern in gebündelten Paketen in bestimmten Intervallen.


Jitter ist einfach zu messen:

 PING highload.ru (178.248.233.16): 56 data bytes icmp_seq=11 ttl=43 time=117.177 ms icmp_seq=12 ttl=43 time=132.868 ms icmp_seq=13 ttl=43 time=176.413 ms icmp_seq=14 ttl=43 time=225.981 ms 

Pinganuli highload.ru mehrmals (ping ist ein instabiler Wert, es ist notwendig zu ((132-117)+(176-132)+(225-176)) / 3 = (14 + 44 + 79) / 3 = 46 ), wir haben den durchschnittlichen Jitter: ((132-117)+(176-132)+(225-176)) / 3 = (14 + 44 + 79) / 3 = 46 .

Angenommen, wir übertragen ein Video und ein Frame ist ein Netzwerkpaket. Es werden mehrere Bilder ohne Unterbrechung abgespielt, aber der dritte Vogel ist aufgrund von Jitter verzögert - wir erhalten ein Standbild. Sie müssen also Pakete irgendwo sammeln und diesen Effekt ausgleichen.

Das heißt, um drahtlose Netzwerke zu charakterisieren, ist es ausreichend, die folgenden Werte zu kennen: RTT (Roundtrip-Zeit); Bandbreite BW (Bandbreite); Paketverlust in Prozent; Jitter.

Wie sieht der Benutzer aus?

Bevor Sie beginnen, die Arbeit mit dem Netzwerk zu optimieren, müssen Sie herausfinden, welche Art von Internet die Benutzer haben - vielleicht hat jeder ein perfektes Netzwerk, jede Lösung funktioniert.

In 80% der Fälle verwendet der Endbenutzer eine drahtlose Verbindung: Es handelt sich entweder um ein Mobilfunknetz oder um Wi-Fi.



In Russland, außerhalb der westlichen Region und großer Städte, sind die durchschnittlichen Netzwerkeigenschaften: RTT - 200 ms, Bandbreite - 1,1 Mbit / s, Paketverlust - 0,6%, Jitter - 5 ms.

Wir haben diese Werte nach Netzwerktypen unterteilt und festgestellt, dass es notwendig ist, zu lernen, damit zu arbeiten.

Entwicklungsfunktionen aufrufen

Viele Menschen vergessen, aber LTE und 3G sind asymmetrische Kommunikationskanäle: Downlink ist immer mehr als Uplink. Je nach Protokolltyp kann dieses Verhältnis zwischen 15/85 und 30/70 variieren. Dies ist beim Entwerfen von Anrufen wichtig.

Wie können Sie überprüfen, welchen Kanal Ihre Kunden haben?



Sie können sich speedtest ansehen, wie hoch das weltweite Geschwindigkeitsverhältnis zwischen mobilem und festem Internet ist. Es stellte sich heraus, dass das feste Internet weltweit ebenfalls asymmetrisch ist. In Russland stellte sich glücklicherweise eine Symmetrie heraus: Das Uplink / Downlink-Verhältnis in einem festen Internet über WLAN in Russland beträgt 50/50. Wir werden uns auf solche Werte konzentrieren.



Fazit: Drahtlose Netzwerke sind beliebt und instabil.

• Mehr als 80% der Kunden nutzen das drahtlose Internet.
• WLAN-Einstellungen ändern sich dynamisch.
• Drahtlose Netzwerke weisen hohe Raten von Paketverlust, Jitter und Neuordnung auf.
• Asymmetrischer Uplink / Downlink-Kanal im Verhältnis 30/70.

Anrufe

Kehren wir mit diesem Wissensspeicher zur Implementierung von Gruppenaufrufen zurück. Betrachten Sie einen Algorithmus für einen einfachen Gruppenaufruf, den wir dann verfeinern.

Schritt 1. Alice möchte Boris anrufen und sendet ihm ein Angebot, in dem sie alles berichtet, was sie kann, welche Protokolle, Einstellungen usw. unterstützt.

Schritt 2. Boris antwortet Alice, woraufhin eine Verkehrsverbindung hergestellt wird.

Schritt 3. Danach beginnt der Austausch von Audio- / Videodaten.

Die Architektur von Anrufen sieht ungefähr so ​​aus wie in der folgenden Abbildung.

Es gibt immer einen gemeinsam genutzten Server, aber wenn die Verbindung hergestellt ist, können Benutzer bereits P2P-Daten oder über Server von Drittanbietern übertragen.

Daten werden von einer Kamera erfasst, die sie auf dem Gerät codiert und an die Socket-Verbindung sendet. Sie durchlaufen das Netzwerk, werden vom Codec auf der anderen Seite wiedergegeben und auf dem Bildschirm angezeigt.

Betrachten Sie alle Schritte des Algorithmus im Detail und versuchen Sie, von 1-zu-1-Anrufen zu Gruppenanrufen zu wechseln.

Signalisierung

Aufgabe: Anruf melden und Datenverbindungen herstellen.

Alles ist ganz einfach:

• Alice ruft an, eine Benachrichtigung wird über ein mobiles Gerät oder einen Browser an Boris gesendet.
• Ein Web-Socket oder eine andere Verbindung wird hergestellt.
• Danach finden Verhandlungen statt - Alice und Boris sind sich einig.
• Wenn der Hörer auf einem Gerät abgenommen wird, wird der Anruf auf dem anderen Gerät automatisch beendet.

Die Anrufplattform in Odnoklassniki unterstützt verschiedene Kunden und Transporte. Sie alle befinden sich in der Nähe eines Servers, der einen Anruf bearbeitet und Nachrichten weiterleitet.

Im Falle eines Serverabsturzes oder der Installation von Updates gibt es einen dauerhaften Speicher, in dem alle Nachrichten aufgezeichnet werden. Im Falle eines Serververlusts können Sie problemlos zu einem anderen wechseln. Das macht ZooKeeper.

Die einzige Schwierigkeit ist genau einmal . Wir möchten einige Nachrichten nicht zweimal anwenden. Dieses Problem wird einfach gelöst: Alle Nachrichten haben eine Seriennummer - zweimal kommt eine einzelne Nachricht nicht an.

Darüber hinaus müssen Sie beim Erstellen eines Anrufs vorsichtig sein. Eine Person kann einen Anruf erstellen, auflegen und einen weiteren Anruf erstellen. Oder es kann nicht hängen, aber immer noch eine andere erstellen. Alle diese Anrufe sind nicht eindeutig - es ist nicht klar, ob dies ein Relais ist oder der Benutzer auf die Anruftaste doppelklickt. Es ist einfach zu reparieren: Auf dem Client wird eine eindeutige ID generiert und eine Deduplizierung durchgeführt. Grundsätzlich gibt es keine Schwierigkeiten bei der Signalisierung .

Die P2P-Signalisierung an die Gruppe ist problemlos abgeschlossen.

Die gleichen Angebote und Antworten sendet Alice nun nicht nur an Boris, sondern auch an Dima. Sie empfangen sie, stimmen zu, Datenaustauschkanäle erscheinen zwischen ihnen.

Audio / Video

Um mit einem Gruppenanruf fertig zu werden und zu verstehen, welche Technologien benötigt werden, müssen wir ein wenig darüber sprechen, was ein Video ist.

Video ist 24 oder 60 Bilder pro Sekunde. Um sie zu komprimieren, werden Codecs verwendet. Das Hauptmerkmal von Codecs ist, dass alle paar Frames ein Referenzframe (z. B. JPEG) vorhanden ist und dass Zwischenframes durch Änderungen bestimmt werden.

Im obigen Bild ist das erste Bild mit der Maschine das Referenzbild, und im nächsten Bild werden nur die Änderungen (Bewegung der Maschine) und beim nächsten Mal auch nur die Änderungen codiert.

Dies wird als Gruppe von Bildern bezeichnet - eine unabhängige Gruppe miteinander verbundener Bilder, die decodiert werden können. Codec ist ein Algorithmus zur Transformation zwischen Frames. Je steiler der Codec, desto besser werden die Daten komprimiert und desto mehr Ressourcen werden benötigt.
Über das Verhältnis der Codec-Bitraten gibt es allgemeine Regeln (siehe Link ).

Die beliebtesten Codecs für Anrufe sind H.264 und VP8 . H.264 ist gut, weil es überall hart arbeitet und keine Batterie frisst. Aber in der Regel auf Handys ein Encoder (Encoder) und 4 Decoder. Für alles andere benötigen Sie die Software VP8, die einen guten Akku verbraucht. Es lohnt sich, die Priorität für Gruppenanrufe auf H.264 zu ändern (siehe den Link zur Vorgehensweise).

Der Codec kann mit einer Variablen (Variable Bitrate) oder einer konstanten Bitrate (Constant Bitrate) codieren. Viele Codecs auf Geräten unterstützen keine konstante Bitrate, so dass Sie mit dem Bild auf der linken Seite leben müssen.

Audio-Codecs

Es gibt verschiedene Legacy-Codecs für Audio, z. B. den G711. Der Opus-Codec ist sehr beliebt - er löst das Codierungsproblem sowohl bei niedrigen als auch bei hohen Bitraten, da er SILK von Skype und den CELT-Codec für Musik enthält.

Es ist erwähnenswert, dass das Opus einen proaktiven Fehlerkorrekturalgorithmus für die Vorwärtsfehlerkorrektur (FEC - Forward Error Correction) hat. Für Audio funktioniert dieser Algorithmus folgendermaßen: In jedem Paket befinden sich Daten in hoher Qualität und Daten aus vorherigen Frames für einige Zeit in geringer Qualität. Wenn dementsprechend das vorherige Paket verloren geht, können Sie die Daten des vorherigen Pakets in geringer Qualität erhalten und irgendwie verlieren. Im Durchschnitt fällt es ziemlich gut aus.

Bei der Arbeit mit Audio-Codecs ist es interessant, die Grafik zu betrachten, die das Verhältnis zwischen der Qualität des Eingangssignals und der Bitrate zeigt.

Es ist zu sehen, dass Opus fast alle Probleme löst. Es ist interessant, auf AAC zu achten, das beim Codieren von Videos in verschiedenen Hostingdiensten verwendet wird, und auf den alten Speex-Codec, der ausschließlich für Audio verwendet wurde und bis zu 32 Kbit / s funktioniert.

Daten zur Medienpathologie

Um zu verstehen, wie Topologien funktionieren und welche Funktionen sie haben, müssen Sie wissen, wie ein Videocodec mit Verlusten umgeht.

Im ersten Fall ging nichts verloren und wir sehen ein gutes Bild. In der zweiten Zeile geht ein zufälliger Frame verloren - das Bild enthält kleine Artefakte. Im dritten Fall verschwand der Referenzrahmen, daher werden bis zum nächsten Referenzrahmen Änderungen angezeigt, die sich zufällig überlappen.

Offensichtlich ist das Erstellen von Referenzrahmen oft teuer, da die Bitrate zunimmt. Daher unterstützen fast alle Anrufdienste die Möglichkeit, bei Verlust einen Referenzrahmen anzufordern. In WebRTC wird dies als vollständiger INTRA-Frame bezeichnet.

Die einfachste Topologie besteht darin, Ihr gesamtes Video an alle anderen Konferenzteilnehmer zu senden.

Wir starten einen Codec und beginnen mit der Videoübertragung. Alice schaltet die Kamera ein, den Codec, sendet ihr Video an Boris und Dima. Aber wenn Dima schlechtes Internet hat, leidet Boris, weil Sie die Qualität des gesamten Videos verringern müssen. Und wenn Dima den Schuss verlor und einen Unterstützer verlangte, wird Boris ihn auch bekommen, obwohl er ihn nicht brauchte.

Auf der anderen Seite können Sie alle Videos in einem Stream zusammenfügen. Dies erfordert spezielle Ausrüstung und möglicherweise zusätzliche Verzögerungen, aber es gibt auch eine solche Lösung.

Transportieren oder liefern Sie Video und Audio mit minimaler Verzögerung

Wir haben die Wahl zwischen TCP- oder UDP-Protokollen.
Wahrscheinlich erinnert sich jeder daran, dass TCP ein zuverlässiges Protokoll ist, das sie im Falle eines Paketverlusts erneut sendet. Aus diesem Grund ist diese Reihenfolge der Frames wie im Bild unten möglich.

Wenn ein Paket im Paket fehlt, können Sie dieses der 24 Frames im Video frei überspringen, aber TCP erlaubt Ihnen nicht, das Folgende zu empfangen, bis Sie das verlorene senden. Die Übertragung von Videos über TCP ist äußerst ineffizient. UDP wird für solche Aufgaben empfohlen und wird von allen Anrufdiensten verwendet.

Dieser Artikel enthält alle Funktionen beider Protokolle und erläutert, warum alle Streams unter UDP funktionieren. Im Rahmen des heutigen Themas reicht es für uns zu wissen, dass UDP nicht überall verfügbar ist und in 3% der Netzwerke nicht funktioniert.

Im Allgemeinen können Benutzer P2P-Verbindungen zwischen sich herstellen.

Dies ist am rentabelsten, da es viel besser ist, direkt zu kommunizieren und keinen zusätzlichen Server zu verwenden, der eine Hebelwirkung bietet, wenn wir uns in Nowosibirsk anrufen.

NAT existiert jedoch und mehr als 97% der Benutzer befinden sich jetzt dahinter - nur wenige haben externe IPs. Einerseits wird dieses Problem früher oder später durch IPv6 behoben. In Russland war MTS übrigens die erste, die es auf den Markt gebracht hat. Jetzt unterstützen sie IPv6 vollständig und alle ihre Clients verfügen über weiße IPs.

NAT kann durchbrechen, kann nicht durchbrechen, und dann müssen Sie Fallback über den Server verwenden. Es gibt auch einen Artikel darüber, wie man NAT durchbricht.

Jitterpuffer zwischen Transport und Frames

Wir ziehen weiter. Jetzt brauchen wir einen Jitterpuffer, um den Effekt des Jitters auszugleichen

Wir beginnen proaktiv, Frames mit einer gewissen Verzögerung anzuzeigen, und richten in der Zwischenzeit Frames im gleichen Intervall im Puffer aus.

Der Puffer erhöht sich dynamisch.

Wenn der Frame verloren geht und das Bild eingefroren ist, vergrößert sich der Puffer, und wir arbeiten bereits mit einem Puffer dieser Größe.

Es kann jedoch eine umgekehrte Situation geben, wenn Sie den Puffer reduzieren müssen. Zum Beispiel hat sich das Netzwerk stabilisiert, und die Zeit muss eingeholt werden. Wenn Sie einfach den Puffer reduzieren, wird es lächerlich, die Leute werden sehr schnell mit der Stimme eines Gnoms sprechen. Aus diesem Grund gibt es spezielle Algorithmen, die die Audio-Geschwindigkeit unmerklich anpassen: Entfernen Sie Pausen zwischen Wörtern oder reduzieren Sie Geräusche, die in der Sprache zu lang sind.

Wenn Sie ein Video transkodieren und etwas reparieren möchten, benötigen Sie zunächst einen Jitter-Puffer, dessen Latenz nicht geringer ist als der Latenz-Jitter dieses Netzwerks. Das heißt, es erhöht definitiv die Latenz und wir erinnern uns, dass wir wirklich innerhalb von 0,5 s bleiben wollen.

Ausatmen - die Theorie ist vorbei!

Ruft nach OK auf

Vor Gruppenanrufen hatten wir p2p-Anrufe, die WebRTC-Bibliothek wurde verwendet, Web- und Mobile-Clients wurden gesammelt, Signalisierung wurde geschrieben.

Wettbewerbsanalyse

Wenn Sie nicht wissen, was Sie tun sollen, schauen Sie sich Ihre Konkurrenten an. Als Referenz haben wir ein Set ausgewählt: Skype, WhatsApp, Hangouts, ICQ, Zoom. Wir haben die maximale Teilnehmerzahl in einem Gruppengespräch, die Latenz, den Batterieverbrauch und die Qualität gemessen.

Am interessantesten ist es, die Verzögerung zu bestimmen. Wir machen es so: Timer einschalten, Video aufnehmen, telefonieren.

100 ms - Kameraverzögerung von dem Moment an, an dem das Video auf die Linse traf, bevor es in die Matrix des Telefons gezeichnet wurde. Danach wird das Video an das Netzwerk gesendet und es wird bereits eine Verzögerung von 310 ms beim Anruf festgestellt.

Vergessen Sie nicht, die CPU-Auslastung auf dem Gerät zu messen. Ab iOS 12 war dies systematisch möglich, aber wir verwenden ein Pyrometer auf die alte Art und Weise.

Erhielt die folgenden Ergebnisse:

WhatsApp und ICQ haben maximal 4 Anrufteilnehmer, Skype hat 25 (Skype for Business 250) und Hangouts und Zoom haben jeweils 100 Teilnehmer. Hangouts hatten früher ungefähr 35 Mitglieder, und jetzt ist er in die 100+ -Rubrik gesprungen.

Der Zoom hat eine etwas längere Verzögerung, aber Hangouts verbrauchen mehr Akkustrom. Zoom scheint mir eine bessere Qualität zu haben, aber es gibt Artikel, die das Gegenteil aussagen - dies ist eine subjektive Metrik.

Einige Dienste verwenden offenes WebRTC, andere proprietäre Protokolle. Es ist jedoch offensichtlich, dass die Anzahl der Teilnehmer des Anrufs nicht beeinflusst wird, welche Art von Transport Sie im Folgenden verwenden. Es gibt Lösungen mit 100 Anrufen und eigenen Protokollen (Zoom) sowie mit WebRTC (Hangouts).

Skaliere von 2 bis N

Stellen Sie sich einen interessanten Fall vor: Es gibt einen Client mit einem asymmetrischen Kanal, Eingang 3 Mbit / s, Ausgang 1,5 Mbit / s, Paketverlust 0,6%, Jitter 50 ms. Es gibt Video in HD (1280x720) mit einer Bitrate von 1,5 Mbit / s und Video mit einer Auflösung von 640x360 (nennen wir LOW) bei 600 Kbit / s. Wir wollen coole Videos übertragen.

Wenn zwei Leute p2p anrufen, ist alles einfach. Sie haben genug Eingangsnetzwerk, das Ausgangsnetzwerk ist eng genug, weil der Kanal asymmetrisch ist und es keine Probleme mit Codecs gibt - alle Codecs sind kostenlos.

Wenn wir anfangen, Gruppengespräche zu führen, müssen wir alle wieder verbinden. Die einfachste Version der Topologie ist Mesh oder "all to all".

Es ist großartig, dass keine Zwischenserver benötigt werden, aber es wird problematisch, jedem Ihr Video für Kunden mit solchen Eigenschaften zur Verfügung zu stellen. Und wenn der Client das Video nicht alleine an jemanden verteilen kann, müssen Sie die Qualität verringern, da der gemeinsame Stream für alle codiert ist.

In diesem Fall reichen für 5 Teilnehmer weder 3 noch 4 Mbit / s aus.

Aus diesem Grund gibt es in WhatsApp in einem Gruppenanruf maximal 4 Teilnehmer, die nicht mehr so ​​lange teilnehmen, wie sie Mesh verwenden.

Eine andere Möglichkeit besteht darin, das gesamte Bild auf dem Server zu sammeln . Dies ist für den Client am rentabelsten: Er hat eine Verbindung zum Server, der Server sammelt das Bild, der Client erhält es zurück.

Angenommen, unsere Benutzer aus Petropavlovsk-Kamchatsky, Komsomolsk-on-Amur und Novosibirsk möchten über einen Moskauer Server chatten. Natürlich wird es sehr schlecht ausgehen. Das Vorhandensein von CDN wird ein wenig helfen, aber dennoch eine große Menge an Jitter-Puffern erhalten, was insgesamt zu einer angemessenen Erhöhung der Latenz führt.

Die nächste Topologie - das Mischen beenden - schlägt vor, kein allgemeines Bild auf dem Server zu sammeln, um diese Verzögerungen zu vermeiden, sondern einfach Pakete auszulösen.

Das heißt, der Server in dieser Topologie ist einfach ein Relay, das Daten überträgt.

Alles wird ein bisschen besser: Der Benutzer empfängt Streams aller anderen Teilnehmer des Anrufs und sendet seine eigenen nur einmal. Aber auch hier gibt es Probleme:

• Qualität. Alle Empfänger Ihres Streams haben ein anderes Netzwerk. Wenn eine Person mit einer schlechten Internetverbindung verbunden ist, muss das Video in niedriger Auflösung an sie gesendet werden, und dementsprechend wird das Bild für alle schlecht.
• Storm Referenzrahmen . Wenn eine Person mit schlechtem Internet ständig nach einem Referenzrahmen fragt, dann fängt auch jeder an, Oporniks zu erhalten. Dies ist eine ineffiziente Verwendung der Bitrate, die Qualität nimmt wieder ab.

Wenn ein zentrales System verwendet wird, werden alle Videos auf dem Server gesammelt. Dies erfordert viele Codierungsstufen, die sowohl die Latenz erhöhen als auch zusätzliche Hardware erfordern. Beim Endmischen hingegen ist alles schnell und einfach.

Nachteile Topologien:

• Mesh - maximal 4 Mitglieder.
• Zentralisiert - Probleme mit der Transcodierung und mit Jitter.
• Ende mischen - Qualitätslimit und Sturmbezugsrahmen.

Nur ICQ und Skype funktionieren in der Mesh-Topologie, und der Rest ist das Endmischen. Aber, wie wir uns erinnern, unterscheiden sich alle Services in ihren Eigenschaften - was bedeutet, dass es nicht nur Endmixing gibt, sondern etwas anderes.

Hangouts haben den Trick mit Endmix gemacht.

Auf jedem Client werden zwei Encoder gestartet: H.264 in hoher Qualität und VP8 in niedriger Qualität. Dementsprechend überträgt der Server für Benutzer mit gutem Internet qualitativ hochwertige Videos, für Benutzer mit schlechtem Internet ist dies schlechter, und schlechte Qualität passt sich an das schlechteste Netzwerk an. Zwei Eigenschaften sind gut, aber das ist zusätzlicher Verkehr von Kunden und Batterieverbrauch. Es gibt aber keinen Jitterpuffer

Die Tabelle zeigt, dass bei Hangouts, in denen das Telefon am meisten erwärmt wird, nur minimale Verzögerungen auftreten, die Qualität jedoch darunter leidet, da die hohe Bitrate bei niedriger Qualität nach wie vor sinkt.

Wir haben uns entschlossen, einen Schritt weiter zu gehen und ein Spiel wie dieses zu spielen: Führen Sie dennoch keine Software-Codecs vom Client aus, codieren Sie H.264, nutzen Sie den Kanal in vollem Umfang unter einem Stream (dies spart Batterie und Verkehr), und verwenden Sie das End-Mischschema für hohe Qualität. centralized-, , , , .

, : . , , , , - . , .

.

, , , latency . , , , , . centralized, , , jitter- . , , .

«», . 100, 50, 20 . .

— , 5 . . : , , , — .

«» , , , — . : , - , fps. , — . - , . , .

Mesh 3-4 latency, , Mesh. , HD End mixing, a SD — centralized.

Zoom.

, - , Zoom , WebRTC. WebRTC , .

.

CPU , . — , , , , CPU , . , .

: , , .

screen sharing . screen sharing, , . screen sharing . , fps — , , .

. — centralized, , . , .

, , , . , , .

, , - . .

Packet pacing

-, UDP- . UDP pacing. UDP- , .

, UDP , 21 100%. — .

pacing? , ( ) — , . , , , , , , - .

:

• pacing, .
• pacing, , , , .

: , pacing , —.

packet pacing?

, ( ) , , - . ( ), , , .

— packet loss , pacing.

MTU

TCP , MTU. UDP, , MTU — , .

MTU 1500, MTU 1100, . , , , , , ( ). , MTU .

TCP , . , MTU: - , , , MTU. , MTU, , .

.

, : , , . 98% 1350. MTU = 1350 , , 2% — , .

Fehlerbehebung

WebRTC SACK, NACK, FEC. .

, 1–3% — , .

WebRTC negative acknowledgement (NACK).

, , - , .

, TCP acknowledgement, selective acknowledgement. negative acknowledgement , FEC (Forward Error Correction).

, SACK, NACK, FEC, .

FEC , , . : , , . , , — .

FEC — XOR, , , . , - .

, . , , , FEC-. , , , , .

, , . , :

• 90% 500 /.
• — 3-4, Mesh End mixing.
• — 27 (, ).

Check List

:

• Packet pacing.
• MTU discovery.
• Fehlerbehebung
• C .

, signalling, WebRTC, , , - .

, :

• Packet loss: , packet pacing, FEC, MTU.
• : back pressure , FEC-.
• Jitter jitter buffer, latency.
• RTT: , signaling.

WebRTC — . RTP, , , . WebRTC .

, Zoom, Skype Line, . . . , , UDP- ( , WebRTC), . , , . , Google STADIA.

STADIA — , . WebRTC, , . Google WebRTC. WebRTC SRTP WebRTC QUIC. , , .

QUIC, . Chrome c Android Google YouTube, TCP — QUIC UDP Google. 30% QUIC/UDP.

QUIC 20-30%, TCP. - QUIC , .

Schlussfolgerungen

, . , : signaling; / ; . , , .

?

• , - , .
• , .

/ .

, , — . , latency, . , ! - :)

HighLoad++ . ( ) , 6-7 2020 . , .