Auteur Sujet: http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https  (Lu 50453 fois)

0 Membres et 1 Invité sur ce sujet

vincent0

  • Abonné Orange adsl
  • *
  • Messages: 122
  • Montpellier
    • Twitter
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #84 le: 15 mai 2018 à 09:19:13 »
Le serveur lafibre.info n'est pas en Debian 9 ?
J'ai monté un serveur en Debian 9 et dans apache le module h2 y est présent et j'ai mis en place du http2 sans soucis (dans docker en plus).

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #85 le: 15 mai 2018 à 09:35:37 »
Ubuntu server LTS

J'ai ouvert un bug en février 2016 pour avoir http/2 dans Ubuntu 16.04, mais l'équipe sécurité à jugé ça trop risqué, car marqué "Expérimental" par Apache.

Debian a été moins conservateur que Ubuntu pour une fois  ;D (enfin, j'ai souvenir que pour les MicroCode Intel, Debian avait mis en prod avant Ubuntu aussi)

Plus Ubuntu prend de la bouteille, plus ils sont stricts sur la sécurité et moins il y a de différence avec Debian. Il faudrait que je revérifie les performances TCP, dans le passé Debian était à la traine :

Débit moyen sur un téléchargement d'un fichier de 100 Mo en fonction de la latence :


Conclusion : Ubuntu server 14.04 et 14.10, Gentoo Linux et Windows Server 2012 font la courses en tête, avec un avantage pour Ubuntu Server.

Red Hat Entreprise Linux Server 7, SUSE Linux Entreprise Server 12 et Debian 7 sont en retrait au niveau des performances.

FreeBSD 10 à lui des performances proche du premier groupe avec une faible latence (< 10ms) mais proche du second groupe avec des latences > 30ms.


vincent0

  • Abonné Orange adsl
  • *
  • Messages: 122
  • Montpellier
    • Twitter
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #86 le: 15 mai 2018 à 12:08:11 »
Effectivement avant d'avoir Ubuntu 18.04, il n'y avait pas de module H2 dans Apache...
Par contre dans cette dernière version, Tomcat ne fonctionne plus avec Java 8, ce qui est problématique pour bon nombre d'appli assez anciennes qui demandent encore cette version pour pouvoir être exécutées.

Sinon j'ai pu facilement migrer de ubuntu à debian avec docker, car il suffit de remplacer dans le "FROM" de ubuntu à debian - moyennant quelques adaptations sur les versions disponibles (de php par exemple) et de noms de packages (mysql pour citer un exemple).

On a plus systématiquement les dernières versions, pas les mises à jour à faire tous les 6 mois...

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #87 le: 15 mai 2018 à 13:03:20 »
Ubuntu 18.04 utilisé par défaut OpenJDK 10 avec migration d'ici septembre sur OpenJDK 11 qui est LTS (j’espère qu'il y aura le même type d’entorse pour proposer OpenSSL avec TLS v1.3 sans attendre Ubuntu 20.04).

Par contre pour ton besoin de veille version, OpenJDK 8 est disponible dans Universe, avec en bonus des mises à jour de sécurité jusqu'en avril 2021.

vincent0

  • Abonné Orange adsl
  • *
  • Messages: 122
  • Montpellier
    • Twitter
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #88 le: 15 mai 2018 à 14:00:34 »
Oui, j'ai vu et testé :
- avec OpenJDK 8 : tomcat ne démarre pas (erreur rencontrée et déjà postée sur launchpad : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895866 - https://bugs.launchpad.net/ubuntu/+source/tomcat8/+bug/1766882)
- avec le JDK 10, c'est mon appli qui marche plus...

En fait, il me faudra un peu de courage pour la mettre à jour - sauf si d'ici là, je décide de tout recoder en Go...

buddy

  • Expert
  • Abonné Free fibre
  • *
  • Messages: 15 098
  • Alpes Maritimes (06)
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #89 le: 15 mai 2018 à 15:12:37 »

Sinon j'ai pu facilement migrer de ubuntu à debian avec docker, car il suffit de remplacer dans le "FROM" de ubuntu à debian - moyennant quelques adaptations sur les versions disponibles (de php par exemple) et de noms de packages (mysql pour citer un exemple).

On a plus systématiquement les dernières versions, pas les mises à jour à faire tous les 6 mois...

Sur Ubuntu LTS, justement tu n'as pas à faire les mises à jour tous les 6 mois.. (c'est le but des LTS)

Ubuntu LTS a le même rythme que debian.
Une version majeure en avril les années paires.

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #90 le: 08 septembre 2018 à 13:13:32 »
A noter que http/2 n'est plus compatible avec le MPM Prefork sous Apache 2.4.27 et supérieur.

Les change log d’Apache 2.4.27 indique juste *) COMPATIBILITY: mod_http2: Disable and give warning when using Prefork. The server will continue to run, but HTTP/2 will no longer be negotiated. [Stefan Eissing]

L'erreur dans les log Apache2 :
[Sat Sep 08 11:24:08.260643 2018] [http2:warn] [pid 12860] AH10034: The mpm module (prefork.c) is not supported by mod_http2. The mpm determines how things are processed in your server. HTTP/2 has more demands in this regard and the currently selected mpm will just not do. This is an advisory warning. Your server will continue to work, but the HTTP/2 protocol will be inactive.

Le MPM prefork n'est aujourd'hui choisi que si vous exécutez des moteurs de traitement qui ne sont pas préparés pour le multithreading (par exemple qui se crashent lorsque plusieurs requêtes arrivent) => En conséquence les clients tels que les navigateurs internet envoient de nombreuses requêtes au même moment et le MPM prefork ne traitera qu'une requête à la fois par connexion. Si l'une d'entre elles est longue à traiter (ou implique une longue interrogation), les autres requêtes seront mises en attente.

Bref prefork, n’était adapté pour http/2 et j’imagine qu’il y a eu des cas où les clients n’appréciaient pas son comportement, d’où un retrait du http/2 pour ce MPM.

La solution est de basculer sur le MPM event et si PHP est nécessaire, il faut utiliser php7.x-fpm

http2 explained de Daniel Stenberg (l'auteur de curl) est un excellent document pour démarrer l'étude de HTTP/2. Ce document est comme ce forum couvert par la licence Creative Commons Attribution 4.0
(cliquez sur la miniature ci-dessous - le document est au format PDF)

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #91 le: 05 mars 2021 à 12:30:43 »
http://fr.archive.ubuntu.com/ supporte depuis aujourd'hui http/2 avec chiffrement (https sur le port 443) et sans chiffrement (http sur le port 80).

Voici ce que cela donne sur http avec curl (les navigateurs ne supportent pas http/2 sur une connexion http en clair)

Pour curl, http/2 est activé par défaut en https. Pour http (sans chiffrement), il faut rajouter l'option --http/2
curl --http2 -o /dev/null http://fr.archive.ubuntu.com/

On voit clairement la demande d'upgrade dans la requête http :
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA


puis la réponse du serveur :
HTTP/1.1 101 Switching Protocols
Upgrade: h2c
Connection: Upgrade




Les paquets :


La capture wireshark (8 Ko) si vous souhaitez regarder:
(cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202103_http2_upgrade.pcapng.gz




Je suis intéressé si il y a des connexion (par exemple derrière un mobile) ou cela échoue.
Si vous avez de l'IPv6, forcer la connexion à partir en IPv4, on a plus de problème de neutralité et bidouillage de paquet en IPv4 qu'en IPv6.

curl --http2 -4 -o /dev/null http://fr.archive.ubuntu.com/

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 674
  • La Madeleine (59)
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #92 le: 05 mars 2021 à 14:08:14 »
À noter qu'on peut utiliser l'option --http2-prior-knowledge pour que curl parle directement l'http2, sans passer par la phase d'upgrade

Dans tout les cas, ce n'est utile que pour h2c (sans tls, donc): quand on chiffre, la négociation du protocole (http2 vs http1.1) est fait à travers les extensions TLS (ALPN)

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #93 le: 05 mars 2021 à 15:27:59 »
un proposal a IETF est en cours d'étude pour ajouter des enregistrements DNS pour indiquer directement les versions HTTP supportées par un serveur web.

Blog d'explication:
https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/

Dernier draft du proposal: https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-03
les discussions et le travail collaboratif ont lieu sur github ici: https://github.com/MikeBishop/dns-alt-svc

l'idée est qu'un jour tu pourras ajouter a ton dns un truc du genre:

lafibre.info 3600 IN HTTPS 1 . alpn=”h3,h2” et via une résolution dns faire connaitre les versions d'HTTPS surpportées.
Du coup un client compatible va directement ouvrir la session en h3 (http/3) ou h2(http/2)

Techniquement c'est un ajout de 2 nouveaux types d'enregistrement DNS: SVCB=64 et HTTPS=65. Ces ajouts serviront pour autre chose également notamment HSTS, indication du Encryted ClientHello de la négo TLS, indication de numéro de ports UDP ou TCP (au lieu des 80/443 par défaut -> du coup on pourra un jour héberger sur le port qu'on souhaite et le préciser dans le dns directement).

A priori pour le moment c'est déjà supporté par Cloudflare , iOS 14 et MacOS 11. Firefox le supporte via un flag mais qu'avec DoH.

('dig' par exemple ne supporte pas encore l'interprétation de ces enregistrements mais on peut les voir  quand même en passant le n° du type:
dig cloudflare.com -t TYPE65on peut décoder les valeurs chaines avec xxd:
dig +short cloudflare.com -t TYPE65 | xxd -r -p

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #94 le: 05 mars 2021 à 15:58:55 »
À noter qu'on peut utiliser l'option --http2-prior-knowledge pour que curl parle directement l'http2, sans passer par la phase d'upgrade

Dans tout les cas, ce n'est utile que pour h2c (sans tls, donc): quand on chiffre, la négociation du protocole (http2 vs http1.1) est fait à travers les extensions TLS (ALPN)

Démo en IPv6 avec un opérateur mobile :
curl --http2-prior-knowledge -6 -o /dev/null http://fr.archive.ubuntu.com/





La capture wireshark (8 Ko) si vous souhaitez regarder:
(cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202103_http2_prior_knowledge_ipv6_ok.pcapng.gz

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #95 le: 05 mars 2021 à 16:02:09 »
Démo en IPv4 avec le même opérateur mobile :
curl --http2-prior-knowledge -4 -o /dev/null http://fr.archive.ubuntu.com/



Trace coté client :





La capture wireshark (1 Ko) si vous souhaitez regarder:
(cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202103_http2_prior_knowledge_ipv4_echec_client.pcapng.gz




Trace coté serveur : On voit qu'un équipement intermédiaire à coupé la partie binaire. (A noter que j'ai vérifié : quand c'est suite à un upgrade, les commandes binaires passent bien du client vers le serveur, après l'upgrade)





La capture wireshark (8 Ko) si vous souhaitez regarder:
(cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202103_http2_prior_knowledge_ipv4_echec_serveur.pcapng.gz