RTCQuicTransport arrive en phase d'évaluation près de chez vous (Chrome 73)

Quoi ?

RTCQuicTransport est une nouvelle plate-forme Web API permettant d'échanger des données arbitraires avec des pairs distants à l'aide de QUIC standard. Il est destiné à des cas d'utilisation peer-to-peer, et il est donc utilisé avec un réseau RTCIceTransport autonome API permettant d'établir une connexion peer-to-peer via ICE Les données sont transmises de manière fiable et dans l'ordre (voir la section ci-dessous). pour en savoir plus sur les commandes une livraison non fiable). Puisqu'il s'agit d'une requête générique, le transport de données bidirectionnel, il peut être utilisé pour le jeu, le transfert de fichiers, transport multimédia, messagerie, etc.

Pourquoi ?

Une API de transport de données de bas niveau performante permet d'activer des applications communications) pour faire de nouvelles choses sur le Web. Vous pouvez vous appuyer sur l'API, créer vos propres solutions, repousser les limites de ce que vous pouvez faire avec des pairs aux connexions appairées, par exemple en déverrouillant des commandes personnalisées d'allocation de débit. Dans à l'avenir, la prise en charge supplémentaire des médias encodés pourrait même vous permettre propre application de communication vidéo avec des commandes de bas niveau. Projet NV de WebRTC est de passer à des API de niveau inférieur. Tester cette solution dès le début précieuses.

Pourquoi QUIC ?

Le protocole QUIC est souhaitable pour les communications en temps réel. Elle repose sur du protocole UDP, il intègre un chiffrement et un contrôle de la congestion, et est multiplexé sans en tête de ligne. Le RTCQuicTransport offre des fonctionnalités très semblables à celles l'API RTCDataChannel, mais qui utilise QUIC plutôt que SCTP comme transport standard. Comme RTCQuicTransport est une API autonome, il n'a pas les frais généraux de l'API RTCPeerConnection, qui inclut le contenu multimédia en temps réel pile.

Comment ?

Présentation générale de l'API

L'API comporte trois abstractions principales : RTCIceTransport et RTCQuicTransport. et RTCQuicStream.

Diagramme RTCQuicTransport illustrant l'architecture de l'API

RTCIceTransport

ICE est un protocole permettant d'établir des connexions peer-to-peer sur Internet et est utilisé dans WebRTC aujourd'hui. Cet objet fournit une API autonome pour établir une connexion ICE. Il est utilisé comme transport de paquets pour la connexion QUIC, et RTCQuicTransport l'accepte dans son constructeur.

RTCQuicTransport

Représente une connexion QUIC. Il est utilisé pour établir une connexion QUIC et créer des flux QUIC. Il présente aussi des statistiques pertinentes pour la connexion QUIC d'application.

RTCQuicStream

Utilisé pour la lecture et l'écriture de données vers et depuis le côté distant. Transport de flux de manière fiable et dans l'ordre. Vous pouvez créer plusieurs flux à partir du même RTCQuicTransport et une fois que les données sont écrites dans un flux, elles déclenchent une l'événement "onquicstream" sur le transport distant. Les flux permettent de distinguer des données différentes sur la même connexion QUIC. Voici quelques exemples courants : envoyer des fichiers distincts sur des flux distincts, de petits segments de données différents flux ou différents types de médias sur des flux distincts. Les RTCQuicStream sont légers, sont multiplexés via une connexion QUIC et n'entraîne pas de blocage de l'en-tête de ligne dans les autres éléments RTCQuicStream.

Configuration de la connexion

Voici un exemple de configuration d'une connexion QUIC peer-to-peer : Comme RTCPeerConnection, l'API RTCQuicTransport nécessite l'utilisation d'un d'un canal de signalisation sécurisé pour négocier les paramètres de la connexion, y compris ses paramètres de sécurité. Le RTCIceTransport négocie c'est ICE (ufrag et password), ainsi que RTCIceCandidate.

Diagramme RTCQuicTransport illustrant l'architecture de l'API

Du point de vue du client:

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);
  }
};

Du point de vue du serveur:

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);
  }
};

Transfert de données

Le transfert de données peut être réalisé à l'aide des API RTCQuicStream pour la lecture et en écriture:

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

Mise en mémoire tampon

Les promesses renvoyées par les méthodes waitFor* autorisent la mise en mémoire tampon des données lorsque JavaScript est occupé. Une contre-pression est appliquée sur le côté d'envoi lorsque le tampon de lecture est plein du côté réception. Le côté envoi dispose d'un qui peut se remplir lorsque la contre-pression est appliquée. Côté écriture, vous disposez également d'une méthode waitForWriteBufferedAmountBelow pour permettent d'attendre de l'espace dans le tampon pour écrire. Plus d'informations sur l'écriture/la lecture de données sont disponibles dans la documentation documentation.

Livraison non commandée/non fiable

Alors qu'un RTCQuicStream permet uniquement d'envoyer des données de manière fiable et dans l'ordre, une livraison peu fiable/non ordonnée peut être obtenue par d'autres moyens. Pour distribution non ordonnée, il est possible d'envoyer de petits fragments de données sur des flux distincts car les données ne sont pas ordonnées entre les flux. En cas de diffusion non fiable, peut envoyer de petits segments de données avec l'option "finish" définie sur "true", puis appeler reset() sur le flux après expiration du délai d'inactivité. Le délai avant expiration doit dépendre le nombre de retransmissions souhaitées avant de supprimer les données.

Quand ?

La phase d'évaluation commencera dans la version Chrome 73 et sera disponible jusqu'à la version M75 (incluse). Ensuite, la phase d'évaluation à la fin. Nous procéderons aux modifications appropriées en fonction de vos commentaires et de votre intérêt. et soit expédier l'API, poursuivre une nouvelle phase d'évaluation pour cette API, ou arrêter l'API.

Où ces déclarations sont-elles formulées ?

Navigateur Chrome sur toutes les plates-formes, sauf iOS.

Quoi d'autre ?

Commentaires

L'un des principaux objectifs de la phase d'évaluation est de recueillir vos commentaires, les développeurs. Nous sommes intéressés par:

  • Qu'est-ce que cette API vous apporte ?
  • En quoi cette API améliore-t-elle les autres API de transport de données ? (WebSocket ou RTCDataChannel de WebRTC) ? Comment pourrait-il s'améliorer ?
  • Performances
  • Ergonomie des API

S'inscrire à la phase d'évaluation

  1. Demandez un jeton pour votre origine.
  2. Ajoutez le jeton à vos pages. Il existe deux façons de le fournir sur toutes les pages de votre serveur d'origine: <ph type="x-smartling-placeholder">
      </ph>
    • Ajoutez une balise <meta> origin-trial à l'en-tête de n'importe quelle page. Par exemple : ceci peut se présenter comme suit: <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • Si vous pouvez configurer votre serveur, vous pouvez également fournir le jeton sur les pages à l'aide d'un en-tête HTTP Origin-Trial. L'en-tête de réponse résultant doit ressemble à ceci: Origin-Trial: TOKEN_GOES_HERE

Spécification Web

Le brouillon de spécification a été placé avant l'API lors de la phase d'évaluation y compris:

  • Flux unidirectionnels plus proches des flux WHATWG
  • Désactiver les retransmissions
  • (bientôt disponible) des datagrammes

Nous souhaitons mettre en œuvre la spécification complète et d'autres (y compris l'assistance pour les diffusions avec WhatWG).

Sécurité

La sécurité du handshake QUIC est appliquée grâce à l'utilisation d'une clé pré-partagée une connexion QUIC P2P chiffrée. Cette clé doit être signalée un canal hors bande sécurisé avec des garanties de confidentialité et d'intégrité. Notez que la clé sera exposée à JavaScript.

Attaque active

Contrairement à DTLS-SRTP, qui nécessite simplement l'intégrité pour signaler le certificat pour signaler la clé pré-partagée nécessite une intégrité et la confidentialité. Si la clé pré-partagée est compromise (par exemple, par le serveur canal), un attaquant actif pourrait mener une attaque de type « man-in-the-middle » pour le handshake QUIC.

État actuel

Étape État
1. Créer une vidéo explicative Fin
**2a. Spécification RTCQuicTransport ** **En cours**
**2b. Spécification RTCIceTransport ** **En cours**
**3. Recueillir des commentaires et d'itérer la conception** **En cours**
4. Phase d'évaluation À partir de Chrome 73 !
5. Lancer Non démarré

Liens utiles