Auteur Sujet: Comparatif des performances HTTP/2 vs HTTP/1.1 en fonction de la latence/pertes (Lu 2329 fois)

vivien · « **le:** 15 mai 2022 à 18:00:52 »

Hors-sujet extrait de HTTP/2 enfin disponible sur le forum

Citation de: kgersen le 10 mai 2022 à 23:18:28

Par contre dans la plupart des implémentations HTTP/2 est souvent moins performant en débit brut que HTTP/1. Donc pour du téléchargement web par exemple on utilise souvent encore plutôt du HTTP/1 en attendant HTTP/3.

J'ai réalisés des tests pour en savoir plus.

Pour ces tests, le client et le serveur (tous les deux avec Ubuntu 22.04 server) sont connectés directement par un lien de 1 Gb/s Ethernet. Le client et le serveur sont l'un contre l'autre. Je simule latence, perte de paquets et utilise différent protocoles (http1.1 vs http2 et Cubic vs BBR). Le fichier téléchargé est un fichier de 250 Mio et le test s’arrête après 10 secondes.

Je mixte toutes ces combinaisons de tests :
- Je test avec les protocoles suivants : HTTP1.1 ; HTTP/2
- Je test avec les pertes de paquets suivantes: 0,000% ; 0,005% ; 0,01% ; 0,02% ; 0,05% ; 0,1% ; 0,2% ; 0,5% ; 1% ; 2% ; 5% ; 10%
- Je teste avec les latences suivantes : 0ms ; 1ms ; 2ms ; 4ms ; 8ms ; 16ms ; 32ms ; 64ms ; 128ms ; 256ms ; 512ms ; 1024ms
- Je test avec les protocoles d'évitement de la congestion suivant :Cubic ; BBR

Voici les données brutes de mes 53 830 tests : 202205_debit_fichier_250mio_10sec.ods

Je reviendrais vers vous avec des graphiques analysant les données plus tard (spoiler : les débits s'effondrent avec Cubic quand il y a des pertes de paquets)

kgersen · « **Réponse #1 le:** 15 mai 2022 à 20:25:08 »

quand je parlais de différence entre http/1 et http/2 en téléchargement c'est plus quand on attend les limites des cpu (dans la plupart des implémentations http/2 demande plus de cpu que http/1, hors opti style sendfile + ktls).

Je ne suis pas certain que des tests sur un lien de 1Gbps donnent grand chose.

Pour ce qui est de la latence ou perte de paquets, 'tcp' reste le même et ne dépend pas de la version d'HTTP donc pas grand chose a voir non plus la (du moins pas grand chose de spécifique a "HTTP2 vs HTTP1" en utilisant qu'un flux TCP).

vivien · « **Réponse #2 le:** 15 mai 2022 à 21:23:33 »

Deux éditeurs d'outil de test de débit pour mobile m'ont fait des retours sur des baisse de débit en HTTP/2 vs HTTP1.1 (il y en a un qui voi le problème uniquement en upload, d'autre en download et upload)

J'ai pensé à une problématique coté client, mais la problème serait lié à H2WindowSize : https://httpd.apache.org/docs/2.4/fr/mod/mod_http2.html#h2windowsize

Finalement, on pense avoir trouvé une piste intéressante hier soir. Déjà on a pu identifier que c’était une problématique serveur et non outil, en créant une page php pour faire du test directement sur le serveur sans passer par 5Gmark. Et on a reproduit le souci.

Ensuite, on a pu voir que la problématique serait au niveau du paramètre H2WindowsSize qui, par défaut est à 65536, ce qui est trop faible. Là on est en train de tester plusieurs valeurs pour essayer de trouver la valeur optimale.

Bref, je veut comprendre le problème.

kgersen · « **Réponse #3 le:** 16 mai 2022 à 13:33:03 »

Il y a le même souci avec Go mais qu'au dela de plusieurs Gbps, ce n'est pas visible en dessous. Cela affecte NSpeed.

J'ai ouvert un ticket https://github.com/golang/go/issues/47840 a ce sujet le 20 août 21, ils ont mal compris le problème et j'ai du relancer le ticket dans un forum Go pour qu'ils daignent enfin admettre le problème le 8 novembre 2021.
Il y a un problème de négociation et adaptation de la "http2 receiver frame size" dans le code Go (je ne sais pas si c'est le meme parametre que toi). Le code de HTTP/2 est complexe et le dev principal du code HTTP de Go est parti de chez Google pour co-fonder Tailscale ... Je ne suis pas certain qu'ils est un remplaçant du même calibre. $:-\$
Vu que Go est open source, une personne externe a Google a proposer un premier patch pour pouvoir spécifier la fenêtre en paramètre,cela résout un peu le problème mais pas complètement. Mais ce patch n'est pas encore accepté par la code review de la team Go et en attente depuis le 9 décembre... Il faut donc utiliser une version perso de Go et y appliqué ce patch (c'est faisable mais ca complique la génération des binaires de nspeed).

C'est clairement pas une priorité interne pour Google car le problème n'est visible qu'a tres tres haut débit et ne concerne que tres peu de cas. La team Go a l'air sous-dimensionné et surchargé donc je ne suis pas sur que cela soit corrigé un jour (il a plus de 5000 tickets ouverts pour Go...)

il y a 2 personnes et une cinquantaine de contributeurs impliqués dans la mise en oeuvre de QUIC et HTTP3 pour Go: https://github.com/lucas-clemente/quic-go Curieusement ce repo n'est pas sur un compte officiel de Google mais sur le compte perso d'un dev employé de Google... J'attend une stabilité de ce code pour l'intégrer a NSPeed.

A noter que la plupart des distro Linux ont une limité génante pour udp: https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size qui peut expliquer les mauvaises performances de QUIC/HTTP3 en reception.

vivien · « **Réponse #4 le:** 17 mai 2022 à 16:15:56 »

Sans être limité par le CPU, je confirme qu'il n'y a pas de baisse de performance avec HTTP/2 pour un débit de 1 Gb/s.

Après avoir menu plus de 58 000 tests de téléchargement d'un fichier de 250 Mio dans des conditions variées de latence et de perte de paquets, je peut même observer que en moyenne, HTTP/2 est même environ 100 Kb/s plus rapide que HTTP/1.1 (100 Kb/s pour une connexion 1 Gb/s).

L'agrégation des résultats en fonctions des conditions de test :

vivien · « **Réponse #5 le:** 17 mai 2022 à 16:23:38 »

Les caractéristiques du test (fichier de 250 Mio pendant une durée de 10 secondes) et la configuration du serveur est au plus proche de l’enquête Arcep sur le mobile 2022 (pour mettre à jour la carte https://monreseaumobile.arcep.fr/) excepté la version d'Ubuntu qui est Ubuntu 22.04 LTS (c'est Ubuntu 20.04 LTS pour la campagne 2022).

Le client et le serveur sont reliés directement entre eux pas un câble Ethernet de 2m.

La latence et les pertes de paquets sont injectés avec NetEM, cf Tutoriel pour générer des pertes de paquets / latence / gigue sur un équipement avec NetEm.

La configuration du serveur : (Le serveur web est Apache, les fichiers de tests sont placés en ramdisque afin de ne pas être limité par les E/S disque)

La configuration du client : (le client est Curl)

kgersen · « **Réponse #6 le:** 17 mai 2022 à 17:25:13 »

Citation de: vivien le 17 mai 2022 à 16:15:56

Après avoir menu plus de 58 000 tests de téléchargement d'un fichier de 250 Mio dans des conditions variées de latence et de perte de paquets, je peut même observer que en moyenne, HTTP/2 est même environ 100 Kb/s plus rapide que HTTP/1.1 (100 Kb/s pour une connexion 1 Gb/s).

C'est sans surprise pour un test limité a 1Gbps et un fichier de 250 Mo.

De plus, en HTTP/1.1 Curl utilise son propre code qui date, en HTTP/2 Curl utilise https://nghttp2.org/ qui a été fortement optimisé et qui est utilisé par plein d'autres logiciels.

En plus tu ne mesure qu'avec Curl qui n'est pas le plus utilisé des clients ou api pour faire du HTTP (1 ou 2) donc pas représentatif de la majorité du trafic web.

Pour du download de gros fichiers , HTTP/2 a par conception plus d'overhead que HTTP/1 car il y a des octets en plus pour chaque DATA FRAME alors qu'HTTP/1 envoi que le contenu du fichier et rien d'autre. Optimiser/négocier les bonnes tailles de DATA FRAME implique que les implémentations utilisées soient bonnes.

il y a un outil de benchmark: https://nghttp2.org/documentation/h2load.1.html qui peut t'aider à faire des tests plus poussés. NSpeed aussi mais l'export des résultats en format data n'est pas encore dispo.

Apres ca dépend de ce que tu cherches a savoir.

vivien · « **Réponse #7 le:** 17 mai 2022 à 19:36:34 »

Citation de: kgersen le 17 mai 2022 à 17:25:13

Apres ca dépend de ce que tu cherches a savoir.

Je cherchais à savoir si le serveur pouvait être limitant.

La réponse est non en descendant.

Si un éditeur d'un outil de test de débit me dit qu'avec cette configuration serveur il a des débits moindre en HTTP/2, je sais que cela vient de l'outil et non du serveur.

Ce n'était pas clair pour moi, surtout après ce mail :

Citation de: vivien le 15 mai 2022 à 21:23:33

Finalement, on pense avoir trouvé une piste intéressante hier soir. Déjà on a pu identifier que c’était une problématique serveur et non outil, en créant une page php pour faire du test directement sur le serveur sans passer par 5Gmark. Et on a reproduit le souci.

Ensuite, on a pu voir que la problématique serait au niveau du paramètre H2WindowsSize qui, par défaut est à 65536, ce qui est trop faible. Là on est en train de tester plusieurs valeurs pour essayer de trouver la valeur optimale.

Je ferais plus tard les même tests, mais pour le flux montant cette fois-ci.