Auteur Sujet: Débit faible en http/3, mais ok en http/2 sur le même serveur (Lu 3969 fois)

vivien · « **le:** 03 mars 2022 à 11:00:25 »

Débit faible en http/3, mais ok en http/2 sur le même serveur

QoSi a mis en place un premier serveur http/3 basé sur un VPS OVH avec Ubuntu 20.04 LTS + Nginx avec le support de Quic & HTTP/3 afin de vérifier les performances de ce protocole.

Le serveur de test est limité (VPS OVH Essential à 10€/mois offrant 2vCore, 4Go ram, 80 Go SSD et 500 Mb/s de débit) merci de ne pas lancer de script automatique dessus.
J'ai testé le fichier https://http3.5gmark.com/dl/52428800.file avec un navigateur Web (Firefox / Chrome, la problématique est la même)

Au premier chargement le navigateur ne sait pas que le serveur est compatible http/3 et le premier transfert après son ouverture est réalisé en http/2 (trafic TCP). Lors de la réponse que va lui faire le serveur, il y a un champ « alt-svc : h3= » :443 » ; ma=259200 » qui indique au client que le serveur sait faire du http/3. Le navigateur va mémoriser cette information et les connexions suivantes seront en http/3 (trafic UDP).

Si le premier transfert http/2 se fait avec au débit maximum, le transfert suivants réalisés en http/3 sont fortement limité en débit (en fonction de la latence ?)

J'ai réalisé des tests sur les 4 opérateurs mobiles où on est limité à environ 10 Mb/s en http/s. Sur une connexion fixe, le débit est un peu plus élevé (30 Mb/s).

Avez-vous une piste pour comprendre d'où vient la limitation ? (une capture Wireshark ne permet plus de voir grand chose avec Quic)

C'est bien le même serveur et le même fichier qui est demandé pour les deux transferts, seul le protocole change.

vivien · « **Réponse #1 le:** 03 mars 2022 à 11:03:06 »

Voici des résultats complets de tests chez les 4 opérateurs mobiles sur plusieurs APN, configuré en IPv4 ou IPv6.

Le serveur http/3 lui n'écoute qu'en IPv4 pour le moment.
Le test http/3 est surligné en orange, les autres tests sont en http/1.1 ou http/2.

Le tests http/3 est dans Firefox, les autres tests utilisent Curl pour aller vite, voie la liste des commandes passées.

vivien · « **Réponse #2 le:** 03 mars 2022 à 20:59:30 »

Autre exemple, où j'ai changé la connexion (SFR câble 100 Mb/s), le PC (Windows 11) et le navigateur (Edge 98).

Là aussi le premier transfert en http/2 a un débit sensiblement plus important que le second qui se fait en http/3.

C'est donc un pb de performance de Nginx. Si vous avez une idée, je suis preneur.

mirtouf · « **Réponse #3 le:** 04 mars 2022 à 09:47:38 »

Bonjour,
le mieux serai sans doute de poster sur la ML nginx-devel car le support http/3 n'est pas encore dans le branche mainline si mes souvenirs sont bons.
Le README contient des indications:
https://hg.nginx.org/nginx-quic/file/tip/README

Optix · « **Réponse #4 le:** 04 mars 2022 à 09:59:01 »

OVH limite le trafic UDP pour limiter les attaques non ?

vivien · « **Réponse #5 le:** 04 mars 2022 à 10:07:02 »

J'ai pensé à une limitation UDP d'OVH, mais le débit http/3 fluctue selon la latence.

Si c'était un limitation OVH, le débit serait le même avec toutes les connexions, non ?

A noter qu'il n'est pas facile de faire un test en ligne de commande, car curl qui a une option --http3 n'est pas compilé sur plusieurs linux avec le support d'http3

curl: option --http3: the installed libcurl version doesn't support this

Fyr · « **Réponse #6 le:** 05 mars 2022 à 05:22:54 »

Bah mince. Moi qui comptait sur l'UDP et son absence de contrôle de flux pour péter tout Internet plein pot ...

Blague à part doit y avoir des portions de code expérimental avec un mode debug qui doit plomber les perfs.

Code: [Sélectionner]

./auto/configure --with-debug --with-http_v3_module dans le README de nginx et visiblement des options à configurer type 0-RTT la taille max de paquets etc.

FloBaoti · « **Réponse #7 le:** 05 mars 2022 à 08:56:08 »

Citation de: Fyr le 05 mars 2022 à 05:22:54

Bah mince. Moi qui comptait sur l'UDP et son absence de contrôle de flux pour péter tout Internet plein pot ...

C'est aussi lui qui transporte 99% des attaques DDoS donc bon... Beaucoup de réseaux limitent UDP.

Fyr · « **Réponse #8 le:** 05 mars 2022 à 12:28:06 »

Citation de: FloBaoti le 05 mars 2022 à 08:56:08

C'est aussi lui qui transporte 99% des attaques DDoS donc bon... Beaucoup de réseaux limitent UDP.

Après si y a des lessiveuses à paquets ça va passer de QUIC à COUIC

kgersen · « **Réponse #9 le:** 16 mai 2022 à 14:07:17 »

y'a une limitation en réception sur certains OS : https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size

kgersen · « **Réponse #10 le:** 16 mai 2022 à 17:57:09 »

ton serveur HTTP/3 n'est plus en service (https://http3.5gmark.com/dl/52428800.file)?

vivien · « **Réponse #11 le:** 16 mai 2022 à 18:12:56 »

Mon OS client lors de mes tests étaient Ubuntu 21.10

C'était du test. Clairement l'écosystème HTTP/3 (client de test de débit et serveur) est pas suffisamment mur pour que cela soit utilisé pour la campagne Arcep (il avait été envisage de faire 25% des tests en HTTP/3.

HTTP/3 est clairement l'avenir, mais il faut avouer que le support se limite principalement à de grands CDN (Google, Facebook,...) et aux principaux navigateurs web.

Même le curl 7.81 livré avec Ubuntu 22.04 ne supporte pas HTTP/3 :

$ curl --http3
curl: option --http3: the installed libcurl version doesn't support this
curl: try 'curl --help' or 'curl --manual' for more information
$ curl --version
curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.11
Release-Date: 2022-01-05
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd