RTCQuicTransport in einem Ursprungstest in Ihrer Nähe (Chrome 73)

Was?

RTCQuicTransport ist eine neue Webplattform, API, die den Austausch beliebiger Daten mit Remote-Peers mithilfe von QUIC ermöglicht Protokoll. Es ist für Peer-to-Peer-Anwendungsfälle vorgesehen und wird daher mit ein eigenständiges RTCIceTransport-Objekt API zum Herstellen einer Peer-to-Peer-Verbindung über ICE Die Daten werden zuverlässig und in der richtigen Reihenfolge übertragen (siehe Abschnitt unten). unzuverlässige Lieferung). Da es sich um einen generischen bidirektionale Datenübertragung, kann für Spiele, Dateiübertragungen, Medientransport, Messaging usw.

Warum?

Ein leistungsstarkes Low-Level-Data-Transport-API ermöglicht Anwendungen (z. B. Echtzeit- Kommunikation), um neue Dinge im Web zu tun. Sie können auf der API aufbauen, Ihre eigenen Lösungen zu entwickeln und dabei die Grenzen dessen zu erweitern, was mit Peers und Peer-Verbindungen herstellen, z. B. zum Entsperren benutzerdefinierter Regler für die Bitratezuweisung. In Künftig könnte eine weitere Unterstützung für codierte Medien sogar dazu beitragen, eigene Videokommunikationsanwendung mit Low-Level-Steuerung. WebRTCs NV-Aufwand auf untergeordnete APIs zu setzen. Ein frühzeitiges Experimentieren wertvoll sind.

Warum QUIC?

Für die Echtzeitkommunikation eignet sich das QUIC-Protokoll. Es baut auf dem verfügt über integrierte Verschlüsselung, Überlastungskontrolle und Multiplexing ohne Blockierung der Zeilenüberschrift RTCQuicTransport bietet sehr ähnliche Funktionen wie die RTCDataChannel API, verwendet jedoch QUIC statt SCTP als Transport Protokoll. Da es sich bei RTCQuicTransport um eine eigenständige API handelt, den Aufwand der RTCPeerConnection API, die die Echtzeitmedien umfasst Stacks.

Wie?

Allgemeine API-Übersicht

Die API hat drei Hauptabstraktionen: RTCIceTransport, RTCQuicTransport und RTCQuicStream.

RTCQuicTransport-Diagramm zur Darstellung der API-Architektur

RTCIceTransport

ICE ist ein Protokoll zum Herstellen von Peer-to-Peer-Verbindungen über das Internet und wird heute in WebRTC verwendet. Dieses Objekt bietet ein eigenständiges API zum Erstellen eine ICE-Verbindung. Es wird als Pakettransport für die QUIC-Verbindung verwendet. und der RTCQuicTransport übernimmt ihn in seinem Konstruktor.

RTCQuicTransport

Stellt eine QUIC-Verbindung dar. Damit wird eine QUIC-Verbindung hergestellt und QUIC-Streams erstellen Außerdem werden relevante Statistiken für die QUIC-Verbindung angezeigt.

RTCQuicStream

Wird zum Lesen und Schreiben von Daten auf der Remoteseite verwendet. Streams-Transport Daten zuverlässig und in der richtigen Reihenfolge. Aus demselben Stream können mehrere Streams erstellt werden. RTCQuicTransport und sobald Daten in einen Stream geschrieben wurden, wird ein „onquicstream“-Ereignis. Streams bieten eine Möglichkeit, unterschiedliche Daten über dieselbe QUIC-Verbindung unterscheiden. Gängige Beispiele können separate Dateien über separate Streams, kleine Datenblöcke verschiedene Streams oder verschiedene Medientypen in separaten Streams. RTCQuicStream-Elemente sind schlank, werden über eine QUIC-Verbindung gemultiplext und verhindern, dass die Zeilenüberschrift anderen RTCQuicStreams blockiert.

Verbindungseinrichtung

Das folgende Beispiel zeigt die Einrichtung einer Peer-to-Peer-QUIC-Verbindung. Wie RTCPeerConnection erfordert auch die RTCQuicTransport API die Verwendung eines sichere Signalisierungskanal, um die Parameter der Verbindung auszuhandeln, einschließlich seiner Sicherheitsparameter. RTCIceTransport handelt mit ICE aus -Parametern (ufrag und Passwort) sowie RTCIceCandidates verwenden.

RTCQuicTransport-Diagramm zur Darstellung der API-Architektur

Kundenperspektive:

const iceTransport = new RTCIceTransport();
const quicTransport = new RTCQuicTransport(iceTransport);
// Signal parameters, key and candidates.
signalingChannel.send({
  iceParams: iceTransport.getLocalParameters(),
  quicKey: quicTransport.getKey(),
});
iceTransport.onicecandidate = e => {
  if (e.candidate) {
    signalingChannel.send({candidate: e.candidate});
  }
};

// When remote parameters are signaled, start connection.
signalingChannel.onMessage = async ({iceParams, candidate}) => {
  if (iceParams) {
    iceTransport.start(iceParams);
    quicTransport.connect();
  } else if (candidate) {
    iceTransport.addRemoteCandidate(candidate);
  }
};

Serverperspektive:

const iceTransport = new RTCIceTransport();
const quicTransport = new RTCQuicTransport(iceTransport);
// Signal parameters, key and candidates.
signalingChannel.send({
  iceParams: iceTransport.getLocalParameters(),
});
iceTransport.onicecandidate = e => {
  if (e.candidate) {
    signalingChannel.send({candidate: e.candidate});
  }
};

// When remote parameters are signaled, start connection.
signalingChannel.onMessage = async ({iceParams, quicKey, candidate}) => {
  if (iceParams && quicKey) {
    iceTransport.start(iceParams);
    quicTransport.listen(quicKey);
  } else if (candidate) {
    iceTransport.addRemoteCandidate(candidate);
  }
};

Datenübertragung

Die Datenübertragung kann mithilfe der RTCQuicStream APIs zum Lesen und Schreiben:

RTCQuicStreamReadResult readInto(Uint8Array data);
void write(RTCQuicStreamWriteParameters data);
Promise<void> waitForWriteBufferedAmountBelow(unsigned long amount);
Promise<void> waitForReadable(unsigned long amount);

Pufferung

Die von den waitFor*-Methoden zurückgegebenen Promis ermöglichen das Zwischenspeichern von Daten, wenn JavaScript ist ausgelastet. Gegendruck wird auf die Sendeseite ausgeübt, auf der Empfangsseite voll ist. Die Absenderseite hat einen Schreibvorgang Puffer, der sich füllen kann, wenn Gegendruck ausgeübt wird. hat auch die Schreibseite eine waitForWriteBufferedAmountBelow-Methode, um im Puffer zu warten, bis ein Schreibraum vorhanden ist. Weitere Informationen zu das Schreiben/Lesen von Daten befindet sich Dokumentation.

Unbestellte/Unzuverlässige Lieferung

Während ein RTCQuicStream nur das Senden von Daten zuverlässig und in einer bestimmten Reihenfolge unterstützt, Eine unzuverlässige/ungeordnete Lieferung kann auf andere Weise erreicht werden. Für ungeordnete Lieferung, können kleine Datenblöcke in separaten Streams weil die Daten nicht nach Streams sortiert sind. Bei einer unzuverlässigen Lieferung kleine Datenblöcke mit der Einstellung "Finish" auf "true", gefolgt von einem Aufruf reset() im Stream nach einer Zeitüberschreitung. Das Zeitlimit sollte von wie viele erneute Übertragungen erwünscht sind, bevor die Daten gelöscht werden.

Wann?

Der Ursprungstest beginnt in Chrome 73 und ist verfügbar einschließlich Version M75. Danach wird der Ursprungstest enden. Basierend auf Feedback und Interesse nehmen wir die entsprechenden Änderungen vor. und entweder die API versenden, mit einem neuen Ursprungstest dieser API fortfahren oder die API einzustellen.

Wo?

Chrome-Browser auf allen Plattformen außer iOS

Was noch?

Feedback

Eines der Hauptziele des Ursprungstests ist es, Feedback von Ihnen, den Entwicklern. Wir interessieren uns für:

  • Was bietet Ihnen diese API?
  • Wie verbessert diese API andere Datenübertragungs-APIs? (WebSockets oder RTCDataChannel von WebRTC)? Was könnte verbessert werden?
  • Leistung
  • API-Ergonomie

Für Ursprungstest registrieren

  1. Fordern Sie ein Token für Ihren Ursprung an.
  2. Fügen Sie das Token zu Ihren Seiten hinzu. Es gibt zwei Möglichkeiten, alle Seiten in Ihrem Ursprungsserver, <ph type="x-smartling-placeholder">
      </ph>
    • Fügen Sie im <head>-Bereich einer Seite ein origin-trial-<meta>-Tag ein. Beispiel: könnte dies etwa so aussehen: <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • Wenn Sie Ihren Server konfigurieren können, können Sie das Token auch auf Seiten bereitstellen. mit einem Origin-Trial-HTTP-Header. Der resultierende Antwortheader sollte Sie sehen in etwa so aus: Origin-Trial: TOKEN_GOES_HERE

Webspezifikation

Der Spezifikationsentwurf wurde im Ursprungstest der API vorgezogen einschließlich:

  • Unidirektionale Streams, die besser auf WHATWG-Streams ausgerichtet sind
  • Erneute Übertragungen deaktivieren
  • (Demnächst verfügbar) Datagramme

Wir sind daran interessiert, die gesamte Spezifikation und darüber hinaus zu implementieren (einschließlich WHATWG-Stream-Support. Ich möchte aber zuerst dein Feedback hören.

Sicherheit

Die Sicherheit im QUIC-Handshake wird durch die Nutzung eines vorab freigegebenen Schlüssels erzwungen, eine verschlüsselte P2P-QUIC-Verbindung herstellen. Dieser Schlüssel muss über einen sicheren Out-of-Band-Kanal mit Gewährleistung für Vertraulichkeit und Integrität Beachten Sie, dass der Schlüssel für JavaScript verfügbar gemacht wird.

Aktiver Angriff

Im Gegensatz zu DTLS-SRTP, das nur eine Integrität für die Signalisierung des Zertifikats erfordert Fingerabdruck haben, erfordert die Signalisierung des vorinstallierten Schlüssels Integrität und Vertraulichkeit. Wenn der PSK manipuliert wurde (z. B. durch den Server in der Signalisierung Kanal), könnte ein aktiver Angreifer potenziell einen Man-in-the-Middle-Angriff ausführen. QUIC-Handshakes hoch.

Aktueller Status

Schritt Status
1. Erklärende Mitteilung erstellen Abschließen
**2a. RTCQuicTransport-Spezifikation ** **In Bearbeitung**
**2b. RTCIceTransport-Spezifikation ** **In Bearbeitung**
**3. Feedback einholen und Design iterieren** **In Bearbeitung**
4. Ursprungstest Ab Chrome 73!
5. Starten Nicht gestartet

Hilfreiche Links