Webship 1.3.1 transforme deux cycles de publication de profilage du transport, de durcissement du protocole et de travail sur la stabilité en gains de capacité mesurables. Sur le même hôte de référence Debian, huit des dix charges de travail comparables de requêtes directes et via proxy inverse sont plus rapides que Webship 1.2.0.
Les plus grands changements se produisent dans HTTP/2 : les requêtes directes h2c passent de 1 003 468 à 1 346 548 par seconde, tandis que le TLS direct HTTP/2 passe de 884 857 à 1 120 872 requêtes par seconde. La capacité de reverse-proxy s'améliore également sur tous les protocoles mesurés.
Webship 1.3.1 comparé à 1.2.0
Le tableau ci-dessous compare la capacité médiane des requêtes locales au serveur. Plus c'est élevé, mieux c'est.
| Charge de travail directe | Webship 1.2.0 | Webship 1.3.1 | Changement | | --- | ---: | ---: | ---: | | HTTP/1.1 | 414 195 RPS | 414 060 RPS | -0,03 % | | HTTP/1.1 TLS | 303 788 RPS | 312 439 RPS | +2,85 % | | h2c | 1 003 468 RPS | 1 346 548 RPS | +34,19% | | HTTP/2 TLS | 884 857 RPS | 1 120 872 RPS | +26,67 % | | HTTP/3 TLS | 409 514 RPS | 400 187 RPS | -2,28 % |
| Proxy inverse avec terminaison TLS | Webship 1.2.0 | Webship 1.3.1 | Changement | | --- | ---: | ---: | ---: | | HTTP/1.1 | 165 160 RPS | 190 102 RPS | +15,10 % | | HTTP/1.1 TLS | 118 681 RPS | 123 344 RPS | +3,93 % | | h2c | 122,371 RPS | 135,499 RPS | +10,73% | | HTTP/2 TLS | 113 919 RPS | 124 957 RPS | +9,69 % | | HTTP/3 TLS | 126 407 RPS | 131 529 RPS | +4,05 % |
Direct HTTP/1.1 est pratiquement inchangé. Direct HTTP/3 TLS est inférieur de 2,28 % à la médiane 1.2.0, donc nous ne présentons pas chaque cellule comme un gain. La version apporte ses améliorations les plus nettes dans HTTP/2 et la capacité du proxy inverse tout en préservant une politique stricte d’acceptation zéro erreur.
D'où viennent les gains
Webship 1.3.1 réduit le travail sur les chemins les plus chauds au lieu d'affaiblir le protocole ou les contrôles de sécurité.
- Les répliques locales de connexion permettent aux réponses HTTP/1 et HTTP/2 répétées d'éviter la contention de compteur de références de tampon d'octets à l'échelle du processus.
- Les blocs HPACK partagés incluent désormais des champs HTTP/2 stables pour la connexion, réduisant l'encodage répété des en-têtes.
- HTTP/2 vide la sortie en file d'attente avant de tenter une autre lecture de socket et utilise davantage de suivi de flux sans verrou, détenu par la connexion.
- Les paquets à en-tête court établis par HTTP/3 évitent une copie à la réception, tandis que les paquets de poignée de main conservent un tampon sécurisé pour la propriété.
- Le passage TLS réutilise les tampons de relais locaux au niveau du travailleur et un minuteur d'inactivité au lieu de les reconstruire à chaque cycle de relais.
- Les chemins de transport de publication ne portent plus les sites d'appel de traçage lorsque l'instrumentation est désactivée.
Ces changements conservent l'encadrement, les bandeaux, l'annulation, l'inspection et la contre-pression. Ils réduisent les coûts de coordination et d'allocation sans transformer le travail de correction en un chemin rapide optionnel.
La stabilité fait partie de la capacité
Une médiane rapide n'est utile que lorsque l'exécution est correcte et répétable. Chaque échantillon de capacité de requête accepté nécessitait zéro erreur HTTP, erreur de socket, échec de protocole, échec généré par le proxy, faute majeure de page et perte de paquets HTTP/3.
La version permet également aux auditeurs de rester actifs grâce à la pression transitoire sur les descripteurs, la mémoire et le réseau ; limite les attentes de collapse du cache selon la date limite de la requête ; préserve les réponses TLS en passage à travers après une demi-fermeture ; et corrige l'admission, la comptabilité, l'isolation des paniques et l'ordre de rejet de WebTransport.
La qualification TLS inversée focalisée HTTP/2 a produit une médiane de 124 957 RPS avec un écart de 0,89 % et un coefficient de variation de 0,33 %. La requalification terminée et le streaming en pass-through HTTP/3 ont chacun passé sept échantillons acceptés avec des corps de 99 943 778 octets exacts et sans erreurs côté client, protocole ou perte de paquets.
WebTransport et streaming de 100 Mo
Webship 1.3.1 qualifie également les WebTransport locaux au serveur et les chemins de diffusion de fichiers volumineux :
- Direct WebTransport : 1 018,1 Mio/s pour les flux fiables et 1 038,9 Mio/s pour les datagrammes.
- WebTransport via le passage TLS : 548,6 Mio/s pour les flux fiables et 629,7 Mio/s pour les datagrammes.
- Streaming direct de 100 Mo : 4 194,8 Mio/s sur HTTP/1.1 TLS, 3 574,3 Mio/s sur HTTP/2 TLS, et 2 096,9 Mio/s sur HTTP/3 TLS.
- Streaming avec proxy inverse et terminaison TLS : 3 585,7 MiB/s, 3 355,0 MiB/s et 1 938,6 MiB/s respectivement.
Une version construite pour un fonctionnement mesurable
Webship 1.3.1 est disponible en tant que binaires signés pour les cibles Linux, Windows, macOS et OpenHarmony prises en charge. La version Linux x86_64 inclut son profil PGO compatible et les métadonnées de provenance.
Lisez la [méthodologie de référence et comparaison actuelle](/benchmarks) complète, consultez la [documentation 1.3.1](/docs/1.3.1), ou obtenez la version signée depuis les [Téléchargements](/downloads).
Sources et méthode de contenu
La comparaison utilise la matrice Debian Webship 1.2.0 enregistrée le 4 septembre 2026 et le benchmark de capacité Debian unifié Webship 1.3.1 enregistré le 11 septembre 2026. Les pourcentages sont calculés à partir des médianes enregistrées.