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

Quoi ?

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

Pourquoi ?

Une API de transport de données de bas niveau puissante peut permettre aux applications (telles que les communications en temps réel) d'effectuer de nouvelles actions sur le Web. Vous pouvez exploiter l'API pour créer vos propres solutions et repousser les limites des connexions peer-to-peer (par exemple, en débloquant des boutons personnalisés d'allocation de débit). À l'avenir, une prise en charge accrue des médias encodés pourrait même permettre de créer votre propre application de communication vidéo avec des commandes de bas niveau. L'initiative NV de WebRTC consiste à passer aux API de niveau inférieur. Il est donc utile de tester cette approche le plus tôt possible.

Pourquoi utiliser le protocole QUIC ?

Le protocole QUIC est souhaitable pour les communications en temps réel. Il repose sur UDP, dispose d'un chiffrement intégré, d'un contrôle de l'encombrement et est multiplexé sans blocage en tête de ligne. RTCQuicTransport offre des fonctionnalités très semblables à celles de l'API RTCDataChannel, mais utilise QUIC au lieu de SCTP comme protocole de transport. Comme RTCQuicTransport est une API autonome, elle n'entraîne pas les frais généraux de l'API RTCPeerConnection, qui inclut la pile multimédia en temps réel.

Comment ?

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

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

Schéma de RTCQuicTransport illustrant l'architecture d'une API

RTCIceTransport

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

RTCQuicTransport

Représente une connexion QUIC. Elle permet d'établir une connexion QUIC et de créer des flux QUIC. Il expose également des statistiques pertinentes pour le niveau de connexion QUIC.

RTCQuicStream

Utilisé pour la lecture et l'écriture de données depuis/vers le côté distant. Les flux transportent les données de manière fiable et dans l'ordre. Plusieurs flux peuvent être créés à partir du même RTCQuicTransport. Une fois les données écrites dans un flux, un événement "onquicstream" est déclenché sur le transport distant. Les flux permettent de distinguer différentes données sur la même connexion QUIC. Par exemple, vous pouvez envoyer des fichiers distincts sur des flux distincts, de petits segments de données dans différents flux ou différents types de contenus multimédias sur plusieurs flux. Les RTCQuicStream sont légers, sont multiplexés via une connexion QUIC et ne bloquent pas les autres RTCQuicStream.

Configuration de la connexion

L'exemple ci-dessous montre comment configurer une connexion QUIC peer-to-peer. Comme RTCPeerConnection, l'API RTCQuicTransport nécessite l'utilisation d'un canal de signal sécurisé pour négocier les paramètres de la connexion, y compris ses paramètres de sécurité. Le RTCIceTransport négocie ses paramètres ICE (ufrag et mot de passe), ainsi que ses RTCIceCandidate.

Schéma de RTCQuicTransport illustrant l'architecture d'une API

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

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

Data Transfer

Le transfert de données peut être réalisé à l'aide des API RTCQuicStream pour la lecture et l'é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* permettent de mettre en mémoire tampon les données lorsque JavaScript est occupé. Une contre-pression est appliquée au côté envoi lorsque le tampon de lecture est plein du côté de la réception. Le côté envoi dispose d'un tampon d'écriture qui peut se remplir lorsque la contre-pression est appliquée. Par conséquent, le côté écriture dispose également d'une méthode waitForWriteBufferedAmountBelow permettant d'attendre de l'espace dans le tampon pour l'écriture. Pour en savoir plus sur l'écriture et la lecture de données, consultez la documentation supplémentaire destinée aux développeurs.

Livraison non fiable/non commandée

Bien qu'une RTCQuicStream ne permette que l'envoi de données de manière fiable et dans l'ordre, une livraison non fiable ou non ordonnée peut être obtenue par d'autres moyens. Dans le cas d'une livraison non ordonnée, il est possible d'envoyer de petits segments de données sur des flux distincts, car les données ne sont pas ordonnées entre les flux. En cas de distribution non fiable, vous pouvez envoyer de petits segments de données avec la valeur "true" définie sur "true", puis appeler reset() sur le flux après un délai d'inactivité. Le délai avant expiration doit dépendre du nombre de retransmissions souhaitées avant la suppression des données.

Quand ?

La phase d'évaluation commencera dans la version Chrome 73 et sera disponible jusqu'à la version M75 (incluse). Passé ce délai, la phase d'évaluation prendra fin. Suite à vos commentaires et à votre intérêt, nous apporterons les modifications appropriées, puis nous expédierons l'API, poursuivrons une nouvelle phase d'évaluation ou interrompons l'API.

Où :

Navigateur Chrome sur toutes les plates-formes sauf iOS.

Quoi d'autre ?

Commentaires

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

  • Que vous apporte cette API ?
  • En quoi cette API améliore-t-elle les autres API de transport de données (WebSocket ou RTCDataChannel de WebRTC) ? Comment pourrions-nous l'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 manières de le fournir sur toutes les pages de votre origine :
    • Ajoutez une balise <meta> origin-trial à l'en-tête de n'importe quelle page. Par exemple : <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 obtenu doit se présenter comme suit: Origin-Trial: TOKEN_GOES_HERE

Spécification Web

Le brouillon de spécification a devancé l'API dans la phase d'évaluation, y compris:

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

Nous souhaitons implémenter la spécification complète et plus encore (y compris la prise en charge des flux WhatWG), mais nous voulons d'abord recueillir vos commentaires.

Sécurité

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

Attaque active

Contrairement au protocole DTLS-SRTP, qui nécessite simplement une intégrité pour signaler l'empreinte du certificat, le signalement de la clé pré-partagée nécessite une intégrité et une confidentialité. Si la clé PSK est compromise (par exemple par le serveur dans le canal de signalement), un pirate informatique actif peut potentiellement lancer une attaque man-in-the-middle contre le handshake QUIC.

État actuel

Step État
1. Créer une vidéo explicative Fin
**2a. Spécification RTCQuicTransport ** **En cours**
**2b. Spécification RTCIceTransport ** **En cours**
**3. Recueillez des commentaires et itérez la conception** **En cours**
4. Phase d'évaluation Commence dans Chrome 73
5. Lancement Non démarrée

Liens utiles