TL;DR : HTTP/2 est possible uniquement au-dessus de TLS avec nginx. HTTP/2 est possible avec ou sans TLS avec Apache httpd, mais, avec un système Debian GNU/Linux Stretch cela nécessite mpm_event ou mpm_worker (c'est recommandé par la fondation Apache pour Debian Buster et autres systèmes), ce qui, dans mon cas, signifie migrer préalablement vers PHP FPM. Bref, j'ai encore du taff.
Que faire en 2020 pour avoir la hype alors qu'on est un retardataire blasé par le progrès technique ? Activer TLS 1.3, la nouvelle version du protocole de sécurisation (confidentialité, authenticité et intégrité) des communications sur Internet ? Le retardataire a uniquement des systèmes Debian Stretch qui livrent la version 1.1.0 d'OpenSSL. Or, la version 1.3 de TLS nécessite la version 1.1.1 d'OpenSSL au minimum.
Bon bah alors, activer HTTP/2, le nouveau protocole qui soutient le web ? Faisons ça, avec Apache httpd et nginx.
Avec la version d'Apache httpd packagée dans la version Stretch de Debian GNU/Linux, il n'est pas possible d'activer HTTP/2 avec le module de multitraitements mpm_prefork (source, confirmé par /usr/share/doc/apache2/NEWS.Debian.gz). Notons que la documentation officielle Apache httpd ne recommande pas d'activer HTTP/2 avec mpm_prefork et préconise plutôt l'utilisation de mpm_event.
Oui, mais avec mpm_event (ou mpm_worker), il n'est pas possible d'utiliser le module PHP pour Apached httpd (car mpm_event est multithread, pas le module PHP). Il faut utiliser FPM ou FastCGI. Hé ouais, le retardataire utilise encore le module PHP…
Du coup, le test de HTTP/2 se fait ainsi :
a2dismod php7.0
;a2dismod mpm_prefork && a2enmod mpm_event
;apt-get install libgcc-6-dev
;/etc/apache/apache2.conf
: LoadFile /usr/lib/gcc/x86_64-linux-gnu/6/libgcc_s.so.1
;a2enmod http2
;Protocols h2 h2c http/1.1
dans /etc/apache2/mods-available/http2.conf
). On peut surcharger ça dans un serveur virtuel. Pour un serveur virtuel HTTPS (TLS), la ligne de config' est Protocols h2 http/1.1
. Pour un serveur virtuel HTTP, la ligne de config' est : Protocols h2c http/1.1
. On peut aussi mettre du h2c dans du TLS, le module sait faire avec même si ça produira aucun effet ;systemctl restart apache2
.J'ai jamais eu de PHP sur mon serveur web géré par nginx et il y a jamais eu d'histoire de module de pré-traitement avec nginx. Du coup, l'activation d'HTTP/2 devrait être plus facile que pour Apache httpd, non ? Oui avec un serveur virtuel HTTPS (TLS), non avec un serveur virtuel HTTP.
systemctl restart nginx
.Sans TLS, le client web ne peut pas utiliser l'extension TLS ALPN (Application Layer Protocol Negociation) pour indiquer qu'il veut communiquer en HTTP/2.
Le client web pourrait causer HTTP/1.1 et positionner l'entête « Upgrade: h2c » qui est l'un des mécanismes permettant de monter en HTTP/2, mais nginx ne permet pas cela.
Il reste une possibilité : que le serveur positionne un entête HTTP Alternative Services qui indique au client que le même service est disponible en HTTP/2. Le client web cause alors en HTTP/2 en utilisant la méthode « prior knowledge » (différente de TLS + ALPN et de HTTP/1.1 + entête Upgrade). Sauf que, si l'on positionne la directive de configuration « http2 » sur une socket HTTP, nginx cause directement HTTP/2, donc pas de HTTP/1.1 (ou 1.0) avec un entête pour informer le client web. Donc le serveur virtuel devient accessible uniquement en HTTP/2. Il faudrait que le serveur virtuel port 80 positionne cet entête en redirigeant vers un serveur virtuel sur le port 81, par exemple. Sauf que, à ce jour, les clients web (cURL y compris) n'implémentent pas les services alternatifs HTTP.
Si l'on veut, on peut activer HTTP/2 comme dans un serveur virtuel HTTPS et tester avec curl -D - --http2-prior-knowledge <URL>
. Mais, pour rappel, ton site web ne sera plus accessible en HTTP/1.1 ou HTTP/1.0. Ni en HTTP/2 avec la plupart des clients web actuels.
Apache httpd ou nginx, il faut tester le bon fonctionnement des manipulations décrites ci-dessus.
On peut tester avec curl -D - --http2 <URL>
(« -D - » permet d'afficher les entêtes HTTP de la réponse, donc de vérifier la présence d'un « HTTP/2 » dès la première ligne).
On peut aussi utiliser l'onglet réseau des outils de développement de Firefox, mais, attention si tu utilises HTTP (non sécurisé) : Firefox ne positionne pas l'entête HTTP/1.1 « Upgrade: h2c » qui est l'un des mécanismes permettant de monter en HTTP/2. Curl le positionne. Bref, toujours avoir un wireshark
en bandoulière.
On peut enfin regarder le journal des requêtes sur son serveur web, car la version y est mentionnée genre « GET / HTTP/2.0 ».
Bref, HTTP/2 avec Apache httpd, ça fonctionne, mais ça nécessite que je migre du module PHP à PHP-FPM ou que je mette à jour mon système vers la version Buster de Debian. Avec nginx, HTTP/2 fonctionne uniquement au-dessus de TLS en attendant que les clients web prennent en charge les services alternatifs HTTP ou que nginx gère h2c (« HTTP/2 in clear ») sans connaissance préalable de la part du client.