http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https



Je tente de comprendre comment mon Firefox annonce aux serveurs web qu'il est compatible http/2 et malgré mes recherches sur le "negotiation mechanism http2", je n'ai pas trouvé la réponse.

Voici le get envoyé sur le site https://ipv4.lafibre.info (première visite pour ce navigateur, donc il ne sait pas si le serveur derrière est http/2 ou non)
GET / HTTP/1.1
Host: ipv4.lafibre.info
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
Cookie: lafibreinfo=a%3A4%3A%7Bi%3A0%3Bs%3A3%3A%22306%22%3Bi%3A1%3Bs%3A40%3A%226f9fbaa04677220421397f9fecba31e76fd5bd2f%22%3Bi%3A2%3Bi%3A1644089568%3Bi%3A3%3Bi%3A1%3B%7D
Connection: keep-alive
Pourquoi il part sur du HTTP 1.1 alors que le client supporte HTTP/2 ?
Pourtant si le serveur en face sait faire du HTTP 2.0, Firefox part sur une requête HTTP 2.0 (car le serveur web de https://ipv4.lafibre.info ne supporte pas encore http/2 mais mon Firefox ne le sait pas encore)

J'ai pensé à des info qui indiquent la prise en charge du 2.0, mais dans "Accept-Encoding", gzip, deflate et br (Brotli) sont des algorithmes de compression (Brotli a été ajouté dans Firefox 44 et Firefox est le premier navigateur à le supporter, Chrome va suivre quelques semaines plus tard)

Bref, si vous avez compris comment se passe la négociation de la version de http, je suis preneur (n'oubliez pas que http/2 n'est utilisable que sur des connexions https)

Schéma pour expliquer les gains de HTTP/2 Push Server vs HTTP/2 vs HTTP/1.1 :


Autre schéma réalisé par CloudFlare :

https://http2.github.io/http2-spec/#discover-http

Il est en https, donc c'est https://http2.github.io/http2-spec/#discover-https.

La négociation se fait dans ce cas au niveau TLS : dans le message ClientHello puis la réponse ServerHello, il y aura l'extension ALPN avec le protocole "h2".

Actuellement Firefox déclare supporter les protocoles "h2", "spdy/3.1", et "http/1.1".
https://ipv4.lafibre.info ne supporte pas l'ALPN (ou c'est désactivé), donc il l'ignore, et Firefox ne voyant pas l'extension dans le ServerHello sait qu'il doit utiliser HTTP 1.1.

Effectivement, merci pour l'info :

oui le chiffrement n'est pas obligatoire avec HTTP/2 contrairement a ce qu'on peut lire ici ou la.

C'est un choix d'implementation des éditeurs de navigateur (notamment Chrome et FF) d'imposer le chiffrement en HTTP/2 dans leur produit.

Bien qu'on pense que la sécurité/confidentialité soient les seules raisons motivant a cela, c'est surtout pour autre chose:

Reasons for choosing TLS-only include respect for user's privacy and early measurements showing that new protocols have a higher success rate when done with TLS. This because of the widespread assumption that anything that goes over port 80 is HTTP 1.1 makes some middle-boxes interfere and destroy traffic when instead other protocols are communicated there."

(source - tres bonne lecture).

En francais: du HTTP/2 non chiffré sur le port 80 risque d'avoir plein de problemes de fonctionnement dans le monde réel a cause de tous les équipements intermédiaires des opérateurs qui interférent souvent sur ce n° port...(=triturage du web par les FAI :p)
Donc la motivation est d'éviter, en pratique,  de se prendre la tête a savoir pourquoi ca ne marche pas ou mal. Si on veut qu'un nouveau protocol soit adopté rapidement il faut un minimum de friction dans sa mise en oeuvre pratique sur les infra existantes.
 

oui mon "'notamment Chrome et FF" référait au fait que ces 2 la ont "poussé" fort pour que tout le monde fasse pareil qu'eux.
Les discussions et échanges ont été houleux sur ce sujet.
et pas au fait que seul eux faisaient comme cela.

Cadeau 
http://packages.ubuntu.com/fr/xenial/httpd/nginx-full