Communication navigateur à faible latence avec WebTransport

Si vous avez déjà développé un jeu multijoueur, un tableau de bord de télémétrie en direct ou un outil de collaboration en temps réel, vous avez probablement atteint les limites de ce que les WebSockets peuvent confortablement offrir. Un flux unique ordonné fonctionne bien jusqu’à ce que ce ne soit plus le cas — et lorsqu’un paquet lent bloque tout ce qui suit, les utilisateurs le ressentent immédiatement.

L’API WebTransport est conçue précisément pour ce problème. Elle offre aux navigateurs un canal de communication à faible latence sur HTTP/3 qui prend en charge à la fois les flux fiables et les datagrammes non fiables — sans le blocage en tête de file (head-of-line blocking) inhérent aux transports basés sur TCP.

Ce que l’API WebTransport fait réellement

WebTransport établit une connexion à un serveur HTTP/3 et expose deux primitives de communication distinctes :

• Datagrammes — paquets non fiables, non ordonnés, à faible surcharge. Pensez UDP, mais avec chiffrement et contrôle de congestion intégrés.
• Flux (Streams) — canaux de données fiables et ordonnés. Plusieurs flux peuvent s’exécuter en parallèle sur une seule connexion sans se bloquer mutuellement.

La différence architecturale clé par rapport aux WebSockets est que WebTransport fonctionne sur QUIC, un protocole de transport basé sur UDP. QUIC gère chaque flux indépendamment, de sorte qu’un flux bloqué ne retarde pas les autres. Les WebSockets, construits sur TCP, n’ont pas une telle isolation — un message lent bloque l’ensemble de la connexion.

Flux et datagrammes WebTransport : sémantique de livraison

Comprendre les garanties de livraison est essentiel avant de choisir quelle primitive utiliser.

Les datagrammes peuvent être perdus ou arriver dans le désordre. Leur taille est limitée par le MTU du chemin. Utilisez-les lorsque la fraîcheur compte plus que l’exhaustivité — saisies de jeu, lectures de capteurs, positions de curseur.

Les flux garantissent une livraison ordonnée et fiable au sein d’un flux donné. Vous pouvez ouvrir des flux unidirectionnels (client vers serveur ou serveur vers client) ou bidirectionnels. Important : l’ordre n’est garanti que au sein d’un seul flux, pas entre plusieurs flux.

const transport = new WebTransport("https://example.com:4999/game")
await transport.ready

// Envoyer un datagramme à faible latence
const writer = transport.datagrams.writable.getWriter()
await writer.write(new Uint8Array([1, 2, 3]))

// Ouvrir un flux bidirectionnel fiable
const stream = await transport.createBidirectionalStream()
const streamWriter = stream.writable.getWriter()
await streamWriter.write(new Uint8Array([4, 5, 6]))

WebTransport vs WebSockets : quand utiliser chacun

Il ne s’agit pas d’une histoire de remplacement — c’est une question d’adéquation.

Les WebSockets restent le bon outil lorsque vous avez besoin d’un flux de messages fiable unique et que la compatibilité large importe. WebTransport trouve sa place lorsque votre application bénéficie réellement du multiplexage ou peut tolérer une livraison partielle.

Les canaux de données WebRTC offrent des capacités similaires mais nécessitent une négociation ICE, des serveurs STUN/TURN et une surcharge de configuration importante. WebTransport est plus simple pour les scénarios client-serveur et fonctionne à l’intérieur des Web Workers.

Support navigateur et exigences d’infrastructure

WebTransport nécessite un contexte sécurisé (HTTPS) et un serveur compatible HTTP/3. Il est bien pris en charge dans les navigateurs basés sur Chromium (Chrome, Edge) et a gagné le support de Firefox. Le support Safari est arrivé plus récemment. Il n’est pas encore considéré comme universellement baseline, donc la détection de fonctionnalité est essentielle. Les détails de support actuels peuvent être vérifiés sur webstatus.dev.

if ("WebTransport" in window) {
  // Utiliser WebTransport
} else {
  // Revenir aux WebSocket
}

Pour le développement local, webtransport.day fournit un serveur d’écho maintenu par la communauté contre lequel vous pouvez tester sans déployer votre propre infrastructure HTTP/3.

Conclusion

WebTransport ne remplace pas les WebSockets — il étend ce qui est possible dans le navigateur. La vraie valeur est architecturale : vous pouvez maintenant envoyer des données non fiables et sensibles au temps aux côtés de messages de contrôle fiables sur une seule connexion, sans que l’un n’affecte l’autre. Pour les applications temps réel où la latence et le débit comptent tous les deux, c’est une capacité significative à avoir à disposition.

FAQ

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.