HTTP/3 : Options de déploiement pratiques (Partie 3)

Bonjour et bienvenue dans le dernier épisode de cette série en trois parties sur les nouveaux protocoles HTTP/3 et QUIC ! Si après les deux parties précédentes — l'historique et les concepts de base de HTTP/3 et les fonctionnalités de performance de HTTP/3 — vous êtes convaincu que commencer à utiliser les nouveaux protocoles est une bonne idée (et vous devriez l'être !), alors cette dernière partie comprend tous vous devez savoir pour commencer!

Tout d'abord, nous discuterons des modifications que vous devez apporter à vos pages et ressources pour utiliser de manière optimale les nouveaux protocoles (c'est la partie la plus facile). Ensuite, nous verrons comment configurer les serveurs et les clients (c'est la partie la plus difficile, sauf si vous utilisez un réseau de diffusion de contenu (CDN)). Enfin, nous verrons quels outils vous pouvez utiliser pour évaluer l'impact des nouveaux protocoles sur les performances (c'est la partie presque impossible, du moins pour l'instant).

Modifications des pages et des ressources

Commençons par une bonne nouvelle : si vous êtes déjà sur HTTP/2, vous n'aurez probablement rien à modifier dans vos pages ou vos ressources lors du passage à HTTP/3 ! . En effet, comme nous l'avons expliqué dans les parties 1 et 2, HTTP/3 ressemble plus à HTTP/2-over-QUIC, et les fonctionnalités de haut niveau des deux versions sont restées les mêmes. Ainsi, toute modification ou optimisation effectuée pour HTTP/2 fonctionnera toujours pour HTTP/3 et vice versa.

Cependant, si vous êtes toujours sur HTTP/1.1, ou si vous avez oublié votre transition vers HTTP/2, ou si vous n'avez jamais modifié les choses pour HTTP/2, alors vous vous demandez peut-être quels étaient ces changements et pourquoi ils étaient nécessaires. Cependant, vous auriez du mal, même aujourd'hui, à trouver un bon article qui détaille les meilleures pratiques nuancées . En effet, comme je l'ai indiqué dans l'introduction de la partie 1, une grande partie du contenu initial de HTTP/2 était trop optimiste quant à son bon fonctionnement dans la pratique, et certains d'entre eux, très franchement, comportaient des erreurs majeures et de mauvais conseils. Malheureusement, une grande partie de cette désinformation persiste aujourd'hui. C'est l'une de mes principales motivations en écrivant cette série sur HTTP/3, pour éviter que cela ne se reproduise.

La meilleure source nuancée tout-en-un pour HTTP/2 que je puisse recommander à l'heure actuelle est le livre HTTP/2 in Action de Barry Pollard. Cependant, comme il s'agit d'une ressource payante et que je ne veux pas que vous deviniez ici, j'ai répertorié ci-dessous quelques-uns des principaux points, ainsi que leur lien avec HTTP/3 :

1. Connexion unique

La plus grande différence entre HTTP/1.1 et HTTP/2 était le passage de 6 à 30 connexions TCP parallèles à une seule connexion TCP sous-jacente. Nous avons discuté un peu dans la partie 2 de la façon dont une seule connexion peut toujours être aussi rapide que plusieurs connexions, en raison de la façon dont le contrôle de la congestion peut entraîner une perte de paquets plus importante ou plus précoce avec plus de connexions (ce qui annule les avantages de leur démarrage plus rapide agrégé). HTTP/3 poursuit cette approche, mais passe "juste" d'une connexion TCP à une connexion QUIC. Cette différence en elle-même ne fait pas grand-chose (elle réduit principalement la surcharge côté serveur), mais elle conduit à la plupart des points suivants.

2. Partage de serveur et coalescence de connexion

Le passage à la configuration de connexion unique était assez difficile dans la pratique car de nombreuses pages étaient partagées sur différents noms d'hôte et même des serveurs (comme img1.example.com et img2.example.com ). En effet, les navigateurs n'ouvraient que jusqu'à six connexions pour chaque nom d'hôte individuel, donc en avoir plusieurs permettait plus de connexions ! Sans modification de cette configuration HTTP/1.1, HTTP/2 ouvrirait toujours plusieurs connexions, ce qui réduirait le fonctionnement réel d'autres fonctionnalités, telles que la hiérarchisation (voir ci-dessous).

En tant que tel, la recommandation initiale était d'annuler le partage de serveur et de consolider autant que possible les ressources sur un seul serveur. HTTP/2 a même fourni une fonctionnalité pour faciliter la transition depuis une configuration HTTP/1.1, appelée fusion de connexion. En gros, si deux noms d'hôte correspondent à la même adresse IP de serveur (à l'aide de DNS) et utilisent un certificat TLS similaire, le navigateur peut réutiliser une seule connexion même entre les deux noms d'hôte .

En pratique, la fusion des connexions peut être difficile à réaliser, par exemple en raison de plusieurs problèmes de sécurité subtils impliquant CORS. Même si vous le configurez correctement, vous pouvez facilement vous retrouver avec deux connexions distinctes. Le truc, c'est que ce n'est pas toujours mauvais . Premièrement, en raison d'une hiérarchisation et d'un multiplexage mal implémentés (voir ci-dessous), la connexion unique pourrait facilement être plus lente que l'utilisation de deux ou plus. Deuxièmement, l'utilisation d'un trop grand nombre de connexions peut entraîner une perte précoce de paquets en raison de contrôleurs de congestion concurrents. Cependant, n'en utiliser que quelques-uns (mais toujours plus d'un) pourrait bien équilibrer la croissance de la congestion avec de meilleures performances, en particulier sur les réseaux à haut débit. Pour ces raisons, je pense qu'un peu de partitionnement est toujours une bonne idée (disons, deux à quatre connexions), même avec HTTP/2. En fait, je pense que la plupart des configurations HTTP/2 modernes fonctionnent aussi bien car elles ont encore quelques connexions supplémentaires ou des charges tierces dans leur chemin critique.

3. Regroupement de ressources et inlining

Dans HTTP/1.1, vous ne pouviez avoir qu'une seule ressource active par connexion, ce qui entraînait un blocage de tête de ligne (HoL) au niveau HTTP. Étant donné que le nombre de connexions était plafonné à un maigre 6 à 30, le regroupement des ressources (où des sous-ressources plus petites sont combinées en une seule ressource plus grande) était une pratique exemplaire de longue date. Nous le voyons encore aujourd'hui dans les bundlers tels que Webpack. De même, les ressources étaient souvent intégrées dans d'autres ressources (par exemple, le CSS critique était intégré dans le HTML).

Avec HTTP/2, cependant, la connexion unique multiplexe les ressources, de sorte que vous pouvez avoir beaucoup plus de demandes de fichiers en attente (en d'autres termes, une seule demande n'occupe plus l'une de vos précieuses connexions). Cela a été interprété à l'origine comme suit : " Nous n'avons plus besoin de regrouper ou d'intégrer nos ressources pour HTTP/2 ". Cette approche a été présentée comme étant meilleure pour la mise en cache fine, car chaque sous-ressource pouvait être mise en cache individuellement et l'ensemble complet n'avait pas besoin d'être retéléchargé si l'un d'entre eux changeait. C'est vrai, mais seulement dans une mesure relativement limitée.

Par exemple, vous pouvez réduire l'efficacité de la compression, car cela fonctionne mieux avec plus de données. De plus, chaque demande ou fichier supplémentaire a une surcharge inhérente car il doit être géré par le navigateur et le serveur. Ces coûts peuvent s'additionner pour, par exemple, des centaines de petits fichiers par rapport à quelques gros. Lors de nos premiers tests, j'ai trouvé des rendements sérieusement décroissants à environ 40 fichiers. Bien que ces chiffres soient probablement un peu plus élevés maintenant, les demandes de fichiers ne sont toujours pas aussi bon marché en HTTP/2 que prévu à l'origine . Enfin, ne pas intégrer les ressources a un coût de latence supplémentaire car le fichier doit être demandé. Ceci, combiné aux problèmes de priorisation et de poussée du serveur (voir ci-dessous), signifie que même aujourd'hui, vous feriez mieux d'intégrer certains de vos CSS critiques. Peut-être qu'un jour la proposition de Resource Bundles aidera à cela, mais pas encore.

Bien sûr, tout cela est également vrai pour HTTP/3. Pourtant, j'ai lu que des gens prétendaient que de nombreux petits fichiers seraient meilleurs que QUIC parce que plus de flux indépendants actifs simultanément signifient plus de bénéfices de la suppression du blocage HoL (comme nous l'avons vu dans la partie 2). Je pense qu'il y a peut-être du vrai là-dedans, mais, comme nous l'avons également vu dans la partie 2, il s'agit d'une question très complexe avec de nombreux paramètres mouvants. Je ne pense pas que les avantages l'emporteraient sur les autres coûts évoqués, mais des recherches supplémentaires sont nécessaires. (Une idée scandaleuse serait que chaque fichier soit exactement dimensionné pour tenir dans un seul paquet QUIC, en contournant complètement le blocage HoL. J'accepterai les redevances de toute startup qui implémente un groupe de ressources qui fait cela. ;))

4. Priorisation

Pour pouvoir télécharger plusieurs fichiers sur une seule connexion, vous devez en quelque sorte les multiplexer. Comme discuté dans la partie 2, en HTTP/2, ce multiplexage est piloté grâce à son système de priorisation. C'est pourquoi il est important d'avoir autant de ressources que possible demandées sur la même connexion également - pour pouvoir les hiérarchiser correctement entre elles ! Comme nous l'avons également vu, cependant, ce système était très complexe , ce qui le rendait souvent mal utilisé et mis en œuvre dans la pratique (voir l'image ci-dessous). Ceci, à son tour, a signifié que certaines autres recommandations pour HTTP/2 - telles que la réduction du regroupement, car les requêtes sont bon marché, et la réduction du partage de serveur, pour tirer le meilleur parti de la connexion unique (voir ci-dessus) - se sont avérées sous-performantes dans entraine toi.

Malheureusement, c'est quelque chose que vous, en tant que développeur Web moyen, ne pouvez pas faire grand-chose, car c'est principalement un problème dans les navigateurs et les serveurs eux-mêmes. Vous pouvez cependant essayer d'atténuer le problème en n'utilisant pas trop de fichiers individuels (ce qui réduira les risques de priorités concurrentes) et en utilisant toujours le partitionnement (limité). Une autre option consiste à utiliser diverses techniques influençant les priorités, telles que le chargement différé, JavaScript async et defer , et des conseils de ressources tels que preload . En interne, ceux-ci modifient principalement les priorités des ressources afin qu'elles soient envoyées plus tôt ou plus tard. Cependant, ces mécanismes peuvent (et souffrent) de bogues. De plus, ne vous attendez pas à preload un tas de ressources et à accélérer les choses : si tout est soudainement une priorité élevée, alors rien ne l'est ! Il est même très facile de retarder des ressources vraiment critiques en utilisant des choses comme preload .

Comme également expliqué dans la partie 2, HTTP/3 change fondamentalement les rouages ​​de ce système de priorisation. Nous espérons que cela signifie qu'il y aura beaucoup moins de bogues et de problèmes avec son déploiement pratique, donc au moins une partie de cela devrait être résolue. Cependant, nous ne pouvons pas encore en être sûrs, car peu de serveurs et de clients HTTP/3 implémentent pleinement ce système aujourd'hui. Néanmoins, les concepts fondamentaux de priorisation ne changeront pas . Vous ne pourrez toujours pas utiliser des techniques telles que le preload sans vraiment comprendre ce qui se passe en interne, car cela pourrait encore mal prioriser vos ressources.

5. Server Push et premier vol

La poussée du serveur permet à un serveur d'envoyer des données de réponse sans attendre au préalable une demande du client. Encore une fois, cela sonne bien en théorie et pourrait être utilisé à la place des ressources intégrées (voir ci-dessus). Cependant, comme indiqué dans la partie 2, push est très difficile à utiliser correctement en raison de problèmes de contrôle de la congestion, de mise en cache, de hiérarchisation et de mise en mémoire tampon. Dans l'ensemble, il est préférable de ne pas l'utiliser pour le chargement général de pages Web à moins que vous ne sachiez vraiment ce que vous faites, et même dans ce cas, il s'agirait probablement d'une micro-optimisation. Je pense toujours qu'il pourrait avoir une place avec les API (REST), où vous pouvez pousser les sous-ressources liées à la réponse (JSON) sur une connexion préchauffée. Cela est vrai pour HTTP/2 et HTTP/3.

Pour généraliser un peu, je pense que des remarques similaires pourraient être faites pour la reprise de session TLS et le 0-RTT, que ce soit sur TCP + TLS ou via QUIC. Comme indiqué dans la partie 2, 0-RTT est similaire au serveur push (tel qu'il est généralement utilisé) en ce sens qu'il tente d'accélérer les toutes premières étapes du chargement d'une page. Cependant, cela signifie qu'il est également limité dans ce qu'il peut réaliser à ce moment-là (encore plus dans QUIC, pour des raisons de sécurité). En tant que telle, une micro-optimisation est, encore une fois, la façon dont vous devez probablement affiner les choses à un niveau bas pour vraiment en bénéficier. Et dire que j'étais autrefois très enthousiaste à l'idée d'essayer de combiner le serveur push avec 0-RTT.

Qu'est-ce que tout cela veut dire?

Tout ce qui précède se résume à une simple règle empirique : appliquez la plupart des recommandations HTTP/2 typiques que vous trouvez en ligne, mais ne les poussez pas à l'extrême .

Voici quelques points concrets qui valent principalement pour HTTP/2 et HTTP/3 :

1. Répartissez les ressources sur environ une à trois connexions sur le chemin critique (sauf si vos utilisateurs se trouvent principalement sur des réseaux à faible bande passante), en utilisant la preconnect et dns-prefetch si nécessaire.
2. Regroupez logiquement les sous-ressources par chemin ou fonctionnalité, ou par fréquence de modification. Cinq à dix ressources JavaScript et cinq à dix ressources CSS par page devraient suffire. L'intégration de CSS critiques peut toujours être une bonne optimisation.
3. Utilisez les fonctionnalités complexes, telles que le preload , avec parcimonie.
4. Utilisez un serveur qui prend correctement en charge la hiérarchisation HTTP/2. Pour HTTP/2, je recommande H2O. Apache et NGINX sont généralement OK (bien qu'ils puissent faire mieux), tandis que Node.js est à éviter pour HTTP/2. Pour HTTP/3, les choses sont moins claires pour le moment (voir ci-dessous).
5. Assurez-vous que TLS 1.3 est activé sur votre serveur Web HTTP/2.

Comme vous pouvez le voir, bien que loin d'être simple, l'optimisation des pages pour HTTP/3 (et HTTP/2) n'est pas sorcier. Ce qui sera plus difficile, cependant, est de configurer correctement les serveurs, les clients et les outils HTTP/3.

Serveurs et Réseaux

Comme vous l'avez probablement compris maintenant, QUIC et HTTP/3 sont des protocoles assez complexes. Les mettre en œuvre de toutes pièces impliquerait de lire (et de comprendre !) des centaines de pages réparties sur plus de sept documents. Heureusement, plusieurs entreprises travaillent sur des implémentations open-source QUIC et HTTP/3 depuis plus de cinq ans maintenant, nous avons donc le choix entre plusieurs options matures et stables.

Certains des plus importants et des plus stables sont les suivants :

Cependant, bon nombre (peut-être la plupart) de ces implémentations s'occupent principalement des éléments HTTP/3 et QUIC ; ce ne sont pas vraiment des serveurs Web à part entière . En ce qui concerne vos serveurs typiques (pensez NGINX, Apache, Node.js), les choses ont été un peu plus lentes, pour plusieurs raisons. Premièrement, peu de leurs développeurs étaient impliqués dans HTTP/3 depuis le début, et maintenant ils doivent rattraper leur retard. Beaucoup contournent cela en utilisant l'une des implémentations répertoriées ci-dessus en interne en tant que bibliothèques, mais même cette intégration est difficile.

Deuxièmement, de nombreux serveurs dépendent de bibliothèques TLS tierces telles que OpenSSL. C'est, encore une fois, parce que TLS est très complexe et doit être sécurisé, il est donc préférable de réutiliser le travail existant et vérifié. Cependant, bien que QUIC s'intègre à TLS 1.3, il l'utilise de manière très différente de la façon dont TLS et TCP interagissent . Cela signifie que les bibliothèques TLS doivent fournir des API spécifiques à QUIC, ce que leurs développeurs ont longtemps été réticents ou lents à faire. Le problème ici est particulièrement OpenSSL, qui a reporté la prise en charge de QUIC, mais il est également utilisé par de nombreux serveurs. Ce problème s'est tellement aggravé qu'Akamai a décidé de lancer un fork d'OpenSSL spécifique à QUIC, appelé quictls. Bien que d'autres options et solutions de contournement existent, la prise en charge de TLS 1.3 pour QUIC est toujours un blocage pour de nombreux serveurs, et elle devrait le rester pendant un certain temps.

Voici une liste partielle des serveurs Web complets que vous devriez pouvoir utiliser immédiatement, ainsi que leur prise en charge HTTP/3 actuelle :

• apache
  La prise en charge n'est pas claire pour le moment. Rien n'a été annoncé. Il a probablement aussi besoin d'OpenSSL. (Notez qu'il existe cependant une implémentation Apache Traffic Server.)
• NGINX
  Il s'agit d'une implémentation personnalisée. C'est relativement nouveau et encore très expérimental. Il devrait être fusionné avec NGINX principal d'ici la fin de 2021. C'est relativement nouveau et encore très expérimental. Notez qu'il existe également un correctif pour exécuter la bibliothèque quiche de Cloudflare sur NGINX, qui est probablement plus stable pour le moment.
• Node.js
  Cela utilise la bibliothèque ngtcp2 en interne. Il est bloqué par la progression d'OpenSSL, bien qu'ils prévoient de passer au fork QUIC-TLS pour que quelque chose fonctionne plus tôt.
• IIS
  Le support n'est pas clair pour le moment et rien n'a été annoncé. Cependant, il utilisera probablement la bibliothèque MsQuic en interne.
• Hypercorn
  Celui-ci intègre aioquic, avec un support expérimental.
• Caddie
  Cela utilise un accès rapide, avec un support complet.
• H2O
  Cela s'utilise rapidement, avec un support complet.
• Litespeed
  Cela utilise LSQUIC, avec un support complet.

Notez quelques nuances importantes :

• Même "support complet" signifie "aussi bon que possible pour le moment", pas nécessairement "prêt pour la production". Par exemple, de nombreuses implémentations ne prennent pas encore entièrement en charge la migration de connexion, 0-RTT, push serveur ou la hiérarchisation HTTP/3 .
• D'autres serveurs non répertoriés, comme Tomcat, n'ont (à ma connaissance) fait aucune annonce pour le moment.
• Parmi les serveurs Web répertoriés, seuls Litespeed, le correctif NGINX de Cloudflare et H2O ont été créés par des personnes intimement impliquées dans la normalisation QUIC et HTTP/3, il est donc plus probable qu'ils fonctionnent mieux au début.
  

Comme vous pouvez le voir, le paysage des serveurs n'est pas encore tout à fait là, mais il existe certainement déjà des options pour configurer un serveur HTTP/3. Cependant, le simple fait d'exécuter le serveur n'est que la première étape. Le configurer et le reste de votre réseau est plus difficile.

Configuration du réseau

Comme expliqué dans la partie 1, QUIC s'exécute au-dessus du protocole UDP pour faciliter son déploiement. Cependant, cela signifie simplement que la plupart des périphériques réseau peuvent analyser et comprendre UDP. Malheureusement, cela ne signifie pas que UDP est universellement autorisé . Étant donné que UDP est souvent utilisé pour les attaques et qu'il n'est pas essentiel au travail quotidien normal en dehors du DNS, de nombreux réseaux et pare-feu (d'entreprise) bloquent presque entièrement le protocole. En tant que tel, UDP doit probablement être explicitement autorisé vers/depuis vos serveurs HTTP/3 . QUIC peut s'exécuter sur n'importe quel port UDP, mais attendez-vous à ce que le port 443 (qui est également généralement utilisé pour HTTPS sur TCP) soit le plus courant.

Cependant, de nombreux administrateurs réseau ne voudront pas simplement autoriser la vente en gros d'UDP. Au lieu de cela, ils voudront spécifiquement autoriser QUIC sur UDP. Le problème est que, comme nous l'avons vu, QUIC est presque entièrement crypté. Cela inclut les métadonnées de niveau QUIC telles que les numéros de paquets, mais aussi, par exemple, les signaux qui indiquent la fermeture d'une connexion. Pour TCP, les pare-feu suivent activement toutes ces métadonnées pour vérifier le comportement attendu. (Avons-nous vu une poignée de main complète avant les paquets transportant des données ? Les paquets suivent-ils les modèles attendus ? Combien de connexions ouvertes y a-t-il ?) Comme nous l'avons vu dans la partie 1, c'est exactement l'une des raisons pour lesquelles TCP n'est plus pratiquement évolutif. Cependant, en raison du cryptage de QUIC, les pare-feu peuvent faire beaucoup moins de cette logique de suivi au niveau de la connexion , et les quelques bits qu'ils peuvent inspecter sont relativement complexes.

Ainsi, de nombreux fournisseurs de pare-feu recommandent actuellement de bloquer QUIC jusqu'à ce qu'ils puissent mettre à jour leur logiciel. Même après cela, cependant, de nombreuses entreprises pourraient ne pas vouloir l'autoriser, car la prise en charge du pare-feu QUIC sera toujours bien inférieure aux fonctionnalités TCP auxquelles elles sont habituées.

Tout cela est encore plus compliqué par la fonctionnalité de migration de connexion. Comme nous l'avons vu, cette fonctionnalité permet de poursuivre la connexion à partir d'une nouvelle adresse IP sans avoir à effectuer une nouvelle poignée de main, grâce à l'utilisation d'identifiants de connexion (CID). Cependant, pour le pare-feu, cela donnera l'impression qu'une nouvelle connexion est utilisée sans avoir d'abord utilisé une poignée de main, ce qui pourrait tout aussi bien être un attaquant envoyant du trafic malveillant. Les pare-feu ne peuvent pas simplement utiliser les QUIC CID, car ils changent également au fil du temps pour protéger la vie privée des utilisateurs ! En tant que tel, les serveurs auront besoin de communiquer avec le pare-feu à propos des CID attendus , mais rien de tout cela n'existe encore.

Il existe des préoccupations similaires pour les équilibreurs de charge pour les configurations à plus grande échelle. Ces machines répartissent les connexions entrantes sur un grand nombre de serveurs principaux. Le trafic d'une connexion doit, bien sûr, toujours être acheminé vers le même serveur principal (les autres ne sauraient pas quoi en faire !). Pour TCP, cela pourrait simplement être fait sur la base du 4-uplet, car cela ne change jamais. Avec la migration de connexion QUIC, cependant, ce n'est plus une option. Encore une fois, les serveurs et les équilibreurs de charge devront s'entendre d'une manière ou d'une autre sur les CID à choisir afin de permettre un routage déterministe . Contrairement à la configuration du pare-feu, cependant, il existe déjà une proposition pour le configurer (bien que cela soit loin d'être largement implémenté).

Enfin, il existe d'autres considérations de sécurité de niveau supérieur, principalement autour des attaques 0-RTT et des attaques par déni de service distribué (DDoS). Comme indiqué dans la partie 2, QUIC inclut déjà un certain nombre d'atténuations pour ces problèmes, mais idéalement, ils utiliseront également des lignes de défense supplémentaires sur le réseau. Par exemple, les serveurs proxy ou périphériques peuvent empêcher certaines requêtes 0-RTT d'atteindre les back-ends réels pour empêcher les attaques par relecture. Alternativement, pour empêcher les attaques par réflexion ou les attaques DDoS qui n'envoient que le premier paquet de prise de contact, puis cessent de répondre (appelées inondations SYN dans TCP), QUIC inclut la fonction de nouvelle tentative. Cela permet au serveur de valider qu'il s'agit d'un client qui se comporte bien, sans avoir à conserver d'état entre-temps (l'équivalent des cookies TCP SYN). Bien sûr, ce processus de nouvelle tentative se déroule mieux quelque part avant le serveur principal, par exemple, au niveau de l'équilibreur de charge. Encore une fois, cela nécessite une configuration et une communication supplémentaires pour la configuration.

Ce ne sont que les problèmes les plus importants que les administrateurs réseau et système auront avec QUIC et HTTP/3. Il y en a plusieurs autres, dont j'ai déjà parlé. Il existe également deux documents d'accompagnement distincts pour les RFC QUIC qui traitent de ces problèmes et de leurs atténuations (partielles) possibles.

Qu'est-ce que tout cela veut dire?

HTTP/3 et QUIC sont des protocoles complexes qui reposent sur de nombreuses machines internes. Tout cela n'est pas encore prêt pour les heures de grande écoute , bien que vous ayez déjà quelques options pour déployer les nouveaux protocoles sur vos back-ends. Cependant, il faudra probablement quelques mois, voire des années, pour que les serveurs les plus importants et les bibliothèques sous-jacentes (telles que OpenSSL) soient mis à jour.

Même dans ce cas, configurer correctement les serveurs et autres intermédiaires du réseau, afin que les protocoles puissent être utilisés de manière sécurisée et optimale, ne sera pas trivial dans des configurations à plus grande échelle. Vous aurez besoin d'une bonne équipe de développement et d'exploitation pour effectuer correctement cette transition.

En tant que tel, surtout au début, il est probablement préférable de s'appuyer sur une grande société d'hébergement ou un CDN pour mettre en place et configurer les protocoles pour vous. Comme indiqué dans la partie 2, c'est là que QUIC est le plus susceptible de rapporter de toute façon, et l'utilisation d'un CDN est l'une des principales optimisations de performances que vous pouvez faire. Je recommanderais personnellement d'utiliser Cloudflare ou Fastly car ils ont été intimement impliqués dans le processus de normalisation et auront les implémentations les plus avancées et les mieux réglées disponibles.

Clients et découverte QUIC

Jusqu'à présent, nous avons envisagé la prise en charge côté serveur et en réseau des nouveaux protocoles. Cependant, plusieurs problèmes sont également à surmonter du côté du client.

Avant d'en arriver là, commençons par quelques bonnes nouvelles : la plupart des navigateurs populaires ont déjà un support HTTP/3 (expérimental) ! Plus précisément, au moment de la rédaction, voici l'état du support (voir aussi caniuse.com):

• Google Chrome (version 91+) : Activé par défaut.
• Mozilla Firefox (version 89+) : Activé par défaut.
• Microsoft Edge (version 90+) : Activé par défaut (utilise Chromium en interne).
• Opera (version 77+) : Activé par défaut (utilise Chromium en interne).
• Apple Safari (version 14) : Derrière un drapeau manuel. Sera activé par défaut dans la version 15, qui est actuellement en avant-première technologique.
• Autres navigateurs : aucun signal à ma connaissance (bien que d'autres navigateurs qui utilisent Chromium en interne, tels que Brave, pourraient, en théorie, également commencer à l'activer).

Notez quelques nuances :

• La plupart des navigateurs se déploient progressivement, de sorte que tous les utilisateurs ne bénéficieront pas de la prise en charge HTTP/3 activée par défaut dès le départ. Ceci est fait pour limiter les risques qu'un seul bogue négligé puisse affecter de nombreux utilisateurs ou que les déploiements de serveurs soient surchargés. En tant que tel, il y a une petite chance que, même dans les versions récentes du navigateur, vous n'obteniez pas HTTP/3 par défaut et que vous deviez l'activer manuellement.
• Comme pour les serveurs, la prise en charge de HTTP/3 ne signifie pas que toutes les fonctionnalités ont été implémentées ou sont actuellement utilisées. En particulier, 0-RTT, migration de connexion, push de serveur, compression d'en-tête QPACK dynamique et hiérarchisation HTTP/3 peuvent toujours être manquants, désactivés, utilisés avec parcimonie ou mal configurés.
• Si vous souhaitez utiliser HTTP/3 côté client en dehors du navigateur (par exemple, dans votre application native), vous devrez alors intégrer l'une des bibliothèques répertoriées ci-dessus ou utiliser cURL. Apple apportera bientôt le support natif HTTP / 3 et QUIC à ses bibliothèques de réseau intégrées sur macOS et iOS, et Microsoft ajoute QUIC au noyau Windows et à leur environnement .NET, mais un support natif similaire n'a (à ma connaissance) pas été annoncé pour d'autres systèmes comme Android.

Alt-Svc

Même si vous avez configuré un serveur compatible HTTP/3 et que vous utilisez un navigateur mis à jour, vous pourriez être surpris de constater que HTTP/3 n'est pas utilisé de manière cohérente . Pour comprendre pourquoi, supposons que vous soyez le navigateur pendant un moment. Votre utilisateur vous a demandé d'accéder à example.com (un site Web que vous n'avez jamais visité auparavant) et vous avez utilisé le DNS pour le résoudre en adresse IP. Vous envoyez un ou plusieurs paquets de prise de contact QUIC à cette adresse IP. Maintenant, plusieurs choses peuvent mal tourner :

1. Le serveur peut ne pas prendre en charge QUIC.
2. L'un des réseaux intermédiaires ou pare-feu peut bloquer complètement QUIC et/ou UDP.
3. Les paquets de prise de contact peuvent être perdus en transit.

Cependant, comment sauriez-vous (lequel) de ces problèmes s'est produit ? Dans les trois cas, vous ne recevrez jamais de réponse à votre ou vos paquets de poignée de main. La seule chose que vous pouvez faire est d'attendre, en espérant qu'une réponse puisse encore arriver. Ensuite, après un certain temps d'attente (le délai d'attente), vous pourriez décider qu'il y a effectivement un problème avec HTTP/3. À ce stade, vous essaierez d'ouvrir une connexion TCP au serveur, en espérant que HTTP/2 ou HTTP/1.1 fonctionnera.

Comme vous pouvez le constater, ce type d'approche peut entraîner des retards importants, en particulier au cours de la ou des premières années, lorsque de nombreux serveurs et réseaux ne prendront pas encore en charge QUIC. Une solution simple mais naïve serait simplement d' ouvrir une connexion QUIC et TCP en même temps, puis d'utiliser la poignée de main qui se terminera en premier . Cette méthode est appelée "course de connexion" ou "globes oculaires heureux". Bien que cela soit certainement possible, cela entraîne des frais généraux considérables. Même si la connexion perdue est presque immédiatement fermée, elle prend encore de la mémoire et du temps CPU sur le client et le serveur (en particulier lors de l'utilisation de TLS). En plus de cela, il y a aussi d'autres problèmes avec cette méthode impliquant des réseaux IPv4 contre IPv6 et les attaques de relecture discutées précédemment (que ma présentation couvre plus en détail).

Ainsi, pour QUIC et HTTP/3, les navigateurs préfèrent jouer la sécurité et n'essayer QUIC que s'ils savent que le serveur le prend en charge . Ainsi, la première fois qu'un nouveau serveur est contacté, le navigateur n'utilisera que HTTP/2 ou HTTP/1.1 via une connexion TCP. Le serveur peut alors faire savoir au navigateur qu'il prend également en charge HTTP/3 pour les connexions ultérieures. Cela se fait en définissant un en-tête HTTP spécial sur les réponses renvoyées via HTTP/2 ou HTTP/1.1. Cet en-tête s'appelle Alt-Svc , qui signifie "services alternatifs". Alt-Svc peut être utilisé pour faire savoir à un navigateur qu'un certain service est également accessible via un autre serveur (IP et/ou port), mais il permet également d'indiquer des protocoles alternatifs. Ceci peut être vu ci-dessous dans la figure 1.

Dès réception d'un en-tête Alt-Svc valide indiquant la prise en charge de HTTP/3, le navigateur le mettra en cache et tentera d'établir une connexion QUIC à partir de ce moment. Certains clients le feront dès que possible (même pendant le chargement initial de la page - voir ci-dessous), tandis que d'autres attendront que la ou les connexions TCP existantes soient fermées. Cela signifie que le navigateur n'utilisera HTTP/3 qu'après avoir d'abord téléchargé au moins quelques ressources via HTTP/2 ou HTTP/1.1 . Même alors, ce n'est pas la navigation facile. Le navigateur sait maintenant que le serveur prend en charge HTTP/3, mais cela ne signifie pas que le réseau intermédiaire ne le bloquera pas. En tant que tel, la course de connexion est toujours nécessaire dans la pratique. Ainsi, vous pouvez toujours vous retrouver avec HTTP/2 si le réseau retarde suffisamment la prise de contact QUIC. De plus, si la connexion QUIC ne parvient pas à s'établir plusieurs fois de suite, certains navigateurs placeront l'entrée de cache Alt-Svc sur une liste de refus pendant un certain temps, sans essayer HTTP/3 pendant un certain temps. En tant que tel, il peut être utile de vider manuellement le cache de votre navigateur si les choses se passent, car cela devrait également vider les liaisons Alt-Svc . Enfin, il a été démontré que Alt-Svc pose de sérieux risques de sécurité. Pour cette raison, certains navigateurs imposent des restrictions supplémentaires, par exemple, sur les ports pouvant être utilisés (dans Chrome, vos serveurs HTTP/2 et HTTP/3 doivent être tous les deux sur un port inférieur à 1024 ou les deux sur un port supérieur ou égal à 1024, sinon Alt-Svc sera ignoré). Toute cette logique varie et évolue énormément d'un navigateur à l'autre, ce qui signifie qu'il peut être difficile d'obtenir des connexions HTTP/3 cohérentes , ce qui complique également le test de nouvelles configurations.

Des travaux sont en cours pour améliorer quelque peu ce processus Alt-Svc en deux étapes. L'idée est d'utiliser de nouveaux enregistrements DNS appelés SVCB et HTTPS, qui contiendront des informations similaires à celles contenues dans Alt-Svc . En tant que tel, le client peut découvrir qu'un serveur prend en charge HTTP/3 lors de l'étape de résolution DNS à la place, ce qui signifie qu'il peut essayer QUIC dès le tout premier chargement de page au lieu de devoir d'abord passer par HTTP/2 ou HTTP/1.1. Pour plus d'informations à ce sujet et sur Alt-Svc , consultez le chapitre Web Almanac de l'année dernière sur HTTP/2.

Comme vous pouvez le voir, Alt-Svc et le processus de découverte HTTP/3 ajoutent une couche de complexité à votre déploiement de serveur QUIC déjà difficile, car :

• vous devrez toujours déployer votre serveur HTTP/3 à côté d'un serveur HTTP/2 et/ou HTTP/1.1 ;
• vous devrez configurer vos serveurs HTTP/2 et HTTP/1.1 pour définir les en-têtes Alt-Svc corrects sur leurs réponses.

Bien que cela devrait être gérable dans les configurations de niveau de production (parce que, par exemple, une seule instance Apache ou NGINX prendra probablement en charge les trois versions HTTP en même temps), cela pourrait être beaucoup plus ennuyeux dans l'ensemble de test (local)- ups (je me vois déjà oublier d'ajouter les en-têtes Alt-Svc ou les gâcher). Ce problème est aggravé par un manque (actuel) de journaux d'erreurs de navigateur et d'indicateurs DevTools, ce qui signifie qu'il peut être difficile de déterminer pourquoi exactement la configuration ne fonctionne pas.

Problèmes supplémentaires

Comme si cela ne suffisait pas, un autre problème rendra les tests locaux plus difficiles : Chrome rend très difficile l'utilisation de certificats TLS auto-signés pour QUIC . En effet, les certificats TLS non officiels sont souvent utilisés par les entreprises pour déchiffrer le trafic TLS de leurs employés (afin qu'ils puissent, par exemple, faire analyser leurs pare-feu à l'intérieur du trafic chiffré). Cependant, si les entreprises commençaient à le faire avec QUIC, nous aurions à nouveau des implémentations de middlebox personnalisées qui font leurs propres hypothèses sur le protocole. Cela pourrait les amener à casser la prise en charge du protocole à l'avenir, ce que nous avons essayé d'empêcher en chiffrant QUIC si intensivement en premier lieu ! As such, Chrome takes a very opinionated stance on this: If you're not using an official TLS certificate (signed by a certificate authority or root certificate that is trusted by Chrome, such as Let's Encrypt), then you cannot use QUIC . This, sadly, also includes self-signed certificates, which are often used for local test set-ups.

It is still possible to bypass this with some freaky command-line flags (because the common --ignore-certificate-errors doesn't work for QUIC yet), by using per-developer certificates (although setting this up can be tedious), or by setting up the real certificate on your development PC (but this is rarely an option for big teams because you would have to share the certificate's private key with each developer). Finally, while you can install a custom root certificate, you would then also need to pass both the --origin-to-force-quic-on and --ignore-certificate-errors-spki-list flags when starting Chrome (see below). Luckily, for now, only Chrome is being so strict, and hopefully, its developers will loosen their approach over time.

If you are having problems with your QUIC set-up from inside a browser, it's best to first validate it using a tool such as cURL. cURL has excellent HTTP/3 support (you can even choose between two different underlying libraries) and also makes it easier to observe Alt-Svc caching logic.

Qu'est-ce que tout cela veut dire?

Next to the challenges involved with setting up HTTP/3 and QUIC on the server-side, there are also difficulties in getting browsers to use the new protocols consistently. This is due to a two-step discovery process involving the Alt-Svc HTTP header and the fact that HTTP/2 connections cannot simply be “upgraded” to HTTP/3, because the latter uses UDP.

Even if a server supports HTTP/3, however, clients (and website owners!) need to deal with the fact that intermediate networks might block UDP and/or QUIC traffic. As such, HTTP/3 will never completely replace HTTP/2 . In practice, keeping a well-tuned HTTP/2 set-up will remain necessary both for first-time visitors and visitors on non-permissive networks. Luckily, as we discussed, there shouldn't be many page-level changes between HTTP/2 and HTTP/3, so this shouldn't be a major headache.

What could become a problem, however, is testing and verifying whether you are using the correct configuration and whether the protocols are being used as expected. This is true in production, but especially in local set-ups. As such, I expect that most people will continue to run HTTP/2 (or even HTTP/1.1) development servers , switching only to HTTP/3 in a later deployment stage. Even then, however, validating protocol performance with the current generation of tools won't be easy.

Tools and Testing

As was the case with many major servers, the makers of the most popular web performance testing tools have not been keeping up with HTTP/3 from the start. Consequently, few tools have dedicated support for the new protocol as of July 2021, although they support it to a certain degree.

Phare de Google

First, there is the Google Lighthouse tool suite. While this is an amazing tool for web performance in general, I have always found it somewhat lacking in aspects of protocol performance. This is mostly because it simulates slow networks in a relatively unrealistic way, in the browser (the same way that Chrome's DevTools handle this). While this approach is quite usable and typically “good enough” to get an idea of the impact of a slow network, testing low-level protocol differences is not realistic enough. Because the browser doesn't have direct access to the TCP stack, it still downloads the page on your normal network, and it then artificially delays the data from reaching the necessary browser logic. This means, for example, that Lighthouse emulates only delay and bandwidth, but not packet loss (which, as we've seen, is a major point where HTTP/3 could potentially differ from HTTP/2). Alternatively, Lighthouse uses a highly advanced simulation model to guesstimate the real network impact, because, for example, Google Chrome has some complex logic that tweaks several aspects of a page load if it detects a slow network. This model has, to the best of my knowledge, not been adjusted to handle IETF QUIC or HTTP/3 yet. As such, if you use Lighthouse today for the sole purpose of comparing HTTP/2 and HTTP/3 performance, then you are likely to get erroneous or oversimplified results, which could lead you to wrong conclusions about what HTTP/3 can do for your website in practice. The silver lining is that, in theory, this can be improved massively in the future, because the browser does have full access to the QUIC stack, and thus Lighthouse could add much more advanced simulations (including packet loss!) for HTTP/3 down the line. For now, though, while Lighthouse can, in theory, load pages over HTTP/3, I would recommend against it.

WebPageTest

Secondly, there is WebPageTest. This amazing project lets you load pages over real networks from real devices across the world, and it also allows you to add packet-level network emulation on top, including aspects such as packet loss! As such, WebPageTest is conceptually in a prime position to be used to compare HTTP/2 and HTTP/3 performance. However, while it can indeed already load pages over the new protocol, HTTP/3 has not yet been properly integrated into the tooling or visualizations . For example, there are currently no easy ways to force a page load over QUIC, to easily view how Alt-Svc was actually used, or even to see QUIC handshake details. In some cases, even seeing whether a response used HTTP/3 or HTTP/2 can be challenging. Still, in April, I was able to use WebPageTest to run quite a few tests on facebook.com and see HTTP/3 in action, which I'll go over now.

First, I ran a default test for facebook.com , enabling the “repeat view” option. As explained above, I would expect the first page load to use HTTP/2, which will include the Alt-Svc response header. As such, the repeat view should use HTTP/3 from the start. In Firefox version 89, this is more or less what happens. However, when looking at individual responses, we see that even during the first page load, Firefox will switch to using HTTP/3 instead of HTTP/2 ! As you can see in figure 2, this happens from the 20th resource onwards. This means that Firefox establishes a new QUIC connection as soon as it sees the Alt-Svc header, and it switches to it once it succeeds. If you scroll down to the connection view, it also seems to show that Firefox even opened two QUIC connections: one for credentialed CORS requests and one for no-CORS requests. This would be expected because, as we discussed above, even for HTTP/2 and HTTP/3, browsers will open multiple connections due to security concerns. However, because WebPageTest doesn't provide more details in this view, it's difficult to confirm without manually digging through the data. Looking at the repeat view (second visit), it starts by directly using HTTP/3 for the first request, as expected.

Next, for Chrome, we see similar behavior for the first page load, although here Chrome already switches on the 10th resource, much earlier than Firefox. It's a bit more unclear here whether it switches as soon as possible or only when a new connection is needed (for example, for requests with different credentials), because, unlike for Firefox, the connection view also doesn't seem to show multiple QUIC connections. For the repeat view, we see some weirder things. Unexpectedly, Chrome starts off using HTTP/2 there as well , switching to HTTP/3 only after a few requests! I performed a few more tests on other pages as well, to confirm that this is indeed consistent behaviour. This could be due to several things: It might just be Chrome's current policy, it might be that Chrome “raced” a TCP and QUIC connection and TCP won initially, or it might be that the Alt-Svc cache from the first view was unused for some reason. At this point, there is, sadly, no easy way to determine what the problem really is (and whether it can even be fixed).

Another interesting thing I noticed here is the apparent connection coalescing behavior. As discussed above, both HTTP/2 and HTTP/3 can reuse connections even if they go to other hostnames, to prevent downsides from hostname sharding. However, as shown in figure 3, WebPageTest reports that, for this Facebook load, connection coalescing is used over HTTP/3 for facebook.com and fbcdn.net , but not over HTTP/2 (as Chrome opens a secondary connection for the second domain). I suspect this is a bug in WebPageTest, however, because facebook.com and fbcnd.net resolve to different IPs and, as such, can't really be coalesced.

The figure also shows that some key QUIC handshake information is missing from the current WebPageTest visualization.

Note : As we see, getting “real” HTTP/3 going can be difficult sometimes. Luckily, for Chrome specifically, we have additional options we can use to test QUIC and HTTP/3, in the form of command-line parameters.

On the bottom of WebPageTest's “Chromium” tab, I used the following command-line options:

 --enable-quic --quic-version=h3-29 --origin-to-force-quic-on=www.facebook.com:443,static.xx.fbcdn.net:443

The results from this test show that this indeed forces a QUIC connection from the start, even in the first view, thus bypassing the Alt-Svc process. Interestingly, you will notice I had to pass two hostnames to --origin-to-force-quic-on . In the version where I didn't, Chrome, of course, still first opened an HTTP/2 connection to the fbcnd.net domain, even in the repeat view. As such, you'll need to manually indicate all QUIC origins in order for this to work !

We can see even from these few examples that a lot of stuff is going on with how browsers actually use HTTP/3 in practice. It seems they even switch to the new protocol during the initial page load, abandoning HTTP/2 either as soon as possible or when a new connection is needed. As such, it's difficult not only getting a full HTTP/3 load, but also getting a pure HTTP/2 load on a set-up that supports both ! Because WebPageTest doesn't show much HTTP/3 or QUIC metadata yet, figuring out what's going on can be challenging, and you can't trust the tools and visualizations at face value either.

So, if you use WebPageTest, you'll need to double-check the results to make sure which protocols were actually used. Consequently, I think this means that it's too early to really test HTTP/3 performance at this time (and especially too early to compare it to HTTP/2). This belief is strengthened by the fact that not all servers and clients have implemented all protocol features yet. Due to the fact that WebPageTest doesn't yet have easy ways of showing whether advanced aspects such as 0-RTT were used, it will be tricky to know what you're actually measuring. This is especially true for the HTTP/3 prioritization feature, which isn't implemented properly in all browsers yet and which many servers also lack full support for. Because prioritization can be a major aspect driving web performance, it would be unfair to compare HTTP/3 to HTTP/2 without making sure that at least this feature works properly (for both protocols!). This is just one aspect, though, as my research shows how big the differences between QUIC implementations can be. If you do any comparison of this sort yourself (or if you read articles that do), make 100% sure that you've checked what's actually going on .

Finally, also note that other higher-level tools (or data sets such as the amazing HTTP Archive) are often based on WebPageTest or Lighthouse (or use similar methods), so I suspect that most of my comments here will be widely applicable to most web performance tooling. Even for those tool vendors announcing HTTP/3 support in the coming months, I would be a bit skeptical and would validate that they're actually doing it correctly. For some tools, things are probably even worse, though; for example, Google's PageSpeed Insights only got HTTP/2 support this year, so I wouldn't wait for HTTP/3 arriving anytime soon.

Wireshark, qlog et qvis

Comme le montre la discussion ci-dessus, il peut être difficile d'analyser le comportement HTTP/3 en utilisant simplement Lighthouse ou WebPageTest à ce stade. Heureusement, d'autres outils de niveau inférieur sont disponibles pour vous aider. Tout d'abord, l'excellent outil Wireshark a un support avancé pour QUIC, et il peut également disséquer expérimentalement HTTP/3. Cela vous permet d'observer quels paquets QUIC et HTTP/3 passent réellement sur le réseau. Cependant, pour que cela fonctionne, vous devez obtenir les clés de déchiffrement TLS pour une connexion donnée, que la plupart des implémentations (y compris Chrome et Firefox) vous permettent d'extraire en utilisant la variable d'environnement SSLKEYLOGFILE . Bien que cela puisse être utile pour certaines choses, comprendre vraiment ce qui se passe, en particulier pour les connexions plus longues, peut nécessiter beaucoup de travail manuel. Vous auriez également besoin d'une compréhension assez avancée du fonctionnement interne des protocoles.

Heureusement, il existe une deuxième option, qlog et qvis. qlog est un format de journalisation basé sur JSON spécifiquement pour QUIC et HTTP/3 qui est pris en charge par la majorité des implémentations QUIC. Au lieu de regarder les paquets passant par le câble, qlog capture ces informations directement sur le client et le serveur, ce qui lui permet d'inclure des informations supplémentaires (par exemple, les détails du contrôle de la congestion). Généralement, vous pouvez déclencher la sortie qlog lors du démarrage des serveurs et des clients avec la variable d'environnement QLOGDIR . (Notez que dans Firefox, vous devez définir la préférence network.http.http3.enable_qlog . Les appareils Apple et Safari utilisent plutôt QUIC_LOG_DIRECTORY . Chrome ne prend pas encore en charge qlog.)

Ces fichiers qlog peuvent ensuite être téléchargés dans la suite d'outils qvis sur qvis.quictools.info. Vous y trouverez un certain nombre de visualisations interactives avancées qui facilitent l'interprétation du trafic QUIC et HTTP/3 . qvis prend également en charge le téléchargement de captures de paquets Wireshark (fichiers .pcap ), et il a un support expérimental pour les fichiers netlog de Chrome, vous pouvez donc également analyser le comportement de Chrome. Un didacticiel complet sur qlog et qvis dépasse le cadre de cet article, mais vous trouverez plus de détails sous forme de didacticiel, sous forme d'article et même sous forme de talk-show. Vous pouvez également me poser des questions à leur sujet directement car je suis le principal implémenteur de qlog et qvis. ;)

Cependant, je ne me fais aucune illusion sur le fait que la plupart des lecteurs ici devraient utiliser Wireshark ou qvis, car ce sont des outils de bas niveau. Pourtant, comme nous avons peu d'alternatives pour le moment, je recommande fortement de ne pas tester de manière approfondie les performances HTTP/3 sans utiliser ce type d'outil , pour vous assurer que vous savez vraiment ce qui se passe sur le fil et si ce que vous voyez est vraiment expliqué par les internes du protocole et non par d'autres facteurs.

Qu'est-ce que tout cela veut dire?

Comme nous l'avons vu, configurer et utiliser HTTP/3 sur QUIC peut être une affaire complexe, et beaucoup de choses peuvent mal tourner. Malheureusement, aucun bon outil ou visualisation n'est disponible qui expose les détails nécessaires à un niveau d'abstraction approprié. Il est donc très difficile pour la plupart des développeurs d'évaluer les avantages potentiels que HTTP/3 peut apporter à leur site Web à l'heure actuelle ou même de valider que leur configuration fonctionne comme prévu.

S'appuyer uniquement sur des métriques de haut niveau est très dangereux car celles-ci pourraient être faussées par une pléthore de facteurs (tels qu'une émulation de réseau irréaliste, un manque de fonctionnalités sur les clients ou les serveurs, une utilisation partielle de HTTP/3, etc.). Même si tout fonctionnait mieux, comme nous l'avons vu dans la partie 2, les différences entre HTTP/2 et HTTP/3 seront probablement relativement faibles dans la plupart des cas, ce qui rend encore plus difficile l'obtention des informations nécessaires de haut niveau. outils sans prise en charge HTTP/3 ciblée.

En tant que tel, je recommande de laisser les mesures de performances HTTP/2 par rapport à HTTP/3 seules pendant quelques mois supplémentaires et de nous concentrer plutôt sur la vérification que nos configurations côté serveur fonctionnent comme prévu . Pour cela, il est plus simple d'utiliser WebPageTest en combinaison avec les paramètres de ligne de commande de Google Chrome, avec un repli sur curl pour les problèmes potentiels - c'est actuellement la configuration la plus cohérente que je puisse trouver.

Conclusion et plats à emporter

Cher lecteur, si vous avez lu l'intégralité de la série en trois parties et que vous l'avez fait ici, je vous salue ! Même si vous n'avez lu que quelques sections, je vous remercie de l'intérêt que vous portez à ces nouveaux protocoles passionnants. Maintenant, je vais résumer les principaux enseignements de cette série, fournir quelques recommandations clés pour les mois et l'année à venir, et enfin vous fournir quelques ressources supplémentaires, au cas où vous souhaiteriez en savoir plus.

Sommaire

Tout d'abord, dans la partie 1, nous avons expliqué que HTTP/3 était nécessaire principalement en raison du nouveau protocole de transport QUIC sous-jacent . QUIC est le successeur spirituel de TCP et intègre toutes ses meilleures pratiques, ainsi que TLS 1.3. Cela était principalement nécessaire parce que TCP, en raison de son déploiement et de son intégration omniprésents dans les boîtiers de médiation, est devenu trop rigide pour évoluer. L'utilisation par QUIC de l'UDP et du cryptage presque complet signifie que nous n'aurons (espérons-le) qu'à mettre à jour les terminaux à l'avenir afin d'ajouter de nouvelles fonctionnalités, ce qui devrait être plus facile. QUIC, cependant, ajoute également de nouvelles fonctionnalités intéressantes. Premièrement, le transport combiné et la poignée de main cryptographique de QUIC sont plus rapides que TCP + TLS, et il peut faire bon usage de la fonctionnalité 0-RTT. Deuxièmement, QUIC sait qu'il transporte plusieurs flux d'octets indépendants et peut être plus intelligent dans la façon dont il gère les pertes et les retards, atténuant ainsi le problème de blocage en tête de ligne. Troisièmement, les connexions QUIC peuvent survivre aux utilisateurs qui se déplacent vers un réseau différent (appelé migration de connexion) en étiquetant chaque paquet avec un ID de connexion. Enfin, la structure de paquets flexible de QUIC (utilisant des trames) le rend plus efficace mais aussi plus flexible et extensible à l'avenir. En conclusion, il est clair que QUIC est le protocole de transport de nouvelle génération et qu'il sera utilisé et étendu pendant de nombreuses années .

Deuxièmement, dans la partie 2, nous avons jeté un regard critique sur ces nouvelles fonctionnalités, en particulier sur leurs implications en termes de performances . Tout d'abord, nous avons vu que l'utilisation d'UDP par QUIC ne le rend pas comme par magie plus rapide (ni plus lent) car QUIC utilise des mécanismes de contrôle de congestion très similaires à TCP pour éviter de surcharger le réseau. Deuxièmement, la poignée de main plus rapide et le 0-RTT sont davantage des micro-optimisations, car ils ne sont en réalité qu'un aller-retour plus rapides qu'une pile TCP + TLS optimisée, et le véritable 0-RTT de QUIC est en outre affecté par une série de problèmes de sécurité qui peuvent limiter son utilité. Troisièmement, la migration de connexion n'est vraiment nécessaire que dans quelques cas spécifiques, et cela signifie toujours réinitialiser les taux d'envoi car le contrôle de la congestion ne sait pas combien de données le nouveau réseau peut gérer. Quatrièmement, l'efficacité de la suppression du blocage de tête de ligne de QUIC dépend fortement de la façon dont les données de flux sont multiplexées et hiérarchisées. Les approches optimales pour récupérer de la perte de paquets semblent préjudiciables aux cas d'utilisation généraux des performances de chargement des pages Web et vice versa, bien que des recherches supplémentaires soient nécessaires. Cinquièmement, QUIC pourrait facilement être plus lent à envoyer des paquets que TCP + TLS, car les API UDP sont moins matures et QUIC chiffre chaque paquet individuellement, bien que cela puisse être largement atténué dans le temps. Sixièmement, HTTP/3 lui-même n'apporte pas vraiment de nouvelles fonctionnalités de performance majeures à la table, mais retravaille et simplifie principalement les composants internes des fonctionnalités HTTP/2 connues. Enfin, certaines des fonctionnalités les plus intéressantes liées aux performances autorisées par QUIC (multipath, données non fiables, WebTransport, correction d'erreurs directes, etc.) ne font pas partie des normes de base QUIC et HTTP/3, mais sont plutôt des extensions proposées qui prendront un peu plus de temps pour être disponible. En conclusion, cela signifie que QUIC n'améliorera probablement pas beaucoup les performances des utilisateurs sur les réseaux à haut débit, mais sera principalement important pour ceux sur les réseaux lents et moins stables .

Enfin, dans cette partie 3, nous avons vu comment utiliser et déployer concrètement QUIC et HTTP/3 . Tout d'abord, nous avons vu que la plupart des meilleures pratiques et leçons tirées de HTTP/2 devraient simplement être transférées à HTTP/3. Il n'est pas nécessaire de modifier votre stratégie de regroupement ou d'intégration, ni de consolider ou de fragmenter votre batterie de serveurs. La poussée du serveur n'est toujours pas la meilleure fonctionnalité à utiliser, et le preload peut également être un pistolet puissant. Deuxièmement, nous avons discuté du fait que cela pourrait prendre un certain temps avant que les packages de serveur Web prêts à l'emploi fournissent une prise en charge complète de HTTP/3 (en partie à cause des problèmes de prise en charge de la bibliothèque TLS), bien que de nombreuses options open source soient disponibles pour les premiers utilisateurs et plusieurs grands CDN ont une offre mature. Troisièmement, il est clair que la plupart des principaux navigateurs ont un support HTTP/3 (de base), même activé par défaut. Cependant, il existe des différences majeures dans la manière et le moment où ils utilisent HTTP/3 et ses nouvelles fonctionnalités, donc comprendre leur comportement peut être difficile. Quatrièmement, nous avons expliqué que cela est aggravé par un manque de prise en charge explicite de HTTP/3 dans des outils populaires tels que Lighthouse et WebPageTest, ce qui rend particulièrement difficile la comparaison des performances de HTTP/3 à HTTP/2 et HTTP/1.1 pour le moment. En conclusion, HTTP/3 et QUIC ne sont probablement pas encore tout à fait prêts pour le prime time, mais ils le seront bientôt .

Recommandations

D'après le résumé ci-dessus, il peut sembler que je présente des arguments solides contre l'utilisation de QUIC ou HTTP/3. Cependant, c'est tout à fait à l'opposé de ce que je veux faire valoir.

Tout d'abord, comme indiqué à la fin de la partie 2, même si votre utilisateur « moyen » ne connaîtra peut-être pas de gains de performances majeurs (selon votre marché cible), une partie importante de votre public verra probablement des améliorations impressionnantes . 0-RTT peut n'économiser qu'un seul aller-retour, mais cela peut encore signifier plusieurs centaines de millisecondes pour certains utilisateurs. La migration de connexion peut ne pas permettre des téléchargements rapides et constants, mais elle aidera certainement les personnes essayant de récupérer ce PDF dans un train à grande vitesse. La perte de paquets sur le câble peut être sporadique, mais les liaisons sans fil pourraient bénéficier davantage de la suppression du blocage en tête de ligne de QUIC. De plus, ces utilisateurs sont ceux qui rencontreraient généralement les pires performances de votre produit et, par conséquent, en seraient les plus durement touchés. Si vous vous demandez pourquoi c'est important, lisez la célèbre anecdote sur les performances Web de Chris Zacharias.

Deuxièmement, QUIC et HTTP/3 ne feront que s'améliorer et s'accélérer avec le temps . La version 1 s'est concentrée sur l'exécution du protocole de base, en gardant des fonctionnalités de performances plus avancées pour plus tard. En tant que tel, je pense qu'il est rentable de commencer à investir dans les protocoles maintenant, pour vous assurer que vous pouvez les utiliser et les nouvelles fonctionnalités de manière optimale lorsqu'elles seront disponibles sur toute la ligne. Compte tenu de la complexité des protocoles et de leurs aspects de déploiement, il serait bon de se donner un peu de temps pour se familiariser avec leurs bizarreries. Même si vous ne voulez pas encore vous salir les mains, plusieurs grands fournisseurs de CDN offrent une prise en charge HTTP/3 mature « inversez le commutateur » (en particulier, Cloudflare et Fastly). J'ai du mal à trouver une raison de ne pas essayer cela si vous utilisez un CDN (ce qui, si vous vous souciez des performances, vous devriez vraiment l'être).

En tant que tel, même si je ne dirais pas qu'il est crucial de commencer à utiliser QUIC et HTTP/3 dès que possible, je pense qu'il existe déjà de nombreux avantages à bénéficier, et ils ne feront qu'augmenter à l'avenir .

Lectures complémentaires

Bien que cela ait été un long corps de texte, malheureusement, cela ne fait qu'effleurer la surface technique des protocoles complexes que sont QUIC et HTTP/3.

Vous trouverez ci-dessous une liste de ressources supplémentaires pour un apprentissage continu, plus ou moins par ordre croissant de profondeur technique :

• « HTTP/3 expliqué », Daniel Stenberg
  Cet e-book, par le créateur de cURL, résume le protocole.
• "HTTP/2 en action", Barry Pollard
  Cet excellent livre complet sur HTTP/2 contient des conseils réutilisables et une section sur HTTP/3.
• @programmationart, Twitter
  Mes tweets sont principalement dédiés à QUIC, HTTP/3 et aux performances Web (y compris les actualités) en général. Voir par exemple mes discussions récentes sur les fonctionnalités QUIC.
• « YouTube », Robin Marx
  Mes plus de 10 entretiens approfondis couvrent divers aspects des protocoles.
• "Le blog de Cloudlare"
  C'est le produit principal d'une entreprise qui gère également un CDN sur le côté.
• "Le blog Fastly"
  Ce blog contient d'excellentes discussions sur les aspects techniques, intégrés dans un contexte plus large.
• QUIC, les RFC réels
  Vous trouverez des liens vers les documents IETF QUIC et HTTP/3 RFC et d'autres extensions officielles.
• Blog IIJ Engineers : Excellentes explications techniques approfondies des détails des fonctionnalités QUIC.
• Articles académiques HTTP/3 et QUIC, Robin Marx
  Mes travaux de recherche portent sur le multiplexage et la hiérarchisation des flux, les outils et les différences d'implémentation.
• QUIPS, EPIQ 2018 et EPIQ 2020
  Ces articles issus d'ateliers universitaires contiennent des recherches approfondies sur la sécurité, les performances et les extensions des protocoles.

Sur ce, je vous laisse, cher lecteur, avec une compréhension, espérons-le, bien améliorée de ce nouveau monde courageux. Je suis toujours ouvert aux commentaires, alors n'hésitez pas à me dire ce que vous pensez de cette série !