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

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
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 :

Optix

  • AS41114 - Expert OrneTHD
  • Abonné Orne THD
  • *
  • Messages: 4 644
  • WOOHOO !
    • OrneTHD
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #1 le: 08 février 2016 à 22:44:50 »
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.

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

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #2 le: 08 février 2016 à 23:21:37 »
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.

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 #3 le: 08 février 2016 à 23:38:23 »
en mode 's' (chiffré), la négo entre HTTP1.1 ou 2.0 se fait pendant la négo TLS, avec ALPN (Application-Layer Protocol Negotiation Extension). Ca ne se voit donc pas au niveau des entetes/requetes HTTPS , c'est plus bas niveau.

Regarde avec wireshark: y'a un exemple ici: https://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=http2-16-ssl.pcapng

dans le paquet n°6 (client hello) on trouve vers la fin:

Extension: Application Layer Protocol Negotiation
    Type: Application Layer Protocol Negotiation (0x0010)
    Length: 14
    ALPN Extension Length: 12
    ALPN Protocol
        ALPN string length: 5
        ALPN Next Protocol: h2-16
        ALPN string length: 5
        ALPN Next Protocol: h2-14

le serveur répond (server hello) dans le paquet n°8:

Extension: Application Layer Protocol Negotiation
    Type: Application Layer Protocol Negotiation (0x0010)
    Length: 8
    ALPN Extension Length: 6
    ALPN Protocol
        ALPN string length: 5
        ALPN Next Protocol: h2-16

edit: hwti plus rapide que moi  ;)

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 #4 le: 09 février 2016 à 09:11:34 »
Effectivement, merci pour l'info :


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 #5 le: 09 février 2016 à 09:19:14 »
Le protocole http/2 a deux identifiants : (seul h2 est pris en charge dans les navigateurs web)

- "h2" identifie le protocole HTTP/2 qui utilise Transport Layer Security (TLS) [TLS12]. Cet identifiant est utilisé dans la négociation de protocole de couche application TLS (ALPN) l'extension champ [TLS-ALPN] et en tout lieu où HTTP/2 sur TLS est identifié.
Le "h2" string est sérialisé dans un identificateur de protocole de ALPN que la séquence de deux octets: 0x68, 0x32.

- "h2c" identifie le protocole HTTP/2 utilise TCP en clair. Cet identifiant est utilisé dans le champ d'en-tête. "H2C" décrit un protocole qui n'utilise TLS.

Pour passer à http/2 en clair (h2c), on utilise http/1.1 et une demande d'upgrade voici le GET à réaliser :
GET / HTTP/1.1
Host: server.example.com
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>

La réponse d'un serveur qui ne supporte pas http/2 :
HTTP/1.1 200 OK
Content-Length: 243
Content-Type: text/html
...

La réponse d'un serveur qui supporte http/2 :
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: h2c

[ HTTP/2 connection ...

Donc une connexion http/2 en clair nécessite un échange via http/1.1.

Cela reste théorique, car aujourd'hui les navigateur n'ont pas implèmentés h2c (mais les serveurs web supportent h2c)

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 #6 le: 09 février 2016 à 09:43:39 »
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:

Citer
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.
 

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 #7 le: 09 février 2016 à 10:49:51 »
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.

Pas seulement Chrome et Firefox : Internet  Explorer 11 sous Win10, Microsoft Edge, Safari sous OS 10.11 et Opéra ont aussi choisi de ne proposer HTTP/2 que sur SSL :


Source : http://caniuse.com/#feat=http2

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 #8 le: 09 février 2016 à 12:13:09 »
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.

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 #9 le: 09 février 2016 à 14:07:05 »
Pas de mod http2 avec Ubuntu 16.04 (version de développement)  :'( :'( :'(
(le fichier /etc/apache2/mods-available/http2.load n'existe pas alors que la version d'apache2 proposé par Ubuntu 16.04 est la Apache 2.4.18)

Normalement l'activation de http/2 devrait se faire avec un a2enmod ssl http2
Puis rajouter les directives dans les virtual host https où http/2 doit être activé ( Protocols h2 http/1.1 )

J'ai ouvert un bug:  https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1543572
Je n'imagine pas Ubuntu server 16.04 LTS sortir sans le support de http/2

mirtouf

  • Abonné Bbox fibre
  • *
  • Messages: 1 297
  • Chelles (77)
    • L'antre de la bête

Marin

  • Client Bbox vdsl
  • Modérateur
  • *
  • Messages: 2 804
  • 73
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #11 le: 10 février 2016 à 11:57:27 »
Je n'imagine pas Ubuntu server 16.04 LTS sortir sans le support de http/2

C'est discutable, est-ce que le fait que SPDY soit normalisé rend SPDY nécessaire ?