Utiliser WebTransport

Jeff Posnick

Publié le : 8 juin 2020

WebTransport est une API Web qui utilise le protocole HTTP/3 comme transport bidirectionnel. Il est destiné aux communications bidirectionnelles entre un client Web et un serveur HTTP/3. Il permet d'envoyer des données de manière non fiable avec ses API de datagrammes et de manière fiable avec ses API de flux.

Les datagrammes sont idéaux pour envoyer et recevoir des données qui ne nécessitent pas de fortes garanties de remise. La taille des paquets de données individuels est limitée par l'unité de transmission maximale (MTU) de la connexion sous-jacente. Ils peuvent être transmis ou non, et s'ils le sont, ils peuvent arriver dans n'importe quel ordre. Ces caractéristiques font des API de datagrammes un outil idéal pour la transmission de données avec une faible latence et un effort maximal. Vous pouvez considérer les datagrammes comme des messages UDP (User Datagram Protocol), mais chiffrés et avec contrôle de congestion.

En revanche, les API de flux fournissent un transfert de données fiable et ordonné. Ils sont bien adaptés aux scénarios dans lesquels vous devez envoyer ou recevoir un ou plusieurs flux de données ordonnées. L'utilisation de plusieurs flux WebTransport est analogue à l'établissement de plusieurs connexions TCP, mais comme HTTP/3 utilise le protocole QUIC plus léger en arrière-plan, ils peuvent être ouverts et fermés sans autant de surcharge.

Cas d'utilisation

Voici une petite liste des utilisations possibles de WebTransport par les développeurs.

• Envoyer l'état du jeu à intervalles réguliers avec une latence minimale à un serveur dans de petits messages non fiables et non ordonnés.
• Recevoir des flux multimédias envoyés par un serveur avec une latence minimale, indépendamment des autres flux de données.
• Recevoir des notifications envoyées par un serveur lorsqu'une page Web est ouverte.

Nous aimerions en savoir plus sur la façon dont vous prévoyez d'utiliser WebTransport.

Prise en charge des navigateurs

Comme pour toutes les fonctionnalités qui ne sont pas compatibles avec tous les navigateurs, nous vous recommandons d'ajouter une détection de fonctionnalité.

Relation avec d'autres technologies

WebTransport remplace-t-il WebSockets ?

Peut-être. Dans certains cas d'utilisation, WebSockets ou WebTransport peuvent être des protocoles de communication valides.

Les communications WebSockets sont modélisées autour d'un flux de messages unique, fiable et ordonné, ce qui convient à certains types de besoins de communication. Si vous avez besoin de ces caractéristiques, les API de flux de WebTransport peuvent également les fournir. En comparaison, les API de datagrammes de WebTransport offrent une diffusion à faible latence, sans garantie de fiabilité ni d'ordre. Elles ne remplacent donc pas directement les WebSockets.

Lorsque vous utilisez WebTransport, avec les API de datagrammes ou plusieurs instances d'API Streams simultanées, vous n'avez pas à vous soucier du blocage en tête de file, qui peut poser problème avec les WebSockets. De plus, l'établissement de nouvelles connexions présente des avantages en termes de performances, car le handshake QUIC sous-jacent est plus rapide que le démarrage de TCP sur TLS.

WebTransport fait partie d'une nouvelle spécification provisoire. L'écosystème WebSocket autour des bibliothèques client et serveur est donc beaucoup plus robuste. Si vous avez besoin d'une solution qui fonctionne "prête à l'emploi" avec les configurations de serveur courantes et une large compatibilité avec les clients Web, WebSockets est un meilleur choix aujourd'hui.

WebTransport est-il identique à une API de socket UDP ?

Non. WebTransport n'est pas une API UDP Socket. Bien que WebTransport utilise HTTP/3, qui à son tour utilise UDP "en coulisses", WebTransport a des exigences en matière de chiffrement et de contrôle de la congestion qui en font plus qu'une simple API de socket UDP.

WebTransport est-il une alternative aux canaux de données WebRTC ?

Oui, pour les connexions client-serveur. WebTransport partage de nombreuses propriétés avec les canaux de données WebRTC, bien que les protocoles sous-jacents soient différents.

En général, l'exécution d'un serveur compatible HTTP/3 nécessite moins de configuration que la maintenance d'un serveur WebRTC, qui implique de comprendre plusieurs protocoles (ICE, DTLS et SCTP) pour obtenir un transport fonctionnel. WebRTC implique beaucoup plus d'éléments mobiles qui peuvent entraîner l'échec des négociations client/serveur.

L'API WebTransport a été conçue en tenant compte des cas d'utilisation des développeurs Web. Elle devrait ressembler davantage à l'écriture de code de plate-forme Web moderne qu'à l'utilisation des interfaces de canal de données de WebRTC. Contrairement à WebRTC, WebTransport est compatible avec les Web Workers, ce qui vous permet d'effectuer des communications client-serveur indépendamment d'une page HTML donnée. Comme WebTransport expose une interface conforme à Streams, il est compatible avec les optimisations liées à la rétropression.

Toutefois, si vous disposez déjà d'une configuration client/serveur WebRTC fonctionnelle qui vous convient, le passage à WebTransport n'offrira peut-être pas beaucoup d'avantages.

Test

Le meilleur moyen d'expérimenter WebTransport est de démarrer un serveur HTTP/3 compatible. Utilisez cette page avec un client JavaScript de base pour tester les communications entre le client et le serveur.

De plus, un serveur d'écho géré par la communauté est disponible sur webtransport.day.

Utiliser l'API

WebTransport a été conçu sur la base de primitives de plate-forme Web modernes, comme l'API Streams. Il s'appuie fortement sur les promesses et fonctionne bien avec async et await.

L'implémentation actuelle de WebTransport dans Chromium est compatible avec trois types de trafic distincts : les datagrammes, ainsi que les flux unidirectionnels et bidirectionnels.

Se connecter à un serveur

Vous pouvez vous connecter à un serveur HTTP/3 en créant une instance WebTransport. Le schéma de l'URL doit être https. Vous devez spécifier explicitement le numéro de port.

Vous devez utiliser la promesse ready pour attendre que la connexion soit établie. Cette promesse reste non tenue jusqu'à ce que la configuration soit terminée et est rejetée si la connexion échoue au niveau QUIC/TLS.

La promesse closed est tenue lorsque la connexion se ferme normalement et rejetée si la fermeture est inattendue.

Si le serveur rejette la connexion en raison d'une erreur d'indication du client (par exemple, si le chemin d'accès de l'URL n'est pas valide), closed est rejeté, tandis que ready reste non résolu.

const url = 'https://example.com:4999/foo/bar';
const transport = new WebTransport(url);

// Optionally, set up functions to respond to
// the connection closing:
transport.closed.then(() => {
  console.log(`The HTTP/3 connection to ${url} closed gracefully.`);
}).catch((error) => {
  console.error(`The HTTP/3 connection to ${url} closed due to ${error}.`);
});

// Once .ready fulfills, the connection can be used.
await transport.ready;

API Datagram

Une fois que vous disposez d'une instance WebTransport connectée à un serveur, vous pouvez l'utiliser pour envoyer et recevoir des bits de données distincts, appelés datagrammes.

L'accesseur writeable renvoie un WritableStream, qu'un client Web peut utiliser pour envoyer des données au serveur. L'accesseur readable renvoie un ReadableStream, ce qui vous permet d'écouter les données du serveur. Les deux flux étant intrinsèquement peu fiables, il est possible que les données que vous écrivez ne soient pas reçues par le serveur, et vice versa.

Les deux types de flux utilisent des instances Uint8Array pour le transfert de données.

// Send two datagrams to the server.
const writer = transport.datagrams.writable.getWriter();
const data1 = new Uint8Array([65,