WebTransport

WebTransport fonctionne sur HTTP/3 (QUIC) et fournit à la fois des flux bidirectionnels fiables et des datagrammes peu fiables – ce que ni WebSocket ni SSE ne peuvent offrir. bext prend en charge WebTransport de manière native lorsqu'il est compilé avec la fonctionnalité h3-quic.

Exigences#

WebTransport nécessite HTTP/3, ce qui signifie :

• L'indicateur de fonctionnalité h3-quic doit être activé au moment de la compilation.
• Un certificat TLS doit être configuré (QUIC est toujours crypté).
• Le port UDP (généralement 443) doit être accessible.

bext build --features h3-quic

Configuration#

[http3]
enabled = true

[webtransport]
enabled = true
max_sessions = 10000
session_idle_timeout_secs = 60

bext annonce la prise en charge de WebTransport via l'en-tête Alt-Svc sur les réponses HTTP/2 afin que les navigateurs puissent découvrir et mettre à niveau automatiquement.

API#

L'API WebTransport reflète WebSocket mais ajoute des méthodes de datagramme :

use bext::webtransport::{WebTransportSession, Datagram};

async fn handle_session(session: WebTransportSession) {
    // Open a reliable bidirectional stream
    let (mut send, mut recv) = session.open_bi().await?;
    send.write_all(b"hello from server").await?;

    // Accept streams opened by the client
    while let Some((mut send, mut recv)) = session.accept_bi().await? {
        tokio::spawn(async move {
            let data = recv.read_to_end(1024 * 64).await?;
            send.write_all(&process(data)).await?;
            Ok::<_, anyhow::Error>(())
        });
    }
}

Flux fiables#

Les flux sont ordonnés et fiables (comme TCP). Ouvrez-en autant que vous le souhaitez — QUIC les multiplexe sans blocage en tête de ligne :

Datagrammes peu fiables#

Les datagrammes ne sont pas ordonnés et peu fiables (comme UDP). Ils sont idéaux pour les données où la fraîcheur compte plus que la livraison :

// Send a datagram
session.send_datagram(b"player_pos:x=10,y=20").await?;

// Receive datagrams
while let Some(dgram) = session.recv_datagram().await? {
    handle_position_update(&dgram);
}

Conformément à la RFC 9297, la taille maximale de la charge utile du datagramme est par défaut 1 200 octets. Les datagrammes plus grands sont supprimés. Vous pouvez interroger le maximum négocié au moment de l'exécution :

let max_size = session.max_datagram_size(); // typically 1200

Cas d'utilisation#

WebTransport brille là où WebSocket échoue :

• Jeux en temps réel — datagrammes peu fiables pour les mises à jour de position, fiables flux pour le chat et l’état du jeu.
• Édition collaborative — Opérations CRDT sur flux fiables, curseur positions sur les datagrammes.
• Sortance de télémétrie — données de capteur haute fréquence lors de la chute d'un l'échantillon est meilleur que la mise en mémoire tampon.
• Médias en direct — segments audio/vidéo à faible latence avec retransmission ajouterait un retard inacceptable.

Exemple de client#

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

// Unreliable datagrams
const writer = transport.datagrams.writable.getWriter();
await writer.write(new Uint8Array([1, 2, 3]));

// Reliable bidirectional stream
const stream = await transport.createBidirectionalStream();
const streamWriter = stream.writable.getWriter();
await streamWriter.write(new TextEncoder().encode("hello"));

Cycle de vie des sessions#

1. Le client envoie une requête CONNECT étendue via HTTP/3.
2. bext valide le pseudo-en-tête :protocol et achemine vers le gestionnaire.
3. Le gestionnaire reçoit un WebTransportSession.
4. Lorsque l'un des côtés se ferme ou que le délai d'inactivité expire, la session se termine.
5. bext émet webtransport_sessions_active et Métriques webtransport_datagrams_sent_total.

Comparaison avec WebSocket#

Indicateur de fonctionnalité#

WebTransport nécessite la fonctionnalité h3-quic :

bext build --features h3-quic

Sans cet indicateur, la configuration WebTransport est ignorée.

En rapport#

• HTTP/3 et QUIC — permettant le transport QUIC, dont dépend WebTransport
• WebSockets — Alternative basée sur TCP avec une compatibilité réseau plus large
• Événements envoyés par le serveur — alternative unidirectionnelle légère pour les cas d'utilisation push uniquement
• TLS et HTTPS — configuration de certificat requise pour QUIC/WebTransport
• Construire des drapeaux — liste complète des indicateurs de fonctionnalités au moment de la compilation

Links#

• Spécification W3C WebTransport — la norme vivante du W3C
• MDN : API WebTransport — Tableaux de référence de l'API du navigateur et de compatibilité du navigateur