Comment activer la prise en charge HTTP / 2 sur DirectAdmin (CentOS)

• Points clés
• HTTP / 2 et SSL
• FAQ
• Partie 1: Apache (serveur Web)
• Partie 2: cURL

HTTP / 2 est la dernière version du protocole HTTP, basée sur SPDY. Son développement a été initié par Google et HTTP / 2 est largement basé sur la base de code et les concepts de SPDY.

SPDY est désormais obsolète et l'adoption mondiale de HTTP / 2 est en cours. De nombreuses sociétés d'hébergement ont déjà pris en charge HTTP / 2 en raison de sa vitesse supplémentaire.

Au moment de la rédaction, DirectAdmin ne fournit pas de méthode en un clic pour activer HTTP / 2. Cependant, il existe plusieurs façons d'obtenir la prise en charge HTTP / 2. La méthode décrite ci-dessous s'est avérée être l'approche la plus robuste et la plus stable.

Plusieurs composants doivent être mis à jour pour que HTTP / 2 prenne effet. Pour cette raison, je vous conseille fortement de prendre un instantané. Si possible, suivez ce guide sur un tout nouveau serveur.

Ce guide se compose de deux parties: l'activation de la prise en charge HTTP / 2 dans le serveur Web (Apache) pour les clients (visiteurs) et l'activation de HTTP / 2 dans cURL. L'activation de HTTP v2 pour cURL force les demandes cURL provenant de votre serveur à utiliser HTTP / 2 pour ses serveurs de destination, si possible.

Points clés

• Il n'est pas nécessaire de mettre à jour Apache et cURL pour utiliser HTTP / 2. C'est bien si vous suivez l'un ou l'autre des guides, car ils fonctionnent séparément l'un de l'autre.
• Il y a eu quelques cas étranges dans lesquels Apache et HTTP / 2 semblent fonctionner correctement, mais le chargement réussit sur les navigateurs et les sites `` aléatoires '' deviennent inaccessibles (timeout) sur d'autres. Le simple fait de revenir à la configuration Apache d'origine résoudra ce problème, car Apache ne connaîtra pas HTTP / 2 et ne tentera pas de diffuser du contenu dessus.
• Faites toujours une sauvegarde ou faites un instantané à l'avance. L'activation de HTTP / 2 peut être un processus relativement fragile, il est donc important de pouvoir annuler les modifications si nécessaire.
• La recompilation du logiciel peut toujours provoquer un léger temps d'arrêt. Dans certains cas, cela prend moins d'une minute, mais il n'y a aucun moyen de le dire exactement. Vous devez au moins être prêt pour un temps d'arrêt.
• Vous avez besoin d'un accès root au serveur pour ce guide. Si vous n'avez pas la possibilité d'élever votre niveau d'autorisation à la racine, vous devez contacter l'administrateur du serveur pour activer HTTP / 2 sur le serveur.

HTTP / 2 et SSL

Bien que ce ne soit pas une exigence technique de HTTP / 2 lui-même, dans la plupart des cas, vous aurez besoin d'un certificat SSL pour utiliser HTTP / 2. Comme mentionné, HTTP / 2 ne l'exige pas techniquement, mais de nombreux navigateurs (Safari, Chrome, Firefox, etc.) ont créé cette norme. Le contenu ne sera pas diffusé via HTTP / 2 lorsqu'une page est chargée sans SSL à l'aide de ces navigateurs. Étant donné que la plupart des utilisateurs utilisent ces navigateurs (et d'autres) qui participent également à cette norme, vous devez utiliser un certificat SSL.

Si vous recherchez un certificat SSL gratuit, vous devriez jeter un œil à l'un de nos guides Let's Encrypt:

Recommandé: l' installation de Let's Encrypt sur DirectAdmin

Panneaux de commande alternatifs:

• Encryptons sur Plesk
• Cryptons sur cPanel

Guides généraux:

• Configuration de LetsEncrypt sur Linux
• Configuration Encryptons avec Apache sur Ubuntu 14.04
• Configuration Cryptons avec Apache sur Ubuntu 16.04

FAQ

Ce guide documente-t-il l'installation de Brotli?

Non, aucune méthode n'est décrite pour installer Brotli avec HTTP / 2 dans cet article.

La compilation échoue sans raison et j'ai suivi les étapes exactes décrites dans cet article. Comment résoudre ça?

Même s'il existe de nombreuses raisons possibles à cela, compte tenu des différents environnements et similaires, vos paramètres régionaux ne sont peut-être pas corrects. Essayez de placer LC_ALL=Cdevant vos commandes, pour que la commande de recompilation d'Apache ressemble à ceci par exemple: LC_ALL=C ./build apache N'oubliez pas l'espace entre LC_ALL=Cet la commande!

Vais-je perdre des données?

Dans le cas où vous utilisez actuellement une configuration de proxy inverse, par exemple avec Apache et Nginx, vous devez la restaurer à Apache, auquel cas vous perdriez en effet vos fichiers de configuration Nginx. Si vous avez créé des configurations VirtualHost personnalisées (que ce soit via la ligne de commande ou DirectAdmin lui-même), vous devez les modifier par domaine afin que les versions d'Apache restent actives. Vous ne perdrez aucune donnée concernant les données utilisateur, le contenu du site Web, les bases de données, etc.

Ces versions personnalisées m'empêcheront-elles de mettre à jour les packages et les logiciels à l'avenir?

En règle générale, il n'y a pas lieu de s'inquiéter à ce sujet. Compte tenu de la configuration modulaire de DirectAdmin (et donc de CustomBuild), vous devriez être en mesure de rétrograder ou de mettre à niveau vers d'autres versions logicielles à l'avenir sans aucun problème. Bien que vous deviez documenter les modifications au cas où un chemin de mise à niveau alternatif serait requis à l'avenir, il ne devrait pas être nécessaire de vous soucier des versions incompatibles avec les nouvelles versions du logiciel.

DirectAdmin n'offre pas HTTP / 2 prêt à l'emploi; cela signifie sûrement que ce n'est pas compatible ou ils ont leurs raisons de ne pas l'être. Pourquoi cette solution de contournement est-elle nécessaire?

Les méthodes d'installation et d'activation de HTTP / 2 décrites ci-dessous ne sont pas tant des solutions de contournement, mais uniquement de simples mises à jour de packages et des changements de configuration. En raison de la configuration modulaire de DirectAdmin, ces modifications sont parfaitement correctes et ne devraient pas causer de problèmes ou d'autres problèmes. Il est difficile de déterminer pourquoi DirectAdmin ne prend pas cela en charge, étant donné que les auteurs n'ont pas donné d'explication à cela. Cependant, une conclusion assez solide est que DirectAdmin utilise les packages de version par le système d'exploitation. Ceux-ci ne sont généralement pas aussi à jour que les packages ci-dessous. Il n'y a rien de mal avec HTTP / 2, la technologie elle-même et sa compatibilité. Tout comme de nombreuses autres technologies, l'adaptation native peut prendre un certain temps.

Quels sont les risques possibles d'activer HTTP / 2 avec Apache?

Dans l'activation de HTTP / 2 (consistant en un processus de mise à niveau et de configuration), de nombreuses variables peuvent s'avérer non standard. Le plus grand risque réside cependant dans l'erreur humaine. Prenez un instantané au préalable, assurez-vous d'annoncer la maintenance à vos utilisateurs (s'il y en a sur le serveur en dehors de vous) et soyez prudent. De plus, ne copiez et ne collez pas les commandes sans penser à ce qu'elles font d'abord.

Je recommande fortement de lancer temporairement une instance de cloud Vultr distincte avec DirectAdmin et de parcourir les étapes. En cas de problème lors d'une nouvelle installation, vous saurez où et comment le déboguer afin de ne pas avoir à le faire dans un environnement de production.

Partie 1: Apache (serveur Web)

Si vous utilisez actuellement un proxy inverse, vous devez revenir à un environnement Apache uniquement. En effet, HTTP / 2 est très difficile à déboguer en cas de problème. En étant en mesure d'utiliser la fonctionnalité intégrée HTTP / 2 d'Apache, vous êtes en mesure d'éliminer une très grande partie des problèmes.

Étape 1: mise à niveau d'OpenSSL

Dans de nombreux cas, votre version OpenSSL n'est pas compatible avec ALPN, qui est requis pour HTTP / 2. Par conséquent, activons ALPN en mettant à jour OpenSSL.

Tout d'abord, assurez-vous que votre version d'OpenSSL n'est pas compatible en exécutant:

openssl version

Si votre version d'OpenSSL est inférieure à 1.1.0f, exécutez ce qui suit en tant que root. Sinon, passez à l'étape 2.

cd ~
wget ftp://ftp.openssl.org/source/openssl-1.1.0f.tar.gz
tar xzf openssl-1.1.0f.tar.gz
cd openssl-1.1.0f
./config --prefix=/usr/local/lib_http2 no-ssl2 no-ssl3 zlib-dynamic -fPIC
make depend
make install

Étape 2: installation de nghttp2

Pour que HTTP / 2 fonctionne, nous devons installer nghttp2. Nghttp2 est une implémentation de HTTP / 2 (et HPACK) en C. Nghttp2 est une version combinée du client, du serveur et du proxy HTTP / 2 en C.

Pour installer nghttp2, exécutez les commandes suivantes. Heureusement, nghttp2 peut être construit directement à partir de CustomBuild.

cd /usr/local/directadmin/custombuild
./build update
./build nghttp2

Étape 3: activation de HTTP / 2 dans Apache

Nous devons modifier quelques valeurs dans le fichier de configuration Apache pour qu'il utilise HTTP / 2. Lorsque le serveur Web n'obtient pas d'instructions pour utiliser une autre version HTTP, il ne s'en servira pas. Par conséquent, nous devons ajouter HTTP / 2 au fichier de configuration.

Pour que ces modifications prennent effet, une reconstruction d'Apache via CustomBuild est nécessaire. Comme les paramètres et les valeurs utilisés par CustomBuild lors de la création du logiciel sont déterminés dans un fichier de configuration dédié, la meilleure pratique consiste à placer ces modifications dans un fichier de configuration personnalisé dédié.

Remarque: si vous ne placez pas ces modifications dans un fichier personnalisé, elles seront très probablement écrasées et votre configuration sera interrompue. Veuillez suivre les instructions ci-dessous.

Exécutez les commandes suivantes afin de créer le fichier et pré-remplissez-le avec les valeurs par défaut afin que nous puissions le modifier par la suite:

mkdir -p /usr/local/directadmin/custombuild/custom/ap2
cp -p /usr/local/directadmin/custombuild/configure/ap2/configure.apache /usr/local/directadmin/custombuild/custom/ap2/configure.apache

Pour l'instant, nous avons un fichier personnalisé qui est identique au fichier de configuration par défaut pour Apache utilisé par CustomBuild. Nous devons modifier le /usr/local/directadmin/custombuild/custom/ap2/configure.apachefichier en remplaçant la chaîne suivante:

"--with-ssl=/usr" \

avec:

"--enable-http2" \
"--enable-ssl-staticlib-deps" \
"--with-ssl=/usr/local/lib_http2" \

Remarque: assurez-vous qu'il n'y a pas d'espace blanc après l'une des barres obliques inverses . Un espace blanc excessif entraînera la rupture de la version.

Ensuite, reconstruisez Apache. CustomBuild utilisera le fichier de configuration personnalisé que vous venez de créer:

./build apache

Étape 4: modification de la configuration Apache

Apache a maintenant été reconstruit, y compris les modules et paramètres nécessaires pour HTTP / 2. Cela signifie que nous avons maintenant une version Apache installée sur notre serveur avec le support de HTTP / 2, mais nous devons dire à Apache de l'utiliser réellement en premier.

Ajoutez les lignes suivantes dans /etc/httpd/conf/extra/httpd-includes.conf:

ProtocolsHonorOrder On
Protocols h2 h2c http/1.1

Enregistrez ces modifications et réécrivez les fichiers de configuration afin qu'ils soient persistants lors des reconstructions:

cd /usr/local/directadmin/custombuild
./build rewrite_confs

HTTP / 2 devrait maintenant être actif sur votre serveur Web (Apache).

Étape 5: redémarrer le serveur

Redémarrez le serveur pour vous assurer que nos modifications persistent lors des redémarrages. Veuillez redémarrer le serveur via le panneau de configuration Vultr ou en exécutant la rebootcommande.

Étape 6: testez HTTP / 2

La fonctionnalité de HTTP / 2 peut facilement être testée en utilisant l'outil suivant: Test HTTP / 2

Étant donné que HTTP / 2 est spécifique au serveur et ne peut pas être limité à une paire spécifique de domaines ou de sites Web, la saisie d'un nom de domaine pointant vers le serveur ou même l'adresse IP du serveur devrait fonctionner.

Le test vous dira s'il est capable d'atteindre le serveur Web via HTTP / 2. Si l'outil indique que HTTP / 2 est activé sur votre serveur, les sites Web DirectAdmin peuvent désormais être atteints via HTTP / 1.1 ou HTTP / 2. Si la prise en charge HTTP / 2 n'est pas disponible pour le client (visiteur), son navigateur reviendra à HTTP / 1.1.

Si l'outil ne peut pas atteindre votre serveur Web via HTTP / 2, suivez à nouveau les étapes ci-dessus. Généralement (comme les étapes ci-dessus n'écrasent rien de manière active), cela n'endommagera ni ne cassera votre configuration.

Partie 2: cURL

Je recommande de mettre à jour cURL afin qu'il puisse atteindre les serveurs avec le support HTTP / 2. Si un serveur ne prend pas en charge HTTP / 2, il retombera sur HTTP / 1.1.

Étape 1: ajout du fichier de configuration personnalisé

Tout comme avec Apache, nous allons créer un fichier de configuration personnalisé afin que cURL construit par CustomBuild utilise nos paramètres personnalisés.

Créez le répertoire:

mkdir -p /usr/local/directadmin/custombuild/custom/curl

Créez le fichier:

touch /usr/local/directadmin/custombuild/custom/curl/configure.curl

Copiez et collez le contenu suivant dans le fichier:

#!/bin/sh
perl -pi -e 's|CURL_CHECK_PKGCONFIG\(zlib\)|#CURL_CHECK_PKGCONFIG(zlib)|g' configure.ac
LIBS="-ldl" ./configure --with-nghttp2=/usr/local --with-ssl=/usr/local/lib_http2

Comme vous pouvez le voir, ces contenus indiquent à cURL d'être compilé à l'aide de la lib_http2bibliothèque SSL.

Enregistrez le fichier et donnez-lui les autorisations appropriées:

chmod 700 /usr/local/directadmin/custombuild/custom/curl/configure.curl

Étape 2: Construction de cURL

Ensuite, tout ce que nous devons faire est de construire cURL.

cd /usr/local/directadmin/custombuild
./build curl

cURL a maintenant été compilé avec le support HTTP 2.