La performance en streaming n'est pas seulement une préoccupation pour les lecteurs vidéo. Les artefacts logiciels, les poids de modèles, les sauvegardes, les bibliothèques audio et les exports API volumineux dépendent tous des mêmes principes fondamentaux : déplacer les octets rapidement, préserver la charge utile exacte, respecter la contre-pression et arrêter proprement lorsqu'un client se déconnecte.
Webship considère ces exigences comme un seul problème de transport à travers HTTP/1.1, HTTP/2, HTTP/3, la livraison directe de fichiers, le proxy inverse et WebTransport. Le chemin rapide n'est utile que lorsqu'il préserve le cadrage, l'annulation, les en-têtes de fin, l'inspection de sécurité et la mémoire limitée.
Capacité de streaming mesurée de 100 Mo
La capacité de Webship 1.3.1 sur Debian a mesuré le débit médian de la charge utile avec un dispositif fixe de 100 Mo. Chaque échantillon accepté nécessitait une réponse de corps exacte de 99 943 778 octets et zéro erreur côté client, protocole, proxy, défaut de page majeur et perte de paquet HTTP/3.
| mode Webship | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Livraison directe de fichiers | 4,194,8 Mio/s | 3,574,3 Mio/s | 2,096,9 Mio/s | | Proxy inverse avec terminaison TLS | 3 585,7 Mio/s | 3 355,0 Mio/s | 1 938,6 Mio/s | | Proxy inverse avec passage TLS | 2 783,2 Mio/s | 2 135,0 Mio/s | 1 748,5 Mio/s |
Dans la comparaison enregistrée, Webship a produit la médiane directe et terminée TLS la plus élevée pour chaque protocole mesuré. La matrice complète inclut Nginx, Lighttpd, Caddy, HAProxy, Envoy, Pingora et Bun sur la [page de référence](/benchmarks).
Ces chiffres mesurent la capacité sur l'hôte de référence. Ils ne constituent pas une promesse pour un chemin internet arbitraire. La latence du stockage, la bande passante réseau, le temps aller-retour, la perte de paquets, la politique TLS, la concurrence et le comportement de l'origine déterminent encore la vitesse réelle de livraison.
Un binaire, trois stratégies de transport
Une grande réponse ne bénéficie pas de la même politique qu'un petit document HTML. Webship maintient le chemin de requête ordinaire de manière conservatrice et ne promeut qu'une réponse en masse éprouvée.
HTTP/1.1 : moins de transitions autour du fichier
Sous Linux, Webship conserve l'en-tête de réponse et le contenu du fichier à l'intérieur d'un seul intervalle TCP cork en mode meilleur effort. Une fois qu'une grande réponse TLS est éligible au chemin de données en vrac, la livraison directe du fichier peut passer des enregistrements Rustls au TLS noyau unidirectionnel audité et utiliser sendfile sans copier le contenu via un tampon d'application.
La connexion commence toujours dans le TLS côté utilisateur. De petites réponses y restent. Webship demande la transition kTLS seulement après qu'un corps de réponse d'au moins 1 Mio prouve que la connexion transporte des données en masse.
HTTP/2 : regroupement sans rompre le contrôle de flux
Le multiplexage HTTP/2 rend le buffering incontrôlé coûteux. Webship regroupe les écritures tout en respectant les limites de contrôle de flux des flux et des connexions. Pour le streaming à haute simultanéité, un tampon d'écriture TLS de 128 KiB peut contenir deux trames DATA de 64 KiB, tandis que le budget d'envoi de la connexion reste explicite et limité.
Un cadre de corps en amont déjà prêt peut être préchargé sans contourner le cadrage Hyper, les remorques, l'annulation, l'inspection ou la contre-pression. Cela réduit un tour de planificateur évitable tout en respectant le contrat du protocole.
HTTP/3 : régulation QUIC au lieu de kTLS
HTTP/3 n'utilise jamais le chemin TCP kTLS. Webship applique l'ordonnancement QUIC conscient du transport, la datagramme limitée en paquetisation, DPLPMTUD, et le micro-batching piloté par minuteur par réacteur. Les grandes réponses HTTP/3 et les sessions WebTransport acceptées peuvent sélectionner BBR sans changer la politique CUBIC utilisée par le trafic ordinaire.
La qualification de stabilité HTTP/3 ciblée a utilisé sept échantillons acceptés. Le streaming terminé TLS a fourni une moyenne médiane de 1 938,6 Mio/s avec un coefficient de variation de 2,12 %. Le passage TLS a fourni 1 748,5 Mio/s avec un coefficient de variation de 1,65 %. Les deux séries n'ont présenté aucune erreur d'intégrité du corps, de client, de protocole ou de perte de paquets.
Livraison directe ou proxy inversé ?
Utilisez la livraison directe lorsque Webship possède l'arborescence de fichiers déployée. Cela supprime le saut d'origine et permet le chemin de fichier statique le plus efficace.
Un site multi-protocoles minimal ressemble à ceci :
listen = "0.0.0.0:443"
workers = 8
root = "/srv/media"
[[sites]]
domain = "media.example.com"
root = "/srv/media"
[sites.protocols]
h1 = true
h2 = true
h3 = true
[sites.tls]
cert = "/etc/webship/media-cert.pem"
key = "/etc/webship/media-key.pem"Utilisez la terminaison TLS par reverse-proxy lorsque Webship doit router par chemin, appliquer des vérifications WAF ou API Shield, faire respecter les limites de corps, ajouter des en-têtes de transfert ou observer les champs HTTP :
[reverse_proxy]
enabled = true
tls_termination = true
[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true
[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"
[[reverse_proxy.routes]]
domain = "media.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:8080"]Définir tls_termination = false lorsque l'origine doit conserver le texte en clair de l'application et les clés de session actives. Le passage direct ne peut pas inspecter les champs HTTP chiffrés. Le passage TCP redirige donc par le SNI de ClientHello, tandis que le passage HTTP/3 nécessite une origine UDP partagée.
Ajuster la diffusion en continu en masse explicitement
Pour le streaming TLS HTTP/2 à haute concurrence, Webship documente ces paramètres liés aux processus :
[runtime.settings]
h2_tls_write_buffer_bytes = "131072"
proxy_h2_tls_max_send_buffer_bytes = "131072"
proxy_h2_tls_connection_send_buffer_bytes = "33554432"Le budget de connexion ci-dessus fournit 128 Ko de crédit pour 256 flux actifs. Considérez-le comme une décision de capacité, et non comme un défaut universel. Mesurez la mémoire, la latence et le débit avec votre concurrence prévue avant de l’augmenter.
Sur Linux, chargez les modules TLS et BBR du noyau et permettez au compte de service Webship de sélectionner BBR. Webship échoue avant la liaison lorsque sa capacité noyau requise n’est pas disponible, donc un déploiement ne peut pas revendiquer silencieusement le chemin optimisé tout en fonctionnant sans celui-ci. Les autres systèmes d’exploitation conservent les chemins portables Rustls et de contrôle de congestion documentés pour leur plateforme.
WebTransport est une forme de streaming différente
WebTransport combine des flux fiables et des datagrammes non fiables sur une session sécurisée. Il n'utilise pas TCP kTLS. Le point de terminaison de diagnostic limité de Webship valide les origines et applique des limites de session, de flux, de capsule, de datagramme, d'octet et de temps d'inactivité.
Lors de l'exécution de capacité 1.3.1, WebTransport direct a atteint 1 018,1 Mio/s pour les flux fiables et 1 038,9 Mio/s pour les datagrammes. Le passage TLS a atteint respectivement 548,6 Mio/s et 629,7 Mio/s. Les deux modes ont réussi les cinq échantillons avec zéro échantillon rejeté, zéro datagramme perdu et zéro faute majeure côté client.
Privilégiez HTTP/3 pour les nouveaux clients WebTransport. Le chemin HTTP/2 existe pour la compatibilité avec les anciens réglages de brouillon expirés.
Ce qu'il faut vérifier avant le trafic de production
- Testez les tailles exactes des médias ou des artefacts que vous servirez, pas seulement une petite réponse synthétique.
- Vérifiez la longueur de la réponse et le condensé du contenu côté client.
- Annulation d'exercice, demandes de plage, lecteurs lents et comportement de demi-fermeture d'origine.
- Mesurez le débit soutenu ainsi que le CPU, la mémoire, les erreurs de socket, les retransmissions et la latence de pointe.
- Validez séparément les modes direct, terminé TLS et passage ; ils ont des limites de sécurité et de routage différentes.
- Garder l'instrumentation désactivée pour le trafic de production normal, puis activer délibérément les diagnostics limités lors de l'investigation.
- Vérifiez à nouveau le kTLS Linux et le pré-vol BBR après des modifications du noyau, du conteneur ou du sandbox systemd.
Le streaming est rapide lorsque tout le parcours coopère. La conception de Webship maintient les optimisations des données volumineuses spécifiques au protocole tout en préservant un modèle opérationnel et un seul niveau de fiabilité.
Lisez la [documentation complète de Webship 1.3.1](/docs/1.3.1), examinez la [méthodologie du benchmark et la matrice des concurrents](/benchmarks), ou téléchargez une version signée depuis [Téléchargements](/downloads).