QUIC DataChannels: Erste Schritte

QUIC-basierte Datenkanäle gelten als Alternative zum aktuellen SCTP-Transport. Die Google WebRTC-Arbeitsgruppe experimentiert bereits mit ihnen:


Lass es uns auch versuchen. Zu diesem Zweck erstellen wir eine einseitige Anwendung , die dem Beispiel eines WebRTC-Kanals zum Senden von Text ähnelt. Dies ist ein voll funktionsfähiges Beispiel (ohne Signalisierungsserver), das außerdem den Vergleich von Ansätzen zur Implementierung von WebRTC-Datenkanälen erleichtert.

Bevor wir beginnen, erinnern wir uns an die Grundlagen des DataChannel .

Kurz über DataChannel

Mit den DataChannels von WebRTC können Teilnehmer beliebige Daten austauschen. Sie können sowohl zuverlässig sein - was beim Übertragen von Dateien sehr nützlich ist - als auch unzuverlässig, was für Informationen über Positionen in Spielen akzeptabel ist. Die API ist eine Erweiterung von RTCPeerConnection und sieht folgendermaßen aus:

 const dc = pc.createDataChannel("some label string"); // ,    – ,   – //    send dc.send("some string"); //    otherPc.addEventListener('datachannel', e => { const channel = e.channel; channel.onmessage = event => { console.log('received', event.data); }); }); 

Auf der offiziellen WebRTC-Beispielseite finden Sie Beispiele für das Senden von Zeichenfolgen und Binärdaten .

DataChannel verwendet SCTP . Es funktioniert parallel zum RTP-Transport für Audio- und Videostreams. Im Gegensatz zu UDP, das üblicherweise von Audio- und Videostreams verwendet wird, bietet SCTP viele andere Funktionen, z. B. das Multiplexen von Kanälen über eine einzelne Verbindung oder zuverlässige, teilweise zuverlässige (d. H. Zuverlässige, aber ungeordnete) und unzuverlässige Modi.

Google hat QUIC 2012 eingeführt (mehr über den Protokollverlauf und seine Nuancen finden Sie in unserem anderen Material - Anmerkung des Übersetzers). Wie WebRTC wurde auch das QUIC-Protokoll unter die Fittiche der IETF gestellt und heißt jetzt HTTP / 3 . QUIC verfügt über eine Reihe großartiger Innovationen, wie z. B. reduzierte Latenz, Bandbreitenberechnung basierend auf Überlastungskontrolle, direkte Verzögerungskorrektur (FEC) und Implementierung im Benutzerbereich (anstelle des Kernels) für ein schnelleres Rollen.

QUIC könnte eine Alternative zu RTCP für WebRTC sein - wie ein Transport für DataChannel. Das aktuelle Experiment versucht, die Verwendung der RTCPeerConnection-API ( und SDP! ) Durch Verwendung einer separaten Version des ICE-Transports zu vermeiden. Stellen Sie sich eine virtuelle Verbindung vor, die ein wenig Sicherheit und viel NAT-Durchquerung bietet .

Im folgenden Video erklärt Ian Swett vom Chrome-Netzwerkteam dieses Konzept. Und obwohl diese Rede mehrere Jahre alt ist, bietet sie dennoch zusätzliche Informationen zum Thema:

Erste Schritte mit QUIC

Glücklicherweise bleibt der größte Teil des Codes aus dem Artikel von 2015 relevant und lässt sich leicht an die neue API anpassen. Lass es uns herausfinden.

Klonen Sie den Code von hier oder versuchen Sie es hier . Bitte beachten Sie, dass Chrome (Version 73+ ist jetzt Canary) mit speziellen Flags ausgeführt werden muss, damit das Experiment lokal funktioniert:

 google-chrome-unstable --enable-blink-features=RTCQuicTransport,RTCIceTransportExtension 

ICE-Transport-Setup

Die RTCIceTransport-Spezifikation basiert auf ORTC, daher ähnelt das Setup dem alten Code:

 const ice1 = new RTCIceTransport(); ice1.onstatechange = function() { console.log('ICE transport 1 state change', ice1.state); }; const ice2 = new RTCIceTransport(); ice2.onstatechange = function() { console.log('ICE transport 2 state change', ice2.state); }; //  ICE- ice1.onicecandidate = function(evt) { console.log('1 -> 2', evt.candidate); if (evt.candidate) { ice2.addRemoteCandidate(evt.candidate); } }; ice2.onicecandidate = function(evt) { console.log('2 -> 1', evt.candidate); if (evt.candidate) { ice1.addRemoteCandidate(evt.candidate); } }; //  ICE- ice1.start(ice2.getLocalParameters(), 'controlling'); ice2.start(ice1.getLocalParameters(), 'controlled'); ice1.gather(iceOptions); ice2.gather(iceOptions); 

Beachten Sie, dass diese API im Gegensatz zu ORTC keinen RTCIceGatherer hat. Weil wir bereits alles haben, was wir zur Installation des ICE-Transports benötigen.

QUIC-Transport konfigurieren

 const quic1 = new RTCQuicTransport(ice1); quic1.onstatechange = function() { console.log('QUIC transport 1 state change', quic1.state); }; const quic2 = new RTCQuicTransport(ice2); quic2.onstatechange = function() { console.log('QUIC transport 2 state change', quic2.state); }; //     QUIC quic2.addEventListener('quicstream', (e) => { console.log('QUIC transport 2 got a stream', e.stream); receiveStream = e.stream; }); 

Hier weicht das Experiment von einer Spezifikation ab, die eine zertifikatbasierte Authentifizierung verwendet. Stattdessen wird der öffentliche Schlüssel verwendet, wie im Beitrag der Google-Entwickler angegeben :

Die RTCQuicTransport-Verbindung wird mit einem öffentlichen API-Schlüssel konfiguriert. Wir planen derzeit nicht, dass diese API die ursprüngliche Validierung ersetzt. Es wird durch eine Remote-Zertifikatsignalisierung ersetzt, um selbstsignierte Zertifikate zu validieren - wenn QUIC dies in Chromium unterstützt.

So weit, so gut.

QUICStream zum Senden und Empfangen von Daten

Die Verwendung von QUICStream ist etwas schwieriger als die Verwendung von WebRTC DataChannel. Die von der WHATWG-Arbeitsgruppe erstellte Streams-API ( siehe Details zu MDN ) wurde akzeptiert, aber nicht implementiert .

Wir erstellen sendStream erst, nachdem der QUIC-Transport in den Status "verbunden" versetzt wurde - in einem anderen Status würde dies zu einem Fehler führen:

 quic1.onstatechange = function() { console.log('QUIC transport 1 state change', quic1.state); if (quic1.state === 'connected' && !sendStream) { sendStream = quic1.createStream('webrtchacks'); //   createDataChannel. document.getElementById('sendButton').disabled = false; document.getElementById('dataChannelSend').disabled = false; } }; 

Dann hängen wir die Handler an die Senden-Schaltfläche und das Eingabefeld an: Nach dem Klicken auf die Schaltfläche wird der Text aus dem Eingabefeld in Uint8Array codiert und in den Stream geschrieben:

 document.getElementById('sendButton').onclick = () => { const rawData = document.getElementById('dataChannelSend').value; document.getElementById('dataChannelSend').value = ''; //  Uint8Array. ,       TextEncoder. const data = encoder.encode(rawData); sendStream.write({ data, }); }; 

Der erste Eintrag löst das Ereignis onquicstream auf dem Remote-QUIC-Transport aus:

 //     QUIC quic2.addEventListener('quicstream', (e) => { console.log('QUIC transport 2 got a stream', e.stream); receiveStream = e.stream; receiveStream.waitForReadable(1) .then(ondata); }); 

... und dann warten wir, bis die Daten lesbar sind:

 function ondata() { const buffer = new Uint8Array(receiveStream.readBufferedAmount); const res = receiveStream.readInto(buffer); const data = decoder.decode(buffer); document.getElementById('dataChannelReceive').value = data; receiveStream.waitForReadable(1) .then(ondata); } 

Alle Daten von receiveStream werden gelesen, in Text dekodiert und in das Ausgabefeld receiveStream . Und so erscheinen jedes Mal lesbare Daten.

Schlussfolgerung und Kommentare

Ich hoffe, dieses Beispiel ist leichter zu verstehen als das ähnliche im Google-Blog . Diese Methode ist für P2P-Verbindungen kaum geeignet, der DataChannel auf SCTP ist für sie bereits in Ordnung. Dies kann jedoch eine interessante Alternative zu Web-Sockets mit einem QUIC-Server am anderen Ende sein. Bis dies geschieht, sollten Sie einen angemessenen Weg finden, um mit unzuverlässigen und ungeordneten Kanälen zu arbeiten. Meiner Meinung nach ähneln die Vorschläge aus dem oben genannten Beitrag eher Hacks als Entscheidungen.

Es ist auch unklar, auf welches Feedback die Entwickler von außen warten. „Führen Sie die Spezifikation bereits ein, anstatt die Verknüpfungen erneut zu formen, was noch einige Jahre bei uns bleiben wird“, klingt zu offensichtlich. Außerdem tendiert die allgemeine Meinung der Community dazu, WHATWG-Streams zu verwenden, was seltsame Lichtentwickler dazu bringt, ihre eigene API zum Lesen von Daten zu testen.

Ich möchte auch, dass SCTP in Chromium zusätzliche Funktionen bietet. Zum Beispiel ist diese Abfrage zu DataChannel - übrigens die am höchsten bewertete - drei Jahre lang fast unberührt geblieben. Es ist nicht ganz klar, warum der Schwerpunkt auf QUIC liegt, wenn noch SCTP-Aufgaben vorhanden sind. Dies sollte jedoch niemanden davon abhalten, QUIC und Feedback zu den Ergebnissen zu testen.

Kommentar von Voximplant

Ein Wort zu unserem Frontend Lead Irbisadm :

Unsere SDKs werden seit langem zur Signalisierung eines Web-Sockets verwendet. Dies ist ein ausgezeichneter, bewährter Standard, aber es gibt einige Probleme damit. Der erste ist TCP. Und TCP ist in Mobilfunknetzen nicht so gut und schnell und unterstützt kein Roaming zwischen Netzwerken. Zweitens ist es oft textuell (es gibt auch einen Binärmodus, aber Sie sehen ihn selten).

Wir haben kürzlich einen Closed Beta-Test des Signalisierungsprotokolls auf dem DataChannel gestartet. Dieses Protokoll ist auch nicht ohne Minuspunkte, aber da es in schlechten Netzwerken und beim Roaming funktioniert, erobert es auf den ersten Blick. Haben Sie das Netzwerk geändert? Die Verbindung muss nicht neu erstellt werden. ICE Restart hilft in den meisten Fällen dabei, einen neuen Weg für den Verkehr zu finden. Aber wie gesagt, das Protokoll hat immer noch Nachteile: Nicht alle Browser unterstützen alle Protokollerweiterungen, wie z. B. garantierte Zustellung und Unterstützung für Paketbestellungen. Außerdem unterstützt das Protokoll gzip für den sofort einsatzbereiten Textmodus nicht. All diese Probleme können jedoch auf der Anwendungsseite gelöst werden.