Présentation

Avec la stack MISV6 basée sur Debian 13 (Trixie) arrive une version de haproxy embarquant une pile SSL particulièrement performante développée par Amazon (AWS-LC), l’utilisation de l’implémentation TLS du kernel (KTLS), mais surtout l’arrivée du protocole HTTP/3 sur QUIC, protocole star au cœur de cet article.

Note : dans l’article qui suit, HTTP/3 fera par défaut référence à HTTP/3 sur QUIC, nous utiliserons donc uniquement le terme HTTP/3, sauf quand c’est QUIC est spécifié explicitement.

HTTP/3

Paraphrasons Cloudflare qui est la société qui en parle le mieux.

« HTTP/3 est la dernière version majeure de HTTP. Les navigateurs et les serveurs web peuvent l’utiliser pour améliorer considérablement l’expérience utilisateur, notamment en ce qui concerne les performances, la fiabilité et la sécurité. La négociation des versions HTTP s’effectue de manière fluide, sans qu’aucune modification de code du site web ne soit nécessaire. »

sources https://www.cloudflare.com/fr-fr/learning/performance/what-is-http3/

Caractéristiques :

• protocoles UDP et QUIC pour plus de rapidité et de linéarité ;
• établissement de la connexion direct et donc simplifié (établissement de la connexion et du handshake SSL simultanée : 0-RTT, voir plus bas) ;
• « mobilité » des connexions ex passage Wifi/4G/5G sans coupure avec le CID (voir plus bas) ;
• chiffrement obligatoire.

Ressources externes :

• https://http3-explained.haxx.se/
• https://www.fasterize.com/fr/protocole-http3-changements-http1-http2/
• tester le support HTTP/3 d’un site : https://http3check.net/

CID VS adresses IP / Ports

Le Connection ID (CID) est un identifiant unique utilisé par QUIC pour identifier une connexion, remplaçant le tuple traditionnel TCP (adresse IP source, port source, adresse IP destination, port destination).

Les changements d’IP/port n’affectent pas la connexion.

1. Client (WiFi) : IP 192.168.1.10, CID = ABC123
   ↓ Connexion établie avec CID = ABC123
   
2. Client change de réseau (WiFi → 4G)
   Nouvelle IP : 10.20.30.40
   
3. Client envoie un paquet avec :
   - Nouvelle IP source : 10.20.30.40
   - Même CID : ABC123
   
4. Serveur reconnaît le CID = ABC123
   → Continue la même connexion sans interruption

Exemple aimablement fourni par ClaudeAI !

La pile protocolaire

┌─────────────────────────────┐
│       HTTP/3                │  ← Couche Application (Layer 7)
│  (Sémantique HTTP)          │
├─────────────────────────────┤
│       QUIC                  │  ← Couche Transport (Layer 4)
│  (Fiabilité, multiplexage,  │
│   chiffrement, contrôle     │
│   de flux)                  │
├─────────────────────────────┤
│       UDP                   │  ← Protocole de base
└─────────────────────────────┘

Schéma aimablement fourni par ClaudeAI !

On peut voir que QUIC apporte concrètement :

• le chiffrement ;
• les « sessions » ;
• etc.

SSL

La négociation SSL classique, petit rappel.

Image : https://thenewstack.io/why-your-apps-biggest-performance-bottleneck-might-be-ssl-tls/

Beaucoup d’aller/retour, vous en conviendrez !

Maintenant comparons la handshake (poignée de mains) classique avec le 0-RTT de QUIC

Image : https://www.cdnetworks.com

Où se positionnent HTTP/3 et QUIC ?

Image : https://www.haproxy.com/blog/state-of-ssl-stacks

La bibliothèque kernel KTLS

Historiquement, TLS était géré entièrement en espace utilisateur (par des bibliothèques comme OpenSSL). Avec KTLS, une fois la négociation TLS établie en espace utilisateur, les opérations de chiffrement/déchiffrement sont transférées au noyau.

Principaux avantages de KTLS :

• des performances améliorées avec une réduction des copies de données entre espace utilisateur et noyau ;
• une intégration avec sendfile() qui permet d’envoyer des fichiers chiffrés directement sans passer par l’espace utilisateur ;
• l’offload matériel qui permet l’accélération cryptographique matérielle directement depuis le noyau ;
• une réduction de la latence avec la réduction des changements de contexte entre noyau et espace utilisateur.

La version de Haproxy déployée utilise pleinement KTLS.

La bibliothèque SSL AWS-LC 

AWS-LC est une bibliothèque SSL particulièrement performante et sécurisée, créée et maintenu par Amazon.
Elle est opensource, compatible OpenSSL et reprend le meilleur des autres piles SSL, telle que BoringSSL de Google.

Principaux avantages de AWS-LC :

• elle consomme moins de ressource à charge égale et profite des optimisations présentes sur les CPU récents de la famille x86-64 ;
• le gain en performance est significatif, il représente une augmentation de performances d’environ 50% par rapport à OpenSSL 1.1.1w et surpasse considérablement les versions OpenSSL 3.x., voir schéma çi-dessus.

Comparaisons de plusieurs piles SSL

Image : https://www.haproxy.com/blog/state-of-ssl-stacks

Foire aux questions

Mais qu’est-ce que cela change pour les clients Kokiris ?

Par exemple, les clients accédant à vos applications depuis des téléphones mobiles verront une amélioration de la vitesse de téléchargement ainsi que ceux voyageant dans un train (même Ouigo ^^).

Pour les plus pointus d’entre vous sachez que si le reverse-proxy supporte pleinement HTTP/3, dans la majorité des cas, vos backends ne dialogueront qu’en HTTP/1 ou HTTP/2.

Seuls les clients possédants un orchestrateur de conteneurs pourront voir se déployer un client compatible HTTP/3 tel que Traefik, mais gardez à l’esprit, qu’ensuite le trafic sera généralement routé en HTTP/1 vers un conteneur Nginx !

Le passage en HTTP/3 nécessite-t-il de modifier mon application ?

Bonne nouvelle, Le passage en HTTP/3 est totalement transparent pour vos applications ! Vous n’avez littéralement rien à modifier.

Je suis client Kokiris, comment puis-je en profiter de suite ?

Les nouveaux serveurs standalone, hors Plesk, seront déployés avec HTTP/3 d’activé par défaut. Si vous avez un serveur récent sur lequel HTTP/3 n’est pas activé, contactez le support.

Je suis derrière un load-balancer ou j’utilise Cloudflare

Actuellement, seuls les serveurs standalone pourront en profiter.

Pour les serveurs situés derrière un IPLB en mode TCP, il est nécessaire d’attendre, une qualification du load-balancing UDP est en cours.

Je suis client Kokiris, devrais-je payer pour en profiter ?

Non, un serveur récent ainsi que l’infogérance vous rendent gratuitement éligible à HTTP/3.

Quid de HTTP/3 sur Plesk

L’offre Plesk Kokiris (KPM) n’est pas concernée par cet article mais sachez que sur simple demande au support Kokiris, HTTP/3 over QUIC peut être activé pourvu que la version de Plesk le supporte.

Comment s’appelle l’implémentation Kokiris ?

Pourquoi pas KokiQUIC !

Je suis dans l’espace ou sur une autre planète, HTTP/3 me permettra-t-il d’accéder à mon site ?

L’impatience est un vilain défaut, patienter donc encore…

Auteur : Antonio M