La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Navigateurs web => Discussion démarrée par: vivien le 08 février 2016 à 21:52:50
-
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
(https://lafibre.info/images/logo/logo_http2.svg)
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 :
(https://lafibre.info/images/stats/201604_gain_http2_server_push.png)
Autre schéma réalisé par CloudFlare :
(https://lafibre.info/images/ssl/201909_http2.png)
-
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 :)
-
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.
-
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 ;)
-
Effectivement, merci pour l'info :
(https://lafibre.info/images/wireshark/201602_wireshark_http2_dans_paquet_hello.png)
-
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)
-
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 (http://daniel.haxx.se/http2/http2-v1.10.pdf)- 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 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 :
(https://lafibre.info/images/wireshark/201602_support_http2_par_navigateur_web.png)
Source : http://caniuse.com/#feat=http2
-
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.
-
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
-
Cadeau ;D
http://packages.ubuntu.com/fr/xenial/httpd/nginx-full
-
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 ?
-
Les versions LTS (Long Term support) sont les seules fortement utilisé pour l'hébergement (certains hébergent ne proposent qu'elles) et donc louper http/2 pour la version 2016, indique que la majorité des utilisateurs vont attendre 2018 et Ubuntu 18.04 LTS pour mettre http/2.
Il est bien sur possible de faire du http/2 sans attendre, mais de nombreuses personnes sont frileuses dans l'ajout de PPA (Personal Package Archives) voir même de paquets "universe" (coucou nginx), de peur de ne pas avoir une réactivité suffisant face aux failles de sécurité.
-
on a une garantie de réactivité sur les LTS d'Ubuntu plus que sur nginx ? je ne suis pas sur.
Apres y'a Docker maintenant, donc on peut très bien isoler les services 'je n'ai pas confiance' sur une base LTS connue sans pour autant avoir la lourdeur d'ajouter une vraie VM.
D'ailleurs a terme, toutes les distros linux vont surement disparaître...mais au quotidien on n'en est pas encore la.
-
D'ailleurs a terme, toutes les distros linux vont surement disparaître...
tu qoi ?
-
Pour de nombreuses entreprises (avec une stratégie qui demande des garanties sur les mise à jour de sécurité), seul les dépôts Main et Restricted sont utilisés, donc limitation à Apache 2.4 officiel. Le support des dépôts Main / Restricted sont reconnus pour être mis à jour rapidement à chaque faille de sécurité et ce pendant la durée de vie prévue.
- Sections Main et Restricted, maintenues par les développeurs d'Ubuntu : Les sections main (paquets tout à fait libres) et restricted (paquets non-libres) contiennent des paquets maintenus par les développeurs d'Ubuntu pour toute la durée de vie de la version d'Ubuntu que vous utilisez.
- Sections Universe et Multiverse, maintenues par les MOTU : Les sections universe et multiverse des dépôts officiels contiennent des paquets maintenus par la communauté. La Fondation Ubuntu ne contrôle pas ces paquets ; ils sont analysés par un comité d'utilisateurs. La section universe contient uniquement des paquets libres et la section multiverse, des paquets non-libres.
- PPA : En aucun cas, les paquets en provenance d'un PPA ne sont maintenus par Canonical, Ils ne bénéficient non plus de la validation officielle Ubuntu, ni du support des développeurs des équipes officielles Ubuntu.
-
La suppression du mod http/2 de Apache 2.4.18 n'est pas un oubli: c'est une suppression volontaire (je n'ai pas compris pourquoi)
- Don't build experimental http2 module for LTS:
+ debian/control: removed libnghttp2-dev Build-Depends (in universe).
+ debian/config-dir/mods-available/http2.load: removed.
Source : https://launchpad.net/ubuntu/xenial/+source/apache2/+changelog
L'auteur de la suppression de http/2 est Marc Deslauriers (https://launchpad.net/~mdeslaur) (Un salarié de Canonical qui est "Ubuntu Security Engineer" et qui était consultant en sécurité chez un grand FAI, avant de passer chez Canonical). J'imagine qu'il y a des pb de sécurité dans la décision de supprimer http/2.
Coté Debian unstable, http/2 semble bien présent : http://metadata.ftp-master.debian.org/changelogs/main/a/apache2/apache2_2.4.18-1_changelog
-
Je crois que le mot clé est "experimental" :)
-
Cadeau ;D
http://packages.ubuntu.com/fr/xenial/httpd/nginx-full
Ah oui ? J'ai fini par passer sur nginx (je suis pas fan, mais pour http/2, je migre).
J'ai installé http://packages.ubuntu.com/fr/xenial/httpd/nginx qui a un support officiel de Canonical, avec maj de sécurités.
Il manque --with-http_v2_module à la compilation de nginx :
# nginx -V
nginx version: nginx/1.9.10 (Ubuntu)
built with OpenSSL 1.0.2e 3 Dec 2015 (running with OpenSSL 1.0.2f 28 Jan 2016)
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_sub_module --with-http_xslt_module --with-stream --with-stream_ssl_module --with-mail --with-mail_ssl_module --with-threads
La suppression de http/2 dans nginx est demandé par l'équipe en charge de la sécurité Ubuntu :
- Remove HTTP/2 references in package descriptions, per Ubuntu Security Team mandate to disable HTTP/2 support.
- debian/rules:
- Disable HTTP/2 module support in all flavors, per Ubuntu Security Team mandate.
Source : https://launchpad.net/ubuntu/xenial/+source/nginx/+changelog
-
Bon bah, go debian alors ou compilation de Apache 2.4.
-
Go debian je dirais ;)
-
go Docker ? :P
-
aussi !
-
Et sinon, vous avez compris le pb de sécurité soulevé par http/2 ? (visiblement ce n'est pas l'implèmentation dans un navigateur qui pose pb mais http/2 de manière globale)
-
Vivien: pour moi, il n'y a pas de problème de sécurité
Il s'agit juste d'un truc nouveau, et les concernés ne se sentent pas capable d'assurer la sécurité dudit module (ce qui est concevable, vis-à-vis de tout logiciel récent / en cours de dev), d'autant plus pour une version LTS (qui va donc durer et se doit d'être plus stable que les autres versions)
-
Et sinon, vous avez compris le pb de sécurité soulevé par http/2 ? (visiblement ce n'est pas l'implèmentation dans un navigateur qui pose pb mais http/2 de manière globale)
a l'origine:
Please disable HTTP/2 / SPDY for initial inclusion into Xenial; the security team would really prefer this code have some more real-world exposure and fuzzing before we turn it on. We can always turn it on after release via an SRU later.
suivi d'un long dialogue entre les 2 de la sécu chez Ubuntu: https://lists.ubuntu.com/archives/ubuntu-release/2016-January/003499.html
qui se conclut par:
21:12 <rbasak> 1. No HTTP2 support in nginx nor apache2 because both upstreams still consider it experimental.
21:12 <sarnold> mdeslaur: I think they're well aware of our concerns at this point and I think they'd take them into proper consideration when makin a decision.
21:12 <rbasak> 2. We expect to add HTTP2 support when they're ready upstreams through SRU, including a future MIR of nghttp2.
21:12 <rbasak> 3. Once added we expect support in main.
21:13 <mdeslaur> rbasak: that sounds accurate to me
21:13 <rbasak> Additionally we're not even building HTTP2 support right now, not even in universe.
tl;dr: principe de précaution, y'a pas de souci de sécurité en soi et ceux qui gèrent apache et nginx considèrent encore HTTP/2 comme experimental.
ils l'ajouterons plus tard quand apache et nginx seront prets.
-
Merci,
Je comprends mieux, la désactivation est lié au fait que la version est LTS (Long Term Support = support de 5 ans sur la même version d'Apache avec mise en place des correctif de sécurité des versions suivantes sur la version supportée 5 ans, par les équipes Ubuntu) et qu'ils souhaitent du code stable. Le code de http/2 risque de beaucoup évoluer ce qui rendra difficile le retro-portage des failles de sécurité qui seront découvertes. Il y a en plus le pb pour Apache avec une bibliothèque http/2 qui est dans le dépôt "universe", et donc pas soumis a des mises à jour de sécurité et un audit contre les failles comme l'est le code du "main".
Si vous vous demandez ce qu'est SRU dont parles les personnes d'Ubuntu : StableReleaseUpdates (https://wiki.ubuntu.com/StableReleaseUpdates)
Je vais mettre en place une VM Debian pour tester http/2. (Je ne suis pas a l'aise avec Docker)
-
ps: t'as pas besoin de Debian Stretch pour avoir http/2. mon site est en http/2 juste avec l'image nginx:latest
L'avantage de stretch est le support ALPN out-of-the-box par openssl et il faut espérer que les devs de chromium ne recommencent pas à dégager NPN.
-
Je ne sais pas si Chrome et Chromium sont 100 % identiques sur ce sujet là, mais NPN dégage de chrome ..
https://www.nextinpact.com/news/98524-chrome-abandonnera-protocole-spdy-15-mai.htm
Google se réjouit évidemment de voir HTTP/2 aussi rapidement adopté, indiquant d’ailleurs que tous les principaux navigateurs sont désormais compatibles. Le retrait de SPDY ne fera pas une grande différence en pratique, les sites l’utilisant par le passé ayant pour la plupart transité vers HTTP/2.
L’éditeur profite de cette annonce pour en faire une autre : l’abandon à la même date de l’extension NPN du protocole TLS. Initialement, elle avait été créée pour négocier les connexions avec SPDY et HTTP/2. Cependant, elle a été supplantée par une nouvelle extension, ALPN, devenue un standard à l’IETF en 2014. Google indique qu’ALPN est actuellement utilisée dans 99 % des cas quand les sites utilisent SPDY ou HTTP/2. Les serveurs ne s’en servant pas peuvent la mettre en place en mettant à jour leur bibliothèque SSL.
-
ça va encore gueuler étant donné que pas mal de distros fournissent encore openssl en version 1.0.1 et donc sans ALPN.
-
y'a un site pour tester si un serveur web http2 fait de l'APLN ou du NPN: https://tools.keycdn.com/http2-test
J'ai mis a jour mon image avec nginx 1.9.9 et openssl 1.0.2.f , ca passe le test APLN.
-
Je ne sais pas si Chrome et Chromium sont 100 % identiques sur ce sujet là, mais NPN dégage de chrome ..
https://www.nextinpact.com/news/98524-chrome-abandonnera-protocole-spdy-15-mai.htm
Chromium c'est Chrome, moins:
- le Flash intégré (mais en contre-partie, Chromium a un mécanisme d’auto-détection du Flash PPAPI d'Adobe, hors bac à sable, depuis la version 43 du navigateur)
- les codecs propriétaires (que la majorité des navigateurs basés dessus intègrent, dont Opera, et même Iron depuis la dernière version 48, et la plupart des distros de Linux permettent même de les ajouter à l'install de Chromium)
- les DRM (idem que les codecs propriétaires, mais pas pour Linux, et pas tous les navigateurs sous Mac OS)
- la majorité des outils de télémétrie de Google (mais il y en a, et désactivable, d'où un débat houleux avec Iron)
- quelques corrections de bugs, et évolutions, en retard d'une version, mais ce n'est pas systématique
Donc concernant HTTP/2 et ce qui est inclus avec, à part le dernier point, c'est le même combat entre Chrome et Chromium.
-
Chromium c'est Chrome, moins:
...les codecs propriétaires (que la majorité des navigateurs basés dessus intègrent, dont Opera,...
Voudrais -tu dire que les dernières versions d'Opera sont basées sur Chromium ?? (https://lafibre.info/images/smileys/@GregLand/cs.gif)
-
Oui, Opera 15 et suivants (depuis juillet 2013) utilisent Chromium en base.
C'est un adieu à Presto, la technologie maison, et bonjour à Webkit, tel qu’utilisé par Chrome et Chromium (le projet open source qui sous-tend le développement du navigateur de Google).
Aujourd'hui il y a 3 grands moteurs de rendu pour présenter des pages web :
- Webkit et son fork Blink (Chrome / Chromium / Opera / Vivaldi / Safari / Konqueror/ Epiphany / Android - Le navigateur par défaut / OmniWeb / Shiira /Midori / Arora / QupZilla / Webster / SunriseBrowser / DeskBrowse / navigateur Web du S60 de Nokia / Maxthon / Samsung Mobile Browser / Rekonq / Uzbl / Jumanji / Uzbl / OWB / Qutebrowser
- Trident (Edge / Internet Exporer / Maxthon / AOL Explorer / Avant Browser / Sleipnir / SlimBrowser
- Gecko (Firefox / Camino / Netscape Navigator / Mozilla Suite / SeaMonkey, Galeon)
A Noter également Lunascape (navigateur web utilisant les moteurs de rendu Trident, Gecko et Webkit)
-
+1 pour Opera/Chromium
Lunascape est (quasi-)mort en soit, même si encore développé et supporté, mais c'est un tout autre sujet.
Pour la transition d'Opera:
- la version 13 n'a jamais existé... pour des questions de superstitions. Cela ne les a pas empêcher de vendre, et revendre leur âme (Chromium à l'époque, les chinois aujourd'hui).
- la version 14 est déjà basé sur Chromium, et elle est uniquement pour la version mobile (uniquement sous Android pour recommencer à l'époque).
-
Oui, Opera 15 et suivants (depuis juillet 2013) utilise Chromium en base.
C'est un adieu à Presto, la technologie maison, et bonjour à Webkit, tel qu’utilisé par Chrome et Chromium (le projet open source qui sous-tend le développement du navigateur de Google).
Aujourd'hui il y a 3 grands moteur de rendu pour présenter des pages web :
- Webkit et son fork Blink (Chrome / Chromium / Opera / Vivaldi / Safari / Konqueror/ Epiphany / Android - Le navigateur par défaut / OmniWeb / Shiira /Midori / Arora / QupZilla / Webster / SunriseBrowser / DeskBrowse / navigateur Web du S60 de Nokia / Maxthon / Samsung Mobile Browser / Rekonq / Uzbl / Jumanji / Uzbl / OWB / Qutebrowser
- Trident (Edge / Internet Exporer / Maxthon / AOL Explorer / Avant Browser / Sleipnir / SlimBrowser
- Gecko (Firefox / Camino / Netscape Navigator / Mozilla Suite / SeaMonkey, Galeon)
A Noter également Lunascape (navigateur web utilisant les moteurs de rendu Trident, Gecko et Webkit)
...Safari aussi !? (https://lafibre.info/images/smileys/Confus/Confus_91.gif)
Merci pour cette mise au clair, Vivien. (https://lafibre.info/images/smileys/@GregLand/ay.gif)
-
...Safari aussi !?
(https://i.imgur.com/T0xyd6U.jpg)
-
Pour Safari, faut remettre les choses dans l'ordre.
Webkit et Safari sont tous les 2 créés par Apple!
Google s'est ensuite imposé dans Webkit, pour le mettre dans Chrome et Chromium.
Et enfin, Google a créé le fork Blink (désaccord avec Apple qui garde les fondamentaux de Webkit), qui est en parallèle de Webkit, où Google y est encore pour des raisons de compatibilité avec iOS (Webkit obligatoire pour les navigateurs dont le moteur de rendu est en local).
-
WebKit est un fork du moteur de rendu KHTML du projet KDE (l’environnement de bureau Linux) utilisé notamment dans le navigateur Konqueror.
KHTML a été développé en même temps que la technologie à composants KPart qu'il utilise pour être intégré à Konqueror, le gestionnaire de fichiers de KDE. Il est sorti en 2000, en même temps que la version 2 de KDE.
En 2002 Apple choisit KHTML ainsi que KJS pour l'interpréteur JavaScript comme base de son moteur de rendu HTML qu'utilisera son navigateur web Safari. Ce nouveau moteur, placé sous licence LGPL et appelé WebKit subit de nombreuses modifications visant notamment à réduire les dépendances aux bibliothèques KDE, à tel point que les échanges de code entre les deux moteurs devinrent très compliqués. Ces problèmes ont été réglés lorsque Apple a ouvert le développement de Webkit en utilisant un dépôt SVN et un système de suivi des bug utilisant Bugzilla1. C'est ainsi que certaines modification d'Apple ont pu être intégrées à KHTML, comme celles ayant permis au moteur de rendu de KDE de passer le test Acid2.
Source : Wikipedia (https://fr.wikipedia.org/wiki/KHTML)
On voit ici les gains de l'OpenSource : tu prends un produit et tu l’améliores en rendant publiques tes modifications. Il y a un beau travail de base créée par les équipes de KDE qui a été amélioré par Apple puis Google.
Aujourd'hui la masse de travail pour faire un bon moteur de rendu fait qu'il n'y aura plus de nouveaux moteurs autre que des fork. C'est pour cela qu'il faut vraiment éviter que Firefox abandonne Gecko. A noter que Firefox sous iOS utilise Webkit (obligation d'Apple).
-
il faut vraiment éviter que Firefox abandonne TridentGecko.
Il travaillent aussi sur Servo, qui est un nouveau moteur (même si certaines parties sont conservées comme SpiderMonkey pour le JS).
-
CloudFlare dit être la première société à activer largement HTTP / 2 Push Server et annonce un gain de temps de chargement de 15%
Schéma pour expliquer les gains de HTTP/2 Push Server vs HTTP/2 vs HTTP/1.1 :
(https://lafibre.info/images/stats/201604_gain_http2_server_push.png)
-
Ce truc me parait une bonne idée, mais cela doit être traité avec une attention particulière, non ?
Dans ton cas, l'image, css et js peuvent et sont potentiellement présent dans le cache local : dans ce dernier cas, tu vas faire télécharger plus de données que nécessaire par le client, ce qui peut-être problèmatique pour les héres propulsés par DSL (ou pire, par onde)
-
le graphique est pas terrible, les navigateurs n'attendent pas d'avoir récupérer x.css avant de lancer le téléchargement de X.js
pas contre en http2, cela n'utilise qu'une connexion ouverte (c'est donc des poignées de main en moins)
-
Le nombre de connexion parallèle est limitée
Pour 3 objets, tu as raison
Pour 30 objets, tu as tort
-
Ce truc me parait une bonne idée, mais cela doit être traité avec une attention particulière, non ?
Dans ton cas, l'image, css et js peuvent et sont potentiellement présent dans le cache local : dans ce dernier cas, tu vas faire télécharger plus de données que nécessaire par le client, ce qui peut-être problèmatique pour les héres propulsés par DSL (ou pire, par onde)
Il existe un mécanisme d'annulation de la part du client quand il commence a recevoir un truc 'pushé' qu'il a déjà en cache (le client envoi un RST_STREAM).
En pratique ca marche bien et l'overhead est minime.
Sur les réseaux sensibles a la conso, le client peut explicitement interdire le push.
source: http://http2.github.io/http2-spec/#PushResources
-
http/2 (avec ou sans PUSH) va aussi économiser des ouvertures de connexions https (cela consomme pas mal de données d'ouvrir une connexion https, il faut échanger le certificat ect.)
Coté serveur, cela va aussi bien diminuer la chargé liée aux nombreuses connexions ouvertes.
-
Si je comprends bien avec http/2 il y a quand même un changement de paradigme. Car on peut rassembler toutes ces ressources sur le même domaine (tous les fichiers mais jusqu'à combien) pour échanger une seule poignée de main et un seul canal de communication.
Et donc que le fonctionnement avec des domaines pour les fichiers statiques semblent compromis. Quel est l'impact de http/2 d'un site à fort traffic qui utilise le CDN à tout va ?
-
Il est effectivement conseillé de limiter le nombre de domaines et de connexions ouvertes.
Généralement on observer que les sites sans réseaux sociaux en http/2 utilisent 2 à 4 hébergements différents.
Wikipedia par exemple est en http/2 et a tout sur 2 nom de domaine.
À l'inverse, un site vraiment mal codé : http://www.ldlc.com/
Il ouvre une centaine de connexion TCP pour afficher une page.
Ils vont devoir changer pas mal de chose pour passer en http/2.
-
Et pour lafibre.info, c'est pour quand ? :)
-
Pas pour tout de suite, le premier point bloquant est la non compatibilité de SMF 2.0.x avec PHP 7 qui bloque tout upgrade.
Le problème c'est que SMF 2.1 ne va pas sortir avant 2ans, donc j’espère qu'ils vont mettre la compatibilité PHP 7 sur SMF 2.0.x (c'est pas
N'hésitez pas à poster un petit message pour insister sur PHP 7 sur le forum de SMF : http://www.simplemachines.org/community/index.php?topic=540808.msg3871960#msg3871960
-
Le problème c'est que SMF 2.1 ne va pas sortir avant 2ans, donc j’espère qu'ils vont mettre la compatibilité PHP 7 sur SMF 2.0.x (c'est pas[...]
Pounaide by tab ? ;D
-
Le problème c'est que SMF 2.1 ne va pas sortir avant 2ans
Où est le problème de planning que t'as soulevé en anglais? La sécurité de PHP 5.6 est assurée jusqu'au 31 décembre 2018.
http://php.net/supported-versions.php
Il n'y a pas de version d'Ubuntu supportée avec cette version de PHP?
Au pire, on peut installer PHP 5.6 sur 16.04, 14.04, et 12.04 via PPA
http://tecadmin.net/install-php5-on-ubuntu/#
-
Il est effectivement conseillé de limiter le nombre de domaine et de connexions ouvertes.
Généralement on observer que les sites sans réseaux sociaux en http/2 utilisent 2 à 4 hébergements différents.
Wikipedia par exemple est en http/2 et a tout sur 2 nom de domaine.
A l'inverse un site vraiment mal codé : http://www.ldlc.com/
Il ouvre une centaine de connexion TCP pour afficher une page.
Ils vont devoir changer pas mal de chose pour passer en http/2.
ca n'est pas du "domain sharding" qu'ils font chez ldlc ? en HTTP 1.x, les navigateurs limitent a 6 connexions par domaine donc si on veut paralléliser plus il suffit d'utiliser plus de nom de domaines distincts, qui peuvent derriere pointer sur le meme serveur.
exemple:
- une page web avec 12 ressources (images, scripts, etc) sur nom.domain.com: le navigateur va en charger 6 au max en meme temps
- la meme page web avec 6 ressources sur n1.domain.com et 6 ressources sur n2.domain.com avec les 2 pointants sur nom.domain.com: la navigateur va charger les 12 ressources en meme temps.
(https://www.maxcdn.com/one/assets/post-images/domain-sharding.png)
cette technique est très utilisée en http 1.x mais ne rend pas forcement plus compliqué le passage en 2.0.
-
- Gecko (Firefox / Camino / Netscape Navigator / Mozilla Suite / SeaMonkey, Galeon)
Et Palemoon utilise Goanna (fork de Gecko) depuis Palemoon 26.
Mozilla/5.0 (X11; Linux x86_64; rv:38.9) Gecko/20100101 Goanna/2.0 Firefox/38.9 PaleMoon/26.2.2
Je le trouve très bon.
Sinon pour Servo, j'ai essayé de le compiler et je l'ai lancé avec browser.html qui est inclut dedans, c'est pas très utilisable ( trèèèèès lent )
-
Où est le problème de planning que t'as soulevé en anglais? La sécurité de PHP 5.6 est assurée jusqu'au 31 décembre 2018.
Je vais expliquer, gérer des mises à jour de sécurité sur de nombreuses années est la cause de tous ces problèmes.
Active support for PHP5.6 upstream ends Dec. 31, 2016.
Security support for PHP5.6 upstream ends Dec. 31, 2018.
Ubuntu 16.04 est supporté jusqu'en avril 2021, avec la même version de PHP. C'est qui a poussé les équipes d'Ubuntu à passer à PHP 7 qui est encore jeune : Avec PHP 5.6 il aura fallu rétro-porter les corrections de bugs depuis PHP7 pendant plus de 2 ans, ce qui demande beaucoup de travail. (Ubuntu aurais du assurer lui même le support de PHP 5.6)
C'est aussi ce support de 5 ans qui a poussé Ubuntu 16.04 a ne pas supporter http/2 avec Apache2 : La version 2.4.18 d'Apache2 est dans Ubuntu 16.04. Le support de cette version n'est pas assuré par Apache, qui a publié de nouvelle version. C'est donc les équipes d'Ubuntu qui support la version 2.4.18 pendant 5ans. Chaque bug de sécurité des version suivante d'Apache est rétro porté sur Apache 2.4.18. Faire ce travail pour http/2 aurais été compliqué car http/2 bouge beaucoup (la moitié des modifications a chaque version d'Apache) : Bref en ne supportant pas http/2 ils économisent pas mal de travail.
SMF a aussi une politique de support très étendue. SMF 2.0 sera probablement supporté encore près de 10ans. Le support de SMF 1.1 viens de s'achever.
En refusant de passer à rendre SMF 2.0 compatible PHP 7, ils ne seront plus utilisable en 2019 quand tous les hébergeur auront basculé sur PHP 7.
Ce qui bloque le passage à PHP7 est, il me semble, le fait que cela rendrait le code avec des versions très anciennes de PHP. Or SMF souhaite proposer une compatibilité avec PHP 4.1 !
On avait déjà galéré pour PHP 5.5 : SMF ne fonctionnait pas avec PHP 5.5 mais là ils avaient, tardivement fait la mise à jour du code, qui ne cassait pas la compatibilité avec PHP 4.1.
Pour vous faire rigoler, le support de PHP 4.1 a été arrêté le 12 mars 2002, il y a plus de 14ans !
J'aime bien les vieux PC et les vieux système d'exploitation, mais je trouve qu'ils ont une politique concernant le soft coté serveur qui est à revoir. Coté client, SMF 2.0 est compatible avec IE6 (pas sur LaFibre.info a cause du https), c'est discutable de garder ce support, mais coté serveur refuser de support PHP 7 pour ne pas perdre PHP 4 est incompréhensible.
Bref, pour en revenir à HTTP/2 : il faut pour avoir une version d'Apache récente, un OS avec des soft récent et donc PHP 7. Le blocage de PHP 7 me force à rester sur PHP 5 et sur des versions d'Apache qui ne supportent pas HTTP/2.
Édit, Petites précisions :
Voici les dates de fin de support officiel de PHP :
- PHP 5.3 : 14 août 2014
- PHP 5.4 : 3 septembre 2015
- PHP 5.5 : 10 juillet 2016
- PHP 5.6 : 31 décembre 2018 (durée de vie plus longue car dernière version de PHP 5)
- PHP 7.0 : 3 décembre 2018
- PHP 7.1 : fin 2019
Voici les dates de fin de support des version de PHP dans Ubuntu server :
- Ubuntu 12.04 LTS : PHP 5.3 avec backport des correctif jusqu'en avril 2017
- Ubuntu 14.04 LTS : PHP 5.5 avec backport des correctif jusqu'en avril 2019
- Ubuntu 15.10 : PHP 5.6 avec des correctif jusqu'en juillet 2016
- Ubuntu 16.04 LTS : PHP 7.0 avec backport des correctif jusqu'en avril 2021
Pour être précis sur les raisons de PHP 7 pour Ubuntu 16.04, alors que PHP 5.6 sera supporté plus longtemps que PHP 7.0, il faut préciser qu'il y a de gros changements entre PHP 5.6 et 7.0 et qu'il sera donc plus facile de faire des backport depuis PHP 7.1/PHP7.2/PHP7.3 vers PHP 7.0 plutôt que PHP 5.3
C'est la même chose pour les autres distributions avec un support de longue durée. Une exception pour Debian, qui fait des upgrade de logiciels lors de la bacul du support normal (2ans premières années) vers l'équipe de support LTS (3ème année à 5ème année).
Il faut préciser que Debian sort avec des logiciels moins récents qu'une Ubuntu, ce qui complique encore plus les choses pour le support LTS.
-
Pas seulement Chrome et Firefox : Internet Explorer 11 sous Win10, Microsoft Edge, Safari sous OS 10.11 et Opéra on aussi choisit de ne proposer HTTP/2 que sur SSL :
TLS, pas SSL, STP!
-
Et sinon, vous avez compris le pb de sécurité soulevé par http/2 ? (visiblement ce n'est pas l'implèmentation dans un navigateur qui pose pb mais http/2 de manière globale)
Quelle est la raison de sécurité de suppression de MathML dans Chromium?
MathML est normalisé, a une utilité théorique mais en pratique est peu utilisé, il y a des alternatives fonctionnelles (mais qui ne sont pas normalisées ni aussi efficaces). Surtout, c'était un code pas simple qu'ils devaient considérer comme trop coûteux à vérifier.
-
J'ai déplacé les propositions de changer le moteur du forum (aujourd'hui SMF) dans un autre sujet : Passer le forum sous Discourse ? (https://lafibre.info/evolution/passer-le-forum-sous-discourse/)
-
Quelle est la raison de sécurité de suppression de MathML dans Chromium?
MathML est normalisé, a une utilité théorique mais en pratique est peu utilisé, il y a des alternatives fonctionnelles (mais qui ne sont pas normalisées ni aussi efficaces). Surtout, c'était un code pas simple qu'ils devaient considérer comme trop coûteux à vérifier.
De mémoire, la même chose a été faîte pour Gopher sous Firefox. Un mauvais buffer overflow au niveau des URL a été trouvé ce qui a précipité la décision.
L'équipe de Chrome avait pensé à faire la même chose pour FTP à une époque, mais ça n'a pas été concrétisé.
-
J'avais même vu des discussions pour mettre à la benne le code FTP de FF! Ce qui avait engendré de fortes protestations.
-
La suppression du mod http/2 de Apache 2.4.18 n'est pas un oubli: c'est une suppression volontaire (je n'ai pas compris pourquoi)
- Don't build experimental http2 module for LTS:
+ debian/control: removed libnghttp2-dev Build-Depends (in universe).
+ debian/config-dir/mods-available/http2.load: removed.
Source : https://launchpad.net/ubuntu/xenial/+source/apache2/+changelog
L'auteur de la suppression de http/2 est Marc Deslauriers (https://launchpad.net/~mdeslaur) (Un salarié de Canonical qui est "Ubuntu Security Engineer" et qui était consultant en sécurité chez un grand FAI, avant de passer chez Canonical). J'imagine qu'il y a des pb de sécurité dans la décision de supprimer http/2.
Coté Debian unstable, http/2 semble bien présent : http://metadata.ftp-master.debian.org/changelogs/main/a/apache2/apache2_2.4.18-1_changelog
Pas de http/2 pour Ubuntu server 16.04 ni Ubuntu server 16.10.
J'ai regardé pour Ubuntu server 17.04, actuellement en développement et déception :
# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu Zesty Zapus (development branch)
Release: 17.04
Codename: zesty
# apache2 -v
Server version: Apache/2.4.23 (Ubuntu)
Server built: 2016-11-16T14:17:24
# a2enmod http2
ERROR: Module http2 does not exist!
Voici le contenu de /etc/apache2/mods-available/ :
# l /etc/apache2/mods-available/
access_compat.load authz_owner.load dir.conf log_debug.load proxy_fdpass.load setenvif.load
actions.conf authz_user.load dir.load log_forensic.load proxy_ftp.conf slotmem_plain.load
actions.load autoindex.conf dump_io.load lua.load proxy_ftp.load slotmem_shm.load
alias.conf autoindex.load echo.load macro.load proxy_hcheck.load socache_dbm.load
alias.load buffer.load env.load mime.conf proxy_html.conf socache_memcache.load
allowmethods.load cache_disk.conf expires.load mime.load proxy_html.load socache_shmcb.load
asis.load cache_disk.load ext_filter.load mime_magic.conf proxy_http.load speling.load
auth_basic.load cache.load file_cache.load mime_magic.load proxy.load ssl.conf
auth_digest.load cache_socache.load filter.load mpm_event.conf proxy_scgi.load ssl.load
auth_form.load cern_meta.load headers.load mpm_event.load proxy_wstunnel.load status.conf
authn_anon.load cgid.conf heartbeat.load mpm_prefork.conf ratelimit.load status.load
authn_core.load cgid.load heartmonitor.load mpm_prefork.load reflector.load substitute.load
authn_dbd.load cgi.load ident.load mpm_worker.conf remoteip.load suexec.load
authn_dbm.load charset_lite.load imagemap.load mpm_worker.load reqtimeout.conf unique_id.load
authn_file.load data.load include.load negotiation.conf reqtimeout.load userdir.conf
authn_socache.load dav_fs.conf info.conf negotiation.load request.load userdir.load
authnz_fcgi.load dav_fs.load info.load proxy_ajp.load rewrite.load usertrack.load
authnz_ldap.load dav.load lbmethod_bybusyness.load proxy_balancer.conf sed.load vhost_alias.load
authz_core.load dav_lock.load lbmethod_byrequests.load proxy_balancer.load session_cookie.load xml2enc.load
authz_dbd.load dbd.load lbmethod_bytraffic.load proxy.conf session_crypto.load
authz_dbm.load deflate.conf lbmethod_heartbeat.load proxy_connect.load session_dbd.load
authz_groupfile.load deflate.load ldap.conf proxy_express.load session.load
authz_host.load dialup.load ldap.load proxy_fcgi.load setenvif.conf
Il devrait y avoir une évolution vers une version plus récente d'Apache2 (2.4.25 ou 2.4.26) d'ici la sorite, espérons que cela proposé.
-
Perso j'ai installé un PPA alternatif pour avoir HTTP/2 sur mes machines ubuntu. C'est vraiment dommage, Debian Stretch a HTTP/2 lui...
-
Tu as compris pourquoi ?
J'ai compris pour Ubuntu 16.04 LTS : il y a un support de 5 ans sur une même version d'Apache2 et les équipes doivent faire des correctifs pour les pb de sécurité qui sont corrigés dans les versions ultérieures d'Apache2 et mod http2 étant jeune, il va y avoir de très nombreuses modifications (c'est vrai) et corriger une ancienne version radicalement différente est complexe.
Pour les versions avec un support de 9mois comme Ubuntu 16.10 et Ubuntu 17.04, cet argument n'est pas valable.
Pour Ubuntu 17.04, il est indiqué "Don't build experimental http2 module for LTS:" or ce n'est pas une version LTS !
J'ouvre un bug ?
apache2 (2.4.23-8ubuntu1) zesty; urgency=medium
* Merge from Debian unstable (LP: #). Remaining changes:
- Don't build experimental http2 module for LTS:
+ debian/control: removed libnghttp2-dev Build-Depends (in universe).
+ debian/config-dir/mods-available/http2.load: removed.
+ debian/rules: removed proxy_http2 from configure.
+ debian/apache2.maintscript: remove http2 conffile.
[ Previously undocumented ]
Source : https://launchpad.net/ubuntu/zesty/+source/apache2/+changelog
-
Une bonne occasion pour passer à nginx :P
-
Bug crée : https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1658469
J’espère qu'il ne sera pas rejeté car Apache le considère toujours comme expérimental :
Warning
This module is experimental. Its behaviors, directives, and defaults are subject to more change from release to release relative to other standard modules. Users are encouraged to consult the "CHANGES" file for potential updates.
Source : https://httpd.apache.org/docs/2.4/mod/mod_http2.html
Maintenant Ubuntu 17.04 n'est pas une version LTS et a un support de seulement 9 mois. La prise de risque est faible.
Je vais regarder si Debian le laisse dans Debian 9. Si c'est le cas, Ubuntu n'a aucune excuse.
-
Une bonne occasion pour passer à nginx :P
Je confirme ;D
C'est ce que j'ai fait chez moi (sauf pour observium, je n'ai pas regardé si c'est faisable simplement). Après, en pratique, chez moi tous les sites web sont derrière un reverse proxy nginx (because une seule IPv4, évidemment).
-
Severe vulnerabilities discovered in HTTP/2 protocol
Four high-profile bugs have been found in the protocol, potentially placing 85 million websites at risk.
Researchers have discovered a number of security issues related to the new HTTP/2 protocol which could place millions of websites at risk of attack.
On Wednesday at Black Hat USA, cybersecurity firm Imperva released new research into a number of high-profile flaws found within the latest version of HTTP, HTTP/2, which underpins the worldwide web's underlying protocols and communication systems.
The report, HTTP/2: In-depth analysis of the top four flaws of the next generation web protocol (.PDF), details four main vulnerabilities and attack vectors related to HTTP/2, of which adoption is steadily increasing.
According to W3Techs, 8.7 percent of all websites -- roughly 85 million -- have adopted the new standard, which is meant to improve how browsers and servers communicate, speeding up the online experience.
The attack vectors discovered include:
- Slow read: The attack calls on a malicious client to read responses very slowly -- identical to the Slowloris DDoS attack which hit financial institutions in 2010 -- and despite slow read attacks being well-known in the HTTP ecosystem, they are still effective in the latest evolution of the web protocol. However, this time, they take place in the application layer of HTTP/2 implementations. Variants of this vulnerability have been discovered across Apache, IIS, Jetty, NGINX, and nghttp2.
- HPACK Bomb: The researchers say this attack resembles a "zip bomb," a malicious archive file designed to crash the program or system reading it and often used to disable antivirus software. Small and innocent-looking messages explode into gigabytes of a data on a server, siphoning away all server memory resources and effectively taking it offline.
- Dependency Cycle attack: HTTP/2 introduced a new flow control mechanism designed to optimize networks. However, the mechanism can be exploited should an attacker craft requests which create a dependency cycle -- creating an infinite loop which cannot be escaped when the flow control system attempts to process these requests.
- Stream Multiplexing Abuse: The final main issue emerges when attackers use security flaws present in how servers implement stream multiplexing functionality. These bugs can crash servers, resulting in a denial of service to legitimate users.
"The general web performance improvements and specific enhancements for mobile applications introduced in HTTP/2 are a potential boon for internet users," said Amichai Shulman, co-founder and CTO of Imperva.
"However, releasing a large amount of new code into the wild in a short time creates an excellent opportunity for attackers," Shulman added. "While it is disturbing to see known HTTP 1.x threats introduced in HTTP/2, it's hardly surprising. As with all new technology, it is important for businesses to perform due diligence and implement safeguards to harden the extended attack surface and protect critical business and consumer data from ever-evolving cyber threats."
In related news, at Black Hat, Rapid7 security researcher Weston Hacker demonstrated a $6 tool which can be used to compromise and break into keycard-based hotel rooms.
Source : ZD Net (http://www.zdnet.com/article/severe-vulnerabilities-discovered-in-http2-protocol/), la 4 août 2016
(c'est mal écrit mais les idées y sont)
-
Je dirais plus que c'est l’occasion de passer sur Debian, j'utilise tout les jours http2 sur ma Debian jessie avec apache sortie tout droit du dépôt stretch.
-
Non merci ;)
-
C'est ce que j'ai fait chez moi (sauf pour observium, je n'ai pas regardé si c'est faisable simplement).
Ouep, j'en ai déjà vu :)
(3000 messages \o/ )
-
Bug crée : https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1658469
J’espère qu'il ne sera pas rejeté car Apache le considère toujours comme expérimental :
Warning
This module is experimental. Its behaviors, directives, and defaults are subject to more change from release to release relative to other standard modules. Users are encouraged to consult the "CHANGES" file for potential updates.
La réponse, https2 arrive avec Ubuntu 17.10 en octobre 2017 :
apache2 is now stuck in proposed. This is becuase nghttp2 (src package) is in universe, and so is libnghttp2-14 which apache2 depends on when enabling http2. We would need a MIR to promote nghttp2 and given where we are in the cycle, that seems unlikely to be approved. Additionally, regardless of Debian, upstream apache still considers it experimental: https://httpd.apache.org/docs/2.4/mod/mod_http2.html.
Given all that, I'm much more comfortable aiming for HTTP2 support in 17.10, as anticipatory of 18.04 and will pursue the MIR and needed first thing in that cycle.
Traduction rapide en français :
Apache2 est maintenant figé pour Ubuntu 17.04. C'est parce que le paquet nghttp2 et donc est libnghttp2-14 dont apache2 dépend lors de l'activation de http2. Nous aurions besoin d'un paquet MIR pour promouvoir nghttp2 et étant donné vu que nous somme en fin de cycle pour Ubuntu 17.04, il y a peu de chance d'être approuvé. De plus, indépendamment de Debian, en amont, apache2 considère le mode_http2 comme expérimental: https://httpd.apache.org/docs/2.4/mod/mod_http2.html.
Compte tenu de tout cela, je suis beaucoup plus à l'aise a viser une mise en place de HTTP2 pour Ubuntu 17.10, en anticipation d' Ubuntu 18.04 LTS.
-
Je vous invite a lire la suite des échanges : https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1658469
Je n'arrive pas a saisir si le mod http/2 sera disponible pour Ubuntu 17.10 (et donc Ubuntu 18.04LTS) :
18:13 <rbasak> nacc: not sure about bug 1658469
18:13 <ubottu> bug 1658469 in apache2 (Ubuntu) "mod_http2 is not available under Apache 2.4.23 / Ubuntu 17.04 xenial" [Low,Fix committed] https://launchpad.net/bugs/1658469
18:13 <rbasak> nacc: to my knowledge we've never added and then removed things to avoid putting things in an LTS.
18:13 <teward> rbasak: refer to -hardened and my mention about nghttp2
18:13 <rbasak> Yeah I saw that, but nacc wasn't in that channel.
18:14 <teward> yep.
18:14 <teward> nacc: IIRC, the Security team had NACK'd http2 back in Xenial
18:14 <teward> at least nghttp2
18:14 <rbasak> nacc: if it's not good enough for an LTS, it's not good enough for a non-LTS release.
18:14 <teward> (NGINX rolls their own implementation separate from nghttp2)
18:15 -!- knoxy has joined #ubuntu-server
-
Pour moi c'est non...
Quelle décéption, c'est une techno cruciale coté serveur dans l'hébergement Web, c'est 70% (je sais pas si vous vous rendez compte de ce chiffre) du trafic sur un site ou il est activé. C'est franchement idiot de ne pas l'activer, Debian Stretch le propose, Nginx le propose... Ils vont perdre du terrain coté hébergement Web.
Pour les irréductibles, il reste "sudo add-apt-repository ppa:ondrej/apache2", ou c/c le mod depuis Debian :p
-
Osef du fait que ce soit, dixit la doc, experimental ?
-
Si Debian l'a intégré dans Stretch, connaissant la rigueur de la team de validation, ouais, osef.
-
Tu m'en vois interloqué, merci de l'info néanmoins
-
Si Debian l'a intégré dans Stretch, connaissant la rigueur de la team de validation, ouais, osef.
Debian 9 Stretch devrait sortir en milieu d’année 2017, c'est un bon argument que tu devrais rajouter sur https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1658469
Ce serait le comble qu'une nouvelle fonctionnalité sortir en premier sur Debian stable et soit refusé par Ubuntu...
-
Apache 2.4.26 va sortir dans quelques semaines...
Changes with Apache 2.4.26 : HTTP/2 support no longer tagged as "experimental" but is instead considered fully production ready.
La liste des modification http/2 entre Apache 2.4.25 et Apache 2.4.26 est impressionnante :
- mod_http2: Fix for possible CPU busy loop introduced in v1.10.3 where a stream may keep the session in continuous check for state changes that never happen. [Stefan Eissing]
- mod_http2: fail requests without ERROR log in case we need to read interim responses and see only garbage. This can happen if proxied servers send data where none should be, e.g. a body for a HEAD request. [Stefan Eissing]
- mod_proxy_http2: adding support for Reverse Proxy Request headers. [Stefan Eissing]
- mod_http2: fixed possible deadlock that could occur when connections were terminated early with ongoing streams. Fixed possible hanger with timeout on race when connection considers itself idle. [Stefan Eissing]
- mod_http2: MaxKeepAliveRequests now limits the number of times a slave connection gets reused. [Stefan Eissing]
- mod_proxy_http2: Fixed bug in re-attempting proxy requests after connection error. Reliability of reconnect handling improved. [Stefan Eissing]
- mod_http2: better performance, eliminated need for nested locks and thread privates. Moving request setups from the main connection to the worker threads. Increase number of spare connections kept. [Stefan Eissing]
- mod_http2: input buffering and dynamic flow windows for increased throughput. Requires nghttp2 >= v1.5.0 features. Announced at startup
in mod_http2 INFO log as feature 'DWINS'. [Stefan Eissing] - mod_http2: h2 workers with improved scalability for better scheduling performance. There are H2MaxWorkers threads created at start and the number is kept constant for now. [Stefan Eissing]
- mod_http2: obsoleted option H2SessionExtraFiles, will be ignored and just log a warning. [Stefan Eissing]
- mod_http2: moving session cleanup to pre_close hook to avoid races with modules already shut down and slave connections still operating. [Stefan Eissing]
- mod_proxy_http2: support for ProxyPreserverHost directive. [Stefan Eissing]
- mod_http2: fix for crash when running out of memory. [Robert Swiecki <robert swiecki.net>, Stefan Eissing]
- mod_http2: not counting file buckets again stream max buffer limits. Effectively transfering static files in one step from slave to master connection. [Stefan Eissing]
- mod_http2: comforting ap_check_pipeline() on slave connections to facilitate reuse (see https://github.com/icing/mod_h2/issues/128).
[Stefan Eissing, reported by Armin Abfalterer] - mod_http2: http/2 streams now with state handling/transitions as defined in RFC7540. Stream cleanup/connection shutdown reworked to become easier to understand/maintain/debug. Added many asserts on state and cleanup transitions. [Stefan Eissing]
- mod_http2: regression fix on PR 59348, on graceful restart, ongoing streams are finished normally before the final GOAWAY is sent. [Stefan Eissing, <slavko gmail.com>]
- mod_http2: fixes PR60599, sending proper response for conditional requests answered by mod_cache. [Jeff Wheelhouse, Stefan Eissing]
- mod_http2: rework of stream resource cleanup to avoid a crash in a close of a lingering connection. Prohibit special file bucket beaming for shared buckets. Files sent in stream output now use the stream pool as read buffer, reducing memory footprint of connections. [Yann Ylavic, Stefan Eissing]
- mod_http2: fix for possible page fault when stream is resumed during session shutdown. [sidney-j-r-m (github)]
- mod_http2: fix for h2 session ignoring new responses while already open streams continue to have data available. [Stefan Eissing]
- mod_http2: adding support for MergeTrailers directive. [Stefan Eissing]
- mod_http2: limiting DATA frame sizes by TLS record sizes in use on the connection. Flushing outgoing frames earlier. [Stefan Eissing]
- mod_http2: cleanup beamer registry on server reload. PR 60510. [Pavel Mateja <pavel verotel.cz>, Stefan Eissing]
- mod_http2: fixes https://github.com/icing/mod_h2/issues/126 e.g. beam bucket lifetime handling when data is sent over temporary pools. [Stefan Eissing]
-
perso j'ai viré Apache & Nginx et je suis passé a Caddy: https://caddyserver.com/
en terme de simplicité et efficacité c'est remarquable. HTTP/2 et gestion completement auto de letsencrypt.
un exemple de config (Caddyfile)
https://mondomain.com, http://mondomain.com {
root /www/mondomain.com
log /logs/mondomain.com.log
gzip
tls me@email.com
}
on lance "caddy" sans paramètre, dans le répertoire du Caddyfile, c'est un exécutable unique (16 Mo environ) sans aucune dépendance de fichier/lib externe.
et c'est tout. il s'occupe de recup des certifs chez LetsEncrypt en utilisant le parametre tls comme email.
et on se retrouve avec un serveur web en http/2
En bonus on a QUIC si on veut, il suffit juste de passer l'option "-quic".
en plus c'est multi-plateforme car en Go:
(http://i.imgur.com/0pFUYSG.png)
donc on peut le mettre dans son routeur ou son Pi. suffit de copier un fichier binaire et les pages du site web. plus simple c'est pas possible.
-
Le point le plus intéressant est qu'il intègre de façon expérimental QUIC (Quick UDP Internet Connections, pronounced quick), utilisé par Google et quelques autres grands acteurs.
Ni Apache, ni Nginx n'ont ce support même en expérimental.
-
http/2 sur Apache sera bien supporté par les prochaines versions d'Ubuntu.
=> https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1658469
J'ai par contre du mal à saisir le lien entre MIR (Mir est un serveur d'affichage développé par Canonical pour les objets connectés) et HTTP/2 dans cette réponse :
Yes, after discussing with others, this (nghttp2) will need to be reviewed for MIR (bug # 1687454 (https://bugs.launchpad.net/ubuntu/+source/nghttp2/+bug/1687454)) but has been uploaded for Artful.
It will probably not be backported to 16.04 or other releases without further review (as the version declaring HTTP/2 stability is 2.4.26 which is not the version in 16.04, etc.)
-
MIR = Main Inclusion Requirement
L'équipe dédiée: https://launchpad.net/~ubuntu-mir
-
perso j'ai viré Apache & Nginx et je suis passé a Caddy: https://caddyserver.com/
en terme de simplicité et efficacité c'est remarquable. HTTP/2 et gestion completement auto de letsencrypt.
un exemple de config (Caddyfile)
https://mondomain.com, http://mondomain.com {
root /www/mondomain.com
log /logs/mondomain.com.log
gzip
tls me@email.com
}
on lance "caddy" sans paramètre, dans le répertoire du Caddyfile, c'est un exécutable unique (16 Mo environ) sans aucune dépendance de fichier/lib externe.
et c'est tout. il s'occupe de recup des certifs chez LetsEncrypt en utilisant le parametre tls comme email.
et on se retrouve avec un serveur web en http/2
En bonus on a QUIC si on veut, il suffit juste de passer l'option "-quic".
en plus c'est multi-plateforme car en Go:
(http://i.imgur.com/0pFUYSG.png)
donc on peut le mettre dans son routeur ou son Pi. suffit de copier un fichier binaire et les pages du site web. plus simple c'est pas possible.
Je connaissais déjà Caddy pour son support de QUIC, mais je l'avais un peu oublié... ^^
Merci du rappel, il faudrait que je tente ! :)
-
On est en période de freeze pour Ubuntu 17.10 - il sort le 19 octobre - et cela a failli coûter la peau du mode HTTP/2, malgré mes relances avant le freeze.
Finalement, cette nuit, Nish Aravamudan de Canonical est intervenu pour justifier une exception au freeze et donner le go pour mettre le mod Http/2 dans Apache qui sera intégré dans Ubuntu 17.10 qui sot dans moins d'un mois : https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1658469
Feature Freeze justification (multiple):
1) This is an entirely new, opt-in feature, currently not available to users. They would need to enable said feature i order to use it.
2) We intend to examine SRU of this feature to 16.04 (and thus would also need to SRU to 17.10 if we wait until 18.04 to do it.) The change is coming either way
3) We want to maximize the exposure/testing of HTTP/2 before 18.04 releases; having it in 17.10 will assist with that.
4) From a practical perspective, this reduces our delta to Debian.
-
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).
-
Ubuntu server LTS
J'ai ouvert un bug en février 2016 (https://lafibre.info/navigateurs/http2-negociation/msg305673/#msg305673) 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 :
(https://lafibre.info/testdebit/curl/201412_comparatif_perf_systemes_exploitations_serveurs_6.png)
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.
-
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...
-
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.
-
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...
-
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.
-
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)
(https://lafibre.info/images/ssl/201809_http2_explained_fr.png) (https://lafibre.info/images/ssl/201809_http2_explained_fr.pdf)
-
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
(https://lafibre.info/images/wireshark/202103_http2_upgrade_1.png)
Les paquets :
(https://lafibre.info/images/wireshark/202103_http2_upgrade_2.png)
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
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/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/
-
À 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)
-
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
-
À 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/
(https://lafibre.info/images/wireshark/202103_http2_prior_knowledge_ipv6_ok_1.png)
(https://lafibre.info/images/wireshark/202103_http2_prior_knowledge_ipv6_ok_2.png)
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
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/202103_http2_prior_knowledge_ipv6_ok.pcapng.gz)
-
Démo en IPv4 avec le même opérateur mobile :
curl --http2-prior-knowledge -4 -o /dev/null http://fr.archive.ubuntu.com/
(https://lafibre.info/images/wireshark/202103_http2_prior_knowledge_ipv6_ipv4.png)
Trace coté client :
(https://lafibre.info/images/wireshark/202103_http2_prior_knowledge_ipv4_echec_client_1.png)
(https://lafibre.info/images/wireshark/202103_http2_prior_knowledge_ipv4_echec_client_2.png)
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
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/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)
(https://lafibre.info/images/wireshark/202103_http2_prior_knowledge_ipv4_echec_serveur_1.png)
(https://lafibre.info/images/wireshark/202103_http2_prior_knowledge_ipv4_echec_serveur_2.png)
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
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/202103_http2_prior_knowledge_ipv4_echec_serveur.pcapng.gz)
-
Démo en IPv6 avec un opérateur mobile :
L'IPv6 trahit l'opérateur ;D
Aucun problème avec Orange : IPv4 (sur APN IPv4 ou IPv6) et IPv6 fonctionnent avec "--http2-prior-knowledge".