En octobre 2020, Chrome a rendu HTTP/3 par défaut. HTTP/3 (RFC 9114) s’exécute sur IETF QUIC (RFC9000). L’activation par défaut de HTTP/3 dans Chrome a amélioré les performances par rapport à HTTP/1, HTTP/2 et même Google QUIC. Parmi les avantages, on peut citer la réduction de la latence dans les recherches Google et un nombre réduit de remises en mémoire tampon sur YouTube.
Mais l’optimisation des performances ne s’est pas arrêtée là. Des avancées récentes incluent l’implémentation de la trame ORIGIN de HTTP/3 (RFC 9412) et de l’adresse préférée du serveur (RFC 9000 Section 9.6). La première améliore le regroupement des connexions, tandis que la seconde réduit le temps de réponse d’une connexion (RTT). Ces deux fonctionnalités ont été activées par défaut dans M131, sorti en version stable le 11 novembre.
**Trame ORIGIN**
Lorsqu’une connexion est établie pour un nom d’hôte spécifique, le certificat du serveur contient généralement de nombreux autres noms d’hôtes sur lesquels le serveur fait autorité. Toutefois, un client ne peut pas envoyer immédiatement des requêtes pour ces autres noms d’hôtes sur cette connexion sans d’abord effectuer une recherche DNS pour l’autre nom d’hôte et vérifier que l’adresse IP de la connexion correspond à l’adresse résolue. Cette résolution DNS supplémentaire introduit une latence et réduit considérablement la probabilité d’un regroupement de connexions en raison de potentielles erreurs d’IP. Les mesures de Chrome indiquent que près de 20 % des connexions HTTP/3 seraient inutiles sans cette erreur.
Créer une nouvelle connexion, même avec QUIC 0-RTT, est coûteux en termes de latence, de mémoire et d’utilisation du processeur. En effet :
* La résolution DNS ajoute de la latence sauf si elle est mise en cache localement dans le cache DNS de Chrome.
* Le client et le serveur doivent envoyer plusieurs paquets pour terminer un handshake QUIC.
* Le protocole TLS nécessite une cryptographie asymétrique gourmande en processeur aux deux extrémités.
* Le contrôleur de congestion démarre dans son état par défaut, ce qui peut entraîner une sous-émission ou une surémission.
* 0-RTT peut échouer.
* Les requêtes non sécurisées ne sont pas envoyées via 0-RTT.
* Plus de connexions consomment plus de mémoire.
De plus, des fonctionnalités telles que les priorités HTTP (RFC 9218) ne sont efficaces que s’il y a plusieurs réponses simultanées à envoyer.
La trame ORIGIN de HTTP/3 (RFC 9412) permet à un serveur d’indiquer quels domaines il souhaite regrouper sur une connexion. De plus, une fois la trame reçue, cela indique que les autres domaines ne doivent pas être regroupés sur cette connexion, même s’ils figurent dans le certificat.
**Adresse préférée du serveur**
Dans certains cas, l’adresse initiale du serveur auquel le client se connecte n’est pas le trajet le plus efficace. Elle peut se trouver derrière un équilibreur de charge L4, et se connecter directement pourrait accroître la stabilité. En particulier lors de l’utilisation d’Anycast, il est possible que le serveur soit distant de l’endroit où le trafic entre dans le réseau, créant un chemin à 3 branches qui augmente le temps de réponse.
Une fois le handshake confirmé, l’adresse préférée du serveur permet à un serveur d’indiquer qu’il souhaite que le client migre vers une autre adresse IP du serveur. Bien qu’une connexion QUIC ne soit pas liée à un seul quadruple comme TCP, il s’agit du seul type de migration dans RFC9000 où le serveur peut modifier son adresse.
Jusqu’à présent, seul Media CDN de Google a largement activé la publicité d’une adresse alternative, mais nous nous attendons à ce que davantage de serveurs l’adoptent prochainement. Les tests ont montré que cette migration est réussie plus de 99 % du temps dans Chrome et réduit le RTT moyen de 40 à 80 %.
**Conclusion**
Les optimisations apportées à QUIC dans Chrome ont considérablement amélioré les performances globales. Des fonctionnalités telles que la trame ORIGIN et l’adresse préférée du serveur réduisent la latence, augmentent la stabilité et améliorent le regroupement des connexions. Alors que QUIC continue d’évoluer, nous pouvons nous attendre à des améliorations encore plus grandes à l’avenir.
**Mots-clés :** HTTP/3, QUIC, Chrome, Optimisation, Performances