Get best of the week

Comparaison des performances HTTP / 3 et HTTP / 2



Chez Cloudflare, nous avons annoncé la prise en charge HTTP / 3 en septembre dernier alors que nous fêtions notre neuvième anniversaire . Notre objectif a toujours été d'améliorer Internet. La collaboration dans le domaine des normes est une partie importante du processus et nous avons la chance de participer au développement de HTTP / 3.

Bien que HTTP / 3 soit encore au stade de projet, nous avons remarqué un grand intérêt pour le nouveau protocole de nos utilisateurs (l'infrastructure Cloudflare dessert plus de 10% des sites Internet - environ Per.). À ce jour, plus de 113 000 zones ont activé la prise en charge HTTP / 3, et si vous avez un navigateur expérimental, vous pouvez maintenant accéder à ces zones en utilisant le nouveau protocole! C'est formidable que tant de personnes l'aient inclus: travailler sur HTTP / 3 d'un grand nombre de sites Web réels signifie que vous pouvez tester plus de propriétés différentes à partir de navigateurs.

Nous avons initialement lancé HTTP / 3 en partenariat avec Google, qui comprenait également un support expérimental pour Chrome Canary. Depuis lors, de plus en plus de navigateurs ont ajouté un support expérimental: il est apparu dans les versions de Firefox Nightly , dans divers navigateurs basés sur Chromium tels que Opera et Edge (via le moteur de base Chromium), et dans les versions préliminaires de Safari. Nous suivons de près ces développements et aidons partout où nous le pouvons. Le fait d'avoir un vaste réseau de sites qui ont activé HTTP / 3 offre aux développeurs de navigateurs un excellent terrain d'essai pour valider le code.

Quel est donc le statut actuel?


Le processus de normalisation de l'IETF implique une série de projets pour préparer un «projet final» prêt pour l'étiquetage en tant que norme RFC. Les membres de l'équipe QUIC travaillent ensemble sur l'analyse, la mise en œuvre et l'interopérabilité pour identifier les problèmes potentiels. Nous avons lancé la prise en charge du protocole au stade de la 23e version du projet, puis nous avons suivi toutes les modifications, et au moment de la rédaction (14 avril 2020), la dernière était la 27e version. Avec chaque ébauche, la qualité des définitions QUIC s'améliore et se rapproche d'un «consensus approximatif» sur la façon dont le protocole devrait se comporter. Pour éviter une analyse perpétuelle avec des paramètres sans cesse dopilivaniya à l'idéal, avec chaque nouvelle version du projet, la barre pour apporter des modifications à la spécification augmente. Cela signifie qu'avec chaque version, il y a moins de changements, et le RFC final correspondra étroitement au protocole que nous avons déjà lancé en production.

Avantages


L'un des principaux avantages de HTTP / 3 était l'augmentation des performances, en particulier lors de la demande de plusieurs objets simultanément. Dans HTTP / 2, toute interférence (perte de paquets) dans une connexion TCP bloque tous les flux à la fois (bloquant le début d'une ligne). Étant donné que HTTP / 3 est basé sur UDP, un seul flux est interrompu lorsqu'un paquet est perdu, mais pas tous.

De plus, HTTP / 3 prend en charge 0-RTT (zéro temps de réception-transmission), c'est-à-dire que les connexions suivantes peuvent démarrer beaucoup plus rapidement que la première, éliminant ainsi la nécessité de confirmer TLS à partir du serveur lors de l'établissement d'une connexion. Cela signifie que le client commence à demander des données beaucoup plus tôt qu'avec une négociation TLS complète, c'est-à-dire que le site Web commence à se charger plus tôt dans le navigateur.

Les animations ci-dessous montrent l'effet de la perte de paquets. Dans le premier exemple, des demandes sont reçues du client au serveur via HTTP / 2 pour recevoir deux ressources. Les demandes et les réponses associées sont colorées en vert et jaune. Les réponses sont divisées en plusieurs paquets. Hélas, un paquet est perdu - en conséquence, le transfert des deux ressources est retardé.



Dans le deuxième exemple, les demandes de deux ressources sont reçues via HTTP / 3. Un paquet est perdu, bloquant le transfert de la ressource jaune, mais sans affecter la verte.



Des améliorations dans la procédure de négociation d'une session signifient que les «connexions» avec les serveurs sont établies beaucoup plus rapidement, c'est-à-dire que les données arrivent plus rapidement dans le navigateur. Nous étions curieux de savoir à quel point cela se reflétait dans le trafic réel, nous avons donc effectué plusieurs tests. Pour évaluer la contribution du 0-RTT, nous avons lancé plusieurs tests de contrôle pour mesurer le temps jusqu'au premier octet (temps au premier octet, TTFB). En moyenne, sur HTTP / 3, le premier octet apparaît après 176 ms. Dans le cas de HTTP / 2, nous voyons 201 ms, c'est-à-dire que HTTP / 3 réduit ici le retard de 12,4%!



Fait intéressant, les projets et les RFC ne réglementent pas tous les aspects du protocole. Par exemple, la méthode de transfert de paquets affecte les performances.et algorithme de contrôle de la congestion du trafic. Le contrôle de congestion est une méthode d'adaptation aux réseaux encombrés côté client et côté serveur: lorsque des paquets sont perdus, la qualité de la communication diminue. Étant donné que QUIC est un nouveau protocole, l'expérimentation et le réglage sont nécessaires pour concevoir et mettre en œuvre correctement un système de gestion de surcharge.

En tant que point de départ simple et sûr, la spécification de détection de perte et de contrôle de congestion recommande l'algorithme Reno , mais tout autre peut être utilisé. Nous avons commencé avec l'algorithme New Reno , mais sur la base de l'expérience, nous avons supposé qu'il n'était pas optimal. Nous sommes récemment passés à CUBIC - Et dans un réseau avec des transmissions surdimensionnées et une plus grande perte de paquets, CUBIC a mieux performé que New Reno. Bientôt, nous en parlerons plus, restez à l'écoute pour une mise à jour du blog.

Dans la pile HTTP / 2 actuelle, nous avons BBR v1 (TCP). Cela signifie que les tests n'effectuent pas une comparaison exacte des pommes avec des pommes, car ces algorithmes de contrôle de la congestion se comportent différemment sur différentes tailles d'engins. Cependant, lors du passage de HTTP / 2 à HTTP / 3, nous constatons déjà une amélioration sur les petits sites. Dans de grandes zones, des performances brillantes sont montrées par notre pile HTTP / 2 finement réglée et optimisée.

Une petite page de test de 15K se charge en moyenne sur HTTP / 3 en 443 ms, contre 458 ms pour HTTP / 2. Mais si vous augmentez la taille de la page à 1 Mo, cet avantage disparaît: spécifiquement dans notre réseau, le protocole HTTP / 3 fonctionne désormais un peu plus lentement que HTTP / 2 - 2,33 s contre 2,30 s.







Les benchmarks synthétiques sont intéressants, mais il est intéressant de voir comment HTTP / 3 se montre dans le monde réel.

À titre de comparaison, nous voulions attirer un service tiers pouvant télécharger des sites de notre réseau, simulant un navigateur Web. WebPageTest est un cadre commun pour mesurer le temps de chargement des pages, avec de bons diagrammes en cascade (cascade). Pour analyser le backend, nous avons utilisé notre propre système Browser Insights , fixant les timings aux confins de notre réseau. Ensuite, ils ont connecté les deux parties par un peu d'automatisation.

Comme test pour mesurer les performances, nous avons pris notre propre blog . Nous avons configuré nos instances WebPageTest pour charger le site à partir d'emplacements à travers le monde, à la fois sur HTTP / 2 et sur HTTP / 3. Inclus HTTP / 3 et Browser Insights. Ainsi, chaque fois qu'un navigateur prenant en charge HTTP / 3 charge la page, des scripts de test demandent des données analytiques collectées à partir du navigateur. La même procédure a été répétée pour HTTP / 2 afin de pouvoir la comparer.

Le graphique suivant montre le temps de chargement de la page blog.cloudflare.com réelle avec une comparaison des métriques HTTP / 3 et HTTP / 2. Nous avons de telles mesures pour différents points géographiques.



Comme vous pouvez le voir, les performances HTTP / 3 sont toujours inférieures aux performances HTTP / 2. La différence est d'environ 1 à 4% en moyenne en Amérique du Nord. Résultats similaires en Europe, en Asie et en Amérique du Sud. Nous pensons que cela peut être dû à une différence dans les algorithmes de contrôle de la congestion: BBR v1 fonctionne sur HTTP / 2 et CUBIC sur HTTP / 3. À l'avenir, nous essaierons d'implémenter le même algorithme de contrôle de surcharge sur les deux protocoles afin d'obtenir une comparaison plus précise des pommes avec des pommes.

Conclusion


Dans l'ensemble, nous sommes très heureux d'aider à faire avancer la nouvelle norme. Notre implémentation tient bien, dans certaines situations montre de meilleures performances, et dans le pire des cas - HTTP / 2 similaire. Une fois la norme finalisée, nous attendons avec impatience que les navigateurs ajoutent la prise en charge HTTP / 3 dans les versions principales. Quant à nous, nous prendrons en charge les dernières versions et chercherons de nouvelles façons d'optimiser HTTP / 3 pour améliorer encore les performances, qu'il s'agisse de configurer le contrôle de l'encombrement, la priorisation ou la configuration du système (CPU et bande passante des canaux).

En attendant, si vous voulez essayer HTTP / 3 en action, il vous suffit de l'activer sur notre tableau de bord et de télécharger l'assemblage de test (Nightly, Canary) de l'un des principaux navigateurs. Consultez notre documentation pour les développeurs pour obtenir des instructions sur l'activation de HTTP / 3 .

More articles:


All Articles