Options de déploiement pratiques (partie 3) —

Après près de cinq ans de développement, le nouveau protocole HTTP/3 approche de sa forme finale. Examinons de près les défis liés au déploiement et au test de HTTP/3, et comment et si vous devez également modifier vos sites Web et vos ressources.

Bonjour et bienvenue dans le dernier volet de cette série en trois parties sur les nouveaux protocoles HTTP/3 et QUIC ! Si après les deux parties précédentes — HTTP/3 history and core concepts et HTTP/3 performance features — 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 tout ce que 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 facilité partie). 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 sur les performances des nouveaux protocoles (c'est la partie presque impossible, du moins pour le moment).

Cette série est divisée en trois parties :

1. HTTP/3 histoire et concepts de base
   Ceci s'adresse aux personnes qui découvrent HTTP/3 et les protocoles en général, et il aborde principalement les bases.
2. Caractéristiques de performances HTTP/3
   C'est plus approfondi et technique. Les personnes qui connaissent déjà les bases peuvent commencer ici.
3. Options de déploiement HTTP/3 pratiques (article actuel)
   Cela explique les défis liés au déploiement et au test de HTTP/3 vous-même. Il détaille comment et si vous devez également modifier vos pages Web et vos ressources.

Modifications apportées aux pages et aux ressources

Commençons par quelques bonnes nouvelles : Si vous êtes déjà sur HTTP/2, vous avez probablement gagné n'avez rien à modifier sur vos pages ou ressources lors du passage à HTTP/3 !. En effet, comme nous l'avons expliqué dans partie 1 et partie 2HTTP/3 ressemble plus à HTTP/2-over-QUIC, et les fonctionnalités de haut niveau de les deux versions sont restées les mêmes. En tant que tel, toutes les modifications ou optimisations apportées pour HTTP/2 fonctionneront 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 vous n'avez jamais vraiment modifié les choses pour HTTP/2, alors vous pourriez vous demander 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 . C'est parce que, comme je l'ai dit dans l'introduction de la partie 1une grande partie du contenu HTTP/2 initial était trop optimiste quant à son efficacité dans la pratique, et une partie, très franchement, avait des erreurs et 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 peux recommander en ce moment est le livre [19659014]HTTP/2 en action de Barry Pollard. Cependant, étant donné qu'il s'agit d'une ressource payante et que je ne veux pas que vous restiez en train de deviner ici, j'ai énuméré quelques-uns des principaux points ci-dessous, 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 partie 2 comment 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 provoquer une perte de paquets plus importante ou plus précoce avec plus de connexions (ce qui annule les avantages de leur agrégation plus rapide début). HTTP/3 continue 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 fusion de connexion

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

En tant que tel, la recommandation initiale était de annuler le sharding de serveur et consolider autant que possible les ressources sur un seul serveur. HTTP/2 a même fourni une fonctionnalité pour faciliter la transition à partir d'une configuration HTTP/1.1, appelée connection coalescing. En gros, si deux noms d'hôte se résolvent sur 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 sur les deux noms d'hôte.

En pratique, la connexion la fusion peut être difficile à obtenir par exemple en raison de plusieurs problèmes de sécurité subtils impliquant CORS. Même si vous le configurez correctement, vous pourriez toujours vous retrouver facilement avec deux connexions distinctes. Le truc, c'est que ce n'est pas toujours mal. 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 d'en utiliser deux ou plus. Deuxièmement, l'utilisation d'un trop grand nombre de connexions pourrait entraîner une perte de paquets prématurée en raison de contrôleurs de congestion concurrents. Cependant, en utiliser 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 sharding 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 qu'elles le font, car elles ont encore quelques connexions supplémentaires ou des charges tierces dans leur chemin critique.

3. Regroupement et intégration de ressources

Dans HTTP/1.1, vous ne pouviez avoir qu'une seule ressource active par connexion, entraînant un blocage en tête de ligne (HoL) au niveau HTTP. Étant donné que le nombre de connexions était limité à 6 à 30, le regroupement de ressources (où des sous-ressources plus petites sont combinées en une seule ressource plus importante) était une bonne pratique de longue date. On le voit encore aujourd'hui dans les bundlers comme 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, vous pouvez donc avoir beaucoup plus de demandes de fichiers en suspens (mettre autrement, une seule requête n'occupe plus l'une de vos quelques précieuses connexions). Cela a été initialement interprété comme « 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 précise, car chaque sous-ressource pouvait être mise en cache individuellement et l'ensemble complet n'avait pas besoin d'être téléchargé à nouveau si l'une d'entre elles changeait. C'est vrai, mais seulement dans une mesure relativement limitée.

Par exemple, vous pourriez réduire l'efficacité de la compressioncar 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'élever, disons, à des centaines de petits fichiers par rapport à quelques gros. Dans nos propres 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 incorporer 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 êtes toujours mieux incorporant certains de vos CSS critiques . Peut-être qu'un jour la Proposition de regroupements de ressources vous aidera, mais pas encore.

Tout cela est, bien sûr, toujours vrai pour HTTP/3. Pourtant, j'ai lu que des gens prétendent que de nombreux petits fichiers seraient meilleurs que QUIC, car 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 partie 2 ). Je pense qu'il y a peut-être une part de vérité à cela, mais, comme nous l'avons également vu dans la partie 2, il s'agit d'un problème très complexe avec de nombreux paramètres mobiles. Je ne pense pas que les avantages l'emporteraient sur les autres coûts discuté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 bundler de ressources qui le fait. ;))

4. Priorisation

Pour pouvoir télécharger plusieurs fichiers sur une seule connexion, vous devez les multiplexer d'une manière ou d'une autre. Comme discuté dans part 2en HTTP/2, ce multiplexage est piloté à l'aide de 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 – pour pouvoir les hiérarchiser correctement les unes par rapport aux autres ! Comme nous l'avons également vu, cependant, ce système était très complexece qui le rendait souvent mal utilisé et mis en œuvre dans la pratique (voir l'image ci-dessous). Ceci, à son tour, a signifié que d'autres recommandations pour HTTP/2 – telles que le regroupement réduit, car les requêtes sont bon marché et le partitionnement de serveur réduit, pour utiliser de manière optimale la connexion unique (voir ci-dessus) – se sont avérées sous-performantes dans pratique.

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 chances de priorités concurrentes) et en utilisant toujours le sharding (limité). Une autre option consiste à utiliser diverses techniques d'influence sur la priorité, telles que lazy loadingJavaScript async et deferet des conseils de ressources tels que preload[19659033]. 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 à imposer un préchargement sur un tas de ressources et à accélérer les choses : si tout est soudainement prioritaire, alors rien ne l'est ! Il est même très facile de retarder des ressources réellement critiques en utilisant des choses comme preload.

Comme également expliqué dans partie 2HTTP/3 modifie fondamentalement les éléments internes 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 hiérarchisation ne changeront pas. Vous ne pourrez toujours pas utiliser des techniques telles que preload sans vraiment comprendre ce qui se passe en interne, car cela pourrait toujours donner une mauvaise priorité à vos ressources.

5. Server Push et First Flight

Server Push permet à un serveur d'envoyer des données de réponse sans attendre au préalable une demande du client. Encore une fois, cela semble très bien en théorie, et cela pourrait être utilisé au lieu d'incorporer des ressources (voir ci-dessus). Cependant, comme indiqué dans partie 2le push est très difficile à utiliser correctement en raison de problèmes de contrôle de congestion, de mise en cache, de hiérarchisation et de mise en mémoire tampon. Dans l'ensemble, il vaut mieux ne pas l'utiliser pour le chargement général de pages Web à moins que vous vraiment savez ce que vous faites, et même alors ce serait probablement une micro-optimisation. Je pense toujours qu'il pourrait avoir une place avec les API (REST), cependant, où vous pouvez pousser les sous-ressources liées à la réponse (JSON) sur une connexion réchauffée. Cela est vrai à la fois 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 0-RTT, que ce soit sur TCP + TLS ou via QUIC. Comme indiqué dans partie 2 0-RTT est similaire au serveur push (tel qu'il est généralement utilisé) en ce sens qu'il essaie 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, en raison de problèmes 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 en tirer vraiment parti. 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 signifie ?

Tout ce qui précède se résume à une règle simple : 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. Shard ressources sur environ une à trois connexions sur le chemin critique (sauf si vos utilisateurs sont principalement sur des réseaux à faible bande passante), en utilisant preconnect et dns-prefetch si nécessaire.
2. Regroupez les sous-ressources logiquement par chemin ou caractéristique, ou par fréquence de changement. Cinq à dix ressources JavaScript et cinq à dix ressources CSS par page devraient suffire. L'incorporation de CSS critiques peut toujours être une bonne optimisation.
3. Utilisez des fonctionnalités complexes, telles que preloadavec parcimonie.
4. Utilisez un serveur qui prend en charge correctement la hiérarchisation HTTP/2. Pour HTTP/2, je recommande H2O. Apache et NGINX sont pour la plupart OK (bien que pourrait faire mieux), tandis que Node.js doit être évité 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. Cependant, ce qui sera plus difficile, c'est de configurer correctement les serveurs, les clients et les outils HTTP/3.

Serveurs et réseaux

Comme vous le comprenez probablement maintenant, QUIC et HTTP/3 sont des protocoles assez complexes. Les mettre en œuvre à partir de zéro 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 plusieurs options matures et stables parmi lesquelles choisir.

Certaines des plus importantes et des plus stables. les plus stables incluent les suivantes :

Cependant, beaucoup (peut-être la plupart) de ces implémentations s'occupent principalement de HTTP/3 et de QUIC ; ils 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. Tout d'abord, peu de leurs développeurs ont été impliqués dans HTTP/3 dès le départ, 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 à QUICce que leurs développeurs ont longtemps été réticents ou lents à faire. Le problème ici en particulier est OpenSSL, qui a un support QUIC reportémais il est également utilisé par de nombreux serveurs. Ce problème est devenu si grave qu'Akamai a décidé de démarrer 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 bloqueur pour de nombreux serveurs, et elle devrait le rester pendant un certain temps.

Une liste partielle de serveurs Web complets que vous devriez être en mesure d'utiliser immédiatement, ainsi que leur prise en charge HTTP/3 actuelle :

Notez quelques nuances importantes :

• Même « prise en charge complète » 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 pleinement en charge la migration de connexion, 0-RTT, le push de serveur ou la priorisation HTTP/3.
• D'autres serveurs non répertoriés, tels que Tomcat, ont (à ma connaissance ) n'a pas encore fait d'annonce.
• Parmi les serveurs Web répertoriés, seuls Litespeed, le correctif NGINX de Cloudflare et H2O ont été créés par des personnes étroitement impliquées dans la normalisation QUIC et HTTP/3, il est donc probable qu'ils fonctionnent mieux dès le début.[19659063]Comme vous pouvez le voir, le paysage des serveurs n'est pas encore complètement là, mais il existe certainement déjà des options pour configurer un serveur HTTP/3. Cependant, la simple exécution du 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 partie 1QUIC s'exécute sur le protocole UDP pour faciliter le déploiement. Cependant, cela signifie principalement 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 n'est pas essentiel au travail quotidien normal en dehors du DNS, de nombreux réseaux (d'entreprise) et pare-feu 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 s'attend à 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 UDP en gros. Au lieu de cela, ils voudront spécifiquement autoriser QUIC sur UDP. Le problème, c'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 y a-t-il de connexions ouvertes ?) Comme nous l'avons vu dans partie 1c'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.

  En tant que tels, de nombreux Les 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 à la connexion de continuer à partir d'une nouvelle adresse IP sans avoir à effectuer une nouvelle poignée de main, grâce à l'utilisation d'ID 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 uniquement utiliser les CID QUIC, 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 pour lequel les CID sont attendus mais aucune de ces choses n'existe encore.

  Il existe des préoccupations similaires pour les équilibreurs de charge à plus grande échelle. mises en place. Ces machines distribuent les connexions entrantes sur un grand nombre de serveurs principaux. Le trafic d'une connexion doit, bien entendu, 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-tuplecar 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 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 configurer cela (bien que cela soit loin d'être largement mis en œuvre).

  Enfin, il existe d'autres considérations de sécurité de plus haut niveau, principalement autour de 0 - RTT et attaques par déni de service distribué (DDoS). Comme discuté dans partie 2QUIC 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 de périphérie peuvent empêcher certaines requêtes 0-RTT d'atteindre les back-ends réels pour empêcher les attaques par rejeu. 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é SYN flood dans TCP), QUIC inclut la fonction retry. 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). Ce processus de nouvelle tentative se produit bien sûr 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 être configurée.

  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 certains dont j'ai parlé . Il existe également deux documents d'accompagnement distincts pour les RFC QUIC qui traitent de ces problèmes et de leurs possibles atténuations (partielles).

  Qu'est-ce que tout cela signifie ?

  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 écoutebien que vous disposiez déjà de certaines 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 (comme 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é de manière sécurisée et optimale, sera non 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. configurer les protocoles pour vous. Comme discuté dans partie 2 c'est là que QUIC est le plus susceptible de porter ses fruits de toute façon, et l'utilisation d'un CDN est l'une des optimisations de performances clés 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 disposeront des implémentations les plus avancées et les mieux ajustées disponibles.

  Clients et QUIC Discovery

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

  Avant d'en venir à cela, commençons par une bonne nouvelle : La plupart des navigateurs populaires ont déjà un support (expérimental) HTTP/3 ! 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 indicateur manuel. Sera activé par défaut dans la version 15, qui est actuellement en préversion technologique.
  • Autres navigateurs : aucun signal à ma connaissance pour le moment (bien que d'autres navigateurs qui utilisent Chromium en interne, tels que Brave, pourraient, en théorie, commencez également à l'activer).

  Notez quelques nuances :

  • La plupart des navigateurs se déploient progressivement, de sorte que tous les utilisateurs n'obtiendront pas 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 deviennent surchargés. En tant que tel, il y a une petite chance que, même dans les versions récentes du navigateur, vous n'obtenez pas HTTP/3 par défaut et devrez l'activer manuellement.
  • Comme pour les serveurs, 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, serveur push, 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 la prise en charge native de HTTP/3 et QUIC à ses bibliothèques 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 utilisez un navigateur mis à jour, vous pourrait ê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é de naviguer sur example.com (un site Web que vous n'avez jamais visité auparavant), et vous avez utilisé DNS pour résoudre ce problème en une adresse IP. Vous envoyez un ou plusieurs paquets d'établissement de liaison QUIC à cette adresse IP. Maintenant, plusieurs choses peuvent mal se passer :

  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 d'établissement de liaison peuvent être perdus en transit.[19659052]Cependant, comment sauriez-vous (lequel) de ces problèmes s'est produit ? Dans les trois cas, vous ne recevrez jamais de réponse à 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 essayez d'ouvrir une connexion TCP au serveur, en espérant que HTTP/2 ou HTTP/1.1 fonctionnera.

     Comme vous pouvez le voir, ce type d'approche pourrait introduire des retards importants, en particulier au cours de la première année. (s) lorsque de nombreux serveurs et réseaux ne prennent pas encore en charge QUIC. Une solution simple mais naïve consisterait simplement à ouvrir à la fois une connexion QUIC et TCP en même temps, puis d'utiliser la poignée de main qui se termine en premier . Cette méthode est appelée « course de connexion » ou « globes oculaires heureux ». Bien que cela soit certainement possible, cela a 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 par rejeu discutées précédemment (que mon exposé couvre plus en détail).

     Comme Ainsi, pour QUIC et HTTP/3, les navigateurs préfèrent jouer la sécurité et n'essayent 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 sur une connexion TCP. Le serveur peut alors informer le 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 est appelé Alt-Svcce qui signifie « alternative services ». Alt-Svc peut être utilisé pour informer 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.

     

     À la réception d'un en-tête Alt-Svc valide indiquant la prise en charge de HTTP/3, le navigateur mettra en cache cela et essaiera de configurer une connexion QUIC à partir de là. 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 téléchargé au moins quelques ressources via HTTP/2 ou HTTP/1.1 d'abord. Even then, it’s not smooth sailing. The browser now knows that the server supports HTTP/3, but that doesn’t mean the intermediate network won’t block it. As such, connection racing is still needed in practice. So, you might still end up with HTTP/2 if the network somehow delays the QUIC handshake enough. Additionally, if the QUIC connection fails to establish a few times in a row, some browsers will put the Alt-Svc cache entry on a denylist for some time, not trying HTTP/3 for a while. As such, it can be helpful to manually clear your browser’s cache if things are acting up because that should also empty the Alt-Svc bindings. Finally, Alt-Svc has been shown to pose some serious security risks. For this reason, some browsers pose extra restrictions on, for instance, which ports can be used (in Chrome, your HTTP/2 and HTTP/3 servers need to be either both on a port below 1024 or both on a port above or equal to 1024, otherwise Alt-Svc will be ignored). All of this logic varies and evolves wildly between browsers, meaning that getting consistent HTTP/3 connections can be difficultwhich also makes it challenging to test new set-ups.

     There is ongoing work to improve this two-step Alt-Svc process somewhat. The idea is to use new DNS records called SVCB and HTTPSwhich will contain information similar to what is in Alt-Svc. As such, the client can discover that a server supports HTTP/3 during the DNS resolution step insteadmeaning that it can try QUIC from the very first page load instead of first having to go through HTTP/2 or HTTP/1.1. For more information on this and Alt-Svcsee last year’s Web Almanac chapter on HTTP/2.

     As you can see, Alt-Svc and the HTTP/3 discovery process add a layer of complexity to your already challenging QUIC server deployment, because:

     • you will always need to deploy your HTTP/3 server next to an HTTP/2 and/or HTTP/1.1 server;
     • you will need to configure your HTTP/2 and HTTP/1.1 servers to set the correct Alt-Svc headers on their responses.

     While that should be manageable in production-level set-ups (because, for example, a single Apache or NGINX instance will likely support all three HTTP versions at the same time), it might be much more annoying in (local) test set-ups (I can already see myself forgetting to add the Alt-Svc headers or messing them up). This problem is compounded by a (current) lack of browser error logs and DevTools indicators, which means that figuring out why exactly the set-up isn’t working can be difficult.

     Additional Issues

     As if that wasn’t enough, another issue will make local testing more difficult: Chrome makes it very difficult for you to use self-signed TLS certificates for QUIC. This is because non-official TLS certificates are often used by companies to decrypt their employees’ TLS traffic (so that they can, for example, have their firewalls scan inside encrypted traffic). However, if companies would start doing that with QUIC, we would again have custom middlebox implementations that make their own assumptions about the protocol. This could lead to them potentially breaking protocol support in the future, which is exactly what we tried to prevent by encrypting QUIC so extensively in the first place! 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 certificateyou 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.

     What Does It All Mean?

     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 discussedthere 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 serversswitching 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.

     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.

     Google Lighthouse

     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 wayin 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 seenis 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 knowledgenot 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.comenabling the “repeat view” option. As explained aboveI 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 89this 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 aboveeven 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 Chromewe 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 wellswitching 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 aboveboth 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.netbut 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’tChrome, 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 featurewhich 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 yearso I wouldn’t wait for HTTP/3 arriving anytime soon.

     Wireshark, qlog and qvis

     As the discussion above shows, it can be tricky to analyze HTTP/3 behavior by just using Lighthouse or WebPageTest at this point. Luckily, other lower-level tools are available to help with this. First, the excellent Wireshark tool has advanced support for QUIC, and it can experimentally dissect HTTP/3 as well. This allows you to observe which QUIC and HTTP/3 packets are actually going over the wire. However, in order for that to work, you need to obtain the TLS decryption keys for a given connection, which most implementations (including Chrome and Firefox) allow you to extract by using the SSLKEYLOGFILE environment variable. While this can be useful for some things, really figuring out what’s happening, especially for longer connections, could entail a lot of manual work. You would also need a pretty advanced understanding of the protocols’ inner workings.

     Luckily, there is a second option, qlog and qvis. qlog is a JSON-based logging format specifically for QUIC and HTTP/3 that is supported by the majority of QUIC implementations. Instead of looking at the packets going over the wire, qlog captures this information on the client and server directly, which allows it to include some additional information (for example, congestion control details). Typically, you can trigger qlog output when starting servers and clients with the QLOGDIR environment variable. (Note that in Firefox, you need to set the network.http.http3.enable_qlog preference. Apple devices and Safari use QUIC_LOG_DIRECTORY instead. Chrome doesn’t yet support qlog.)

     These qlog files can then be uploaded to the qvis tool suite at qvis.quictools.info. There, you’ll get a number of advanced interactive visualizations that make it easier to interpret QUIC and HTTP/3 traffic. qvis also has support for uploading Wireshark packet captures (.pcap files), and it has experimental support for Chrome’s netlog filesso you can also analyze Chrome’s behavior. A full tutorial on qlog and qvis is beyond the scope of this article, but more details can be found in tutorial formas a paperand even in talk-show format. You can also ask me about them directly because I’m the main implementer of qlog and qvis. 😉

     However, I am under no illusion that most readers here should ever use Wireshark or qvis, because these are quite low-level tools. Still, as we have few alternatives at the moment, I strongly recommend not extensively testing HTTP/3 performance without using this type of toolto make sure you really know what’s happening on the wire and whether what you’re seeing is really explained by the protocol’s internals and not by other factors.

     What Does It All Mean?

     As we’ve seen, setting up and using HTTP/3 over QUIC can be a complex affair, and many things can go wrong. Sadly, no good tool or visualization is available that exposes the necessary details at an appropriate level of abstraction. This makes it very difficult for most developers to assess the potential benefits that HTTP/3 can bring to their website at this time or even to validate that their set-up works as expected.

     Relying only on high-level metrics is very dangerous because these could be skewed by a plethora of factors (such as unrealistic network emulation, a lack of features on clients or servers, only partial HTTP/3 usage, etc.). Even if everything did work better, as we’ve seen in part 2the differences between HTTP/2 and HTTP/3 will likely be relatively small in most cases, which makes it even more difficult to get the necessary information from high-level tools without targeted HTTP/3 support.

     As such, I recommend leaving HTTP/2 versus HTTP/3 performance measurements alone for a few more months and focusing instead on making sure that our server-side set-ups are functioning as expected. For this, it’s easiest to use WebPageTest in combination with Google Chrome’s command-line parameters, with a fallback to curl for potential issues — this is currently the most consistent set-up I can find.

     Conclusion and Takeaways

     Dear reader, if you’ve read the full three-part series and made it here, I salute you! Even if you’ve only read a few sections, I thank you for your interest in these new and exciting protocols. Now, I will summarize the key takeaways from this series, provide a few key recommendations for the coming months and year, and finally provide you with some additional resources, in case you’d like to know more.

     Summary

     First, in part 1we discussed that HTTP/3 was needed mainly because of the new underlying QUIC transport protocol. QUIC is the spiritual successor to TCP, and it integrates all of its best practices, as well as TLS 1.3. This was mainly needed because TCP, due to its ubiquitous deployment and integration in middleboxes, has become too inflexible to evolve. QUIC’s usage of UDP and almost full encryption means that we (hopefully) only have to update the endpoints in the future in order to add new features, which should be easier. QUIC, however, also adds some interesting new capabilities. First, QUIC’s combined transport and cryptographic handshake is faster than TCP + TLS, and it can make good use of the 0-RTT feature. Secondly, QUIC knows it is carrying multiple independent byte streams and can be smarter about how it handles loss and delays, mitigating the head-of-line blocking problem. Thirdly, QUIC connections can survive users moving to a different network (called connection migration) by tagging each packet with a connection ID. Finally, QUIC’s flexible packet structure (employing frames) makes it more efficient but also more flexible and extensible in the future. In conclusion, it’s clear that QUIC is the next-generation transport protocol and will be used and extended for many years to come.

     Secondly, in part 2we took a bit of a critical look at these new features, especially their performance implications. First, we saw that QUIC’s use of UDP doesn’t magically make it faster (nor slower) because QUIC uses congestion control mechanisms very similar to TCP to prevent overloading the network. Secondly, the faster handshake and 0-RTT are more micro-optimizations, because they are really only one round trip faster than an optimized TCP + TLS stack, and QUIC’s true 0-RTT is further affected by a range of security concerns that can limit its usefulness. Thirdly, connection migration is really only needed in a few specific cases, and it still means resetting send rates because the congestion control doesn’t know how much data the new network can handle. Fourthly, the effectiveness of QUIC’s head-of-line blocking removal severely depends on how stream data is multiplexed and prioritized. Approaches that are optimal to recover from packet loss seem detrimental to general use cases of web page loading performance and vice versa, although more research is needed. Fifthly, QUIC could easily be slower to send packets than TCP + TLS, because UDP APIs are less mature and QUIC encrypts each packet individually, although this can be largely mitigated in time. Sixthly, HTTP/3 itself doesn’t really bring any major new performance features to the table, but mainly reworks and simplifies the internals of known HTTP/2 features. Finally, some of the most exciting performance-related features that QUIC allows (multipath, unreliable data, WebTransport, forward error correction, etc.) are not part of the core QUIC and HTTP/3 standards, but rather are proposed extensions that will take some more time to be available. In conclusion, this means QUIC will probably not improve performance much for users on high-speed networks, but will mainly be important for those on slow and less-stable networks.

     Finally, in this part 3we looked at how to practically use and deploy QUIC and HTTP/3. First, we saw that most best practices and lessons learned from HTTP/2 should just carry over to HTTP/3. There is no need to change your bundling or inlining strategy, nor to consolidate or shard your server farm. Server push is still not the best feature to use, and preload can similarly be a powerful footgun. Secondly, we’ve discussed that it might take a while before off-the-shelf web server packages provide full HTTP/3 support (partly due to TLS library support issues), although plenty of open-source options are available for early adopters and several major CDNs have a mature offering. Thirdly, it’s clear that most major browsers have (basic) HTTP/3 support, even enabled by default. There are major differences in how and when they practically use HTTP/3 and its new features, though, so understanding their behavior can be challenging. Fourthly, we’ve discussed that this is worsened by a lack of explicit HTTP/3 support in popular tools such as Lighthouse and WebPageTest, making it especially difficult to compare HTTP/3 performance to HTTP/2 and HTTP/1.1 at this time. In conclusion, HTTP/3 and QUIC are probably not quite ready for primetime yet, but they soon will be.

     Recommendations

     From the summary above, it might seem like I am making strong arguments against using QUIC or HTTP/3. However, that is quite opposite to the point I want to make.

     First, as discussed at the end of part 2even though your “average” user might not encounter major performance gains (depending on your target market), a significant portion of your audience will likely see impressive improvements. 0-RTT might only save a single round trip, but that can still mean several hundred milliseconds for some users. Connection migration might not sustain consistently fast downloads, but it will definitely help people trying to fetch that PDF on a high-speed train. Packet loss on cable might be bursty, but wireless links might benefit more from QUIC’s head-of-line blocking removal. What’s more, these users are those who would typically encounter the worst performance of your product and, consequently, be most heavily affected by it. If you wonder why that matters, read Chris Zacharias’ famous web performance anecdote.

     Secondly, QUIC and HTTP/3 will only get better and faster over time. Version 1 has focused on getting the basic protocol done, keeping more advanced performance features for later. As such, I feel it pays to start investing in the protocols now, to make sure you can use them and the new features to optimal effect when they become available down the line. Given the complexity of the protocols and their deployment aspects, it would be good to give yourself some time to get acquainted with their quirks. Even if you don’t want to get your hands dirty quite yet, several major CDN providers offer mature “flip the switch” HTTP/3 support (particularly, Cloudflare and Fastly). I struggle to find a reason not to try that out if you’re using a CDN (which, if you care about performance, you really should be).

     As such, while I wouldn’t say that it’s crucial to start using QUIC and HTTP/3 as soon as possible, I do feel there are plenty of benefits already to be had, and they will only increase in the future.

     Further Reading

     While this has been a long body of text, sadly, it really only scratches the technical surface of the complex protocols that QUIC and HTTP/3 are.

     Below you will find a list of additional resources for continued learning, more or less in order of ascending technical depth:

     • “HTTP/3 Explained,” Daniel Stenberg
       This e-book, by the creator of cURL, summarizes the protocol.
     • “HTTP/2 in Action,” Barry Pollard
       This excellent all-round book on HTTP/2 has reusable advice and a section on HTTP/3.
     • @programmingartTwitter
       My tweets are mostly dedicated to QUIC, HTTP/3, and web performance (including news) in general. See for example my recent threads on QUIC features.
     • “YouTube,” Robin Marx
       My over 10 in-depth talks cover various aspects of the protocols.
     • “The Cloudlare Blog”
       This is the main product of a company that also runs a CDN on the side.
     • “The Fastly Blog”
       This blog has excellent discussions of technical aspects, embedded in the wider context.
     • QUICthe actual RFCs
       You’ll find links to the IETF QUIC and HTTP/3 RFC documents and other official extensions.
     • IIJ Engineers Blog: Excellent deep technical explanations of QUIC feature details.
     • HTTP/3 and QUIC academic papers, Robin Marx
       My research papers cover stream multiplexing and prioritization, tooling, and implementation differences.
     • QUIPSEPIQ 2018and EPIQ 2020
       These papers from academic workshops contain in-depth research on security, performance, and extensions of the protocols.

     With that, I leave you, dear reader, with a hopefully much-improved understanding of this brave new world. I am always open to feedbackso please let me know what you think of this series!

     This series is divided into three parts:

     1. HTTP/3 history and core concepts
        This is targeted at people new to HTTP/3 and protocols in general, and it mainly discusses the basics.
     2. HTTP/3 performance features
        This is more in-depth and technical. People who already know the basics can start here.
     3. Practical HTTP/3 deployment options (current article)
        This explains the challenges involved in deploying and testing HTTP/3 yourself. It details how and if you should change your web pages and resources as well.
     (vf, il, al)