Jak aktywować obsługę HTTP / 2 w DirectAdmin (CentOS)

• Kluczowe punkty
• HTTP / 2 i SSL
• FAQ
• Część 1: Apache (serwer WWW)
• Część 2: cURL

HTTP / 2 to najnowsza wersja protokołu HTTP oparta na SPDY. Jego rozwój został zainicjowany przez Google, a HTTP / 2 jest w dużej mierze oparty na bazie kodu i koncepcjach SPDY.

SPDY jest już przestarzałe i trwa wdrażanie na całym świecie protokołu HTTP / 2. Wiele firm hostingowych zapewniło już obsługę protokołu HTTP / 2 ze względu na jego dodatkową prędkość.

W chwili pisania tego tekstu DirectAdmin nie zapewnia sposobu włączenia HTTP / 2 za pomocą jednego kliknięcia. Istnieje jednak wiele sposobów uzyskania obsługi protokołu HTTP / 2. Przedstawiona poniżej metoda okazała się najbardziej niezawodnym i stabilnym podejściem.

Aby komponent HTTP / 2 zadziałał, należy zaktualizować kilka składników. Z tego powodu zdecydowanie radzę zrobić migawkę. Jeśli to możliwe, postępuj zgodnie z tym przewodnikiem na zupełnie nowym serwerze.

Ten przewodnik składa się z dwóch części: włączania obsługi HTTP / 2 na serwerze WWW (Apache) dla klientów (odwiedzających) oraz aktywacji HTTP / 2 w cURL. Włączenie HTTP v2 dla cURL zmusza żądania cURL pochodzące z twojego serwera do korzystania z HTTP / 2 dla jego serwerów docelowych, jeśli to możliwe.

Kluczowe punkty

• Nie jest wymagana aktualizacja zarówno Apache, jak i cURL, aby używać HTTP / 2. W porządku jest przestrzeganie obu przewodników, ponieważ działają one niezależnie od siebie.
• Było kilka dziwnych przypadków, w których Apache i HTTP / 2 wydają się działać poprawnie, ale ładowanie udaje się w „losowych” przeglądarkach, a witryny stają się nieosiągalne (czas oczekiwania) na innych. Po prostu przywrócenie oryginalnej konfiguracji Apache to naprawi, ponieważ Apache nie będzie wiedział o HTTP / 2 i nie będzie próbował podawać zawartości na nim.
• Zawsze rób kopię zapasową lub zrób migawkę z góry. Włączenie HTTP / 2 może być względnie delikatnym procesem, dlatego ważne jest, aby móc cofnąć zmiany w razie potrzeby.
• Ponowne kompilowanie oprogramowania może zawsze powodować niewielkie przestoje. W niektórych przypadkach jest to mniej niż minuta, ale nie można dokładnie powiedzieć. Powinieneś być przygotowany przynajmniej na jakiś czas przestoju.
• W tym przewodniku potrzebujesz dostępu root do serwera. Jeśli nie masz możliwości podniesienia poziomu uprawnień do rootowania, powinieneś skontaktować się z administratorem serwera, aby włączyć HTTP / 2 na serwerze.

HTTP / 2 i SSL

Chociaż nie jest to wymaganiem technicznym samego HTTP / 2, w większości przypadków będziesz potrzebować certyfikatu SSL, aby korzystać z HTTP / 2. Jak wspomniano, HTTP / 2 nie wymaga tego technicznie, ale wiele przeglądarek (Safari, Chrome, Firefox itp.) Stworzyło ten standard. Treść nie będzie wyświetlana przez HTTP / 2, gdy strona zostanie załadowana bez SSL przy użyciu tych przeglądarek. Biorąc pod uwagę, że większość użytkowników korzysta z tych przeglądarek (i innych), które również uczestniczą w tym standardzie, powinieneś użyć certyfikatu SSL.

Jeśli szukasz darmowego certyfikatu SSL, zapoznaj się z jednym z naszych przewodników Let's Encrypt:

Zalecane: instalowanie Let's Encrypt na DirectAdmin

Alternatywne panele sterowania:

• Szyfrujmy w Plesku
• Szyfrujmy na cPanel

Ogólne przewodniki:

• Skonfiguruj LetsEncrypt w systemie Linux
• Instalacja Let's Encrypt With Apache na Ubuntu 14.04
• Instalujmy Szyfrujmy za pomocą Apache na Ubuntu 16.04

FAQ

Czy ten przewodnik opisuje instalację Brotli?

Nie, w tym artykule nie ma opisanej metody instalowania Brotli obok HTTP / 2.

Kompilacja kończy się niepowodzeniem bez powodu i wykonałem dokładnie kroki opisane w tym artykule. Jak to rozwiązać?

Chociaż istnieje wiele możliwych przyczyn, biorąc pod uwagę różne środowiska i tym podobne, być może ustawienia regionalne są nieprawidłowe. Spróbuj LC_ALL=Cpodać swoje komendy, aby komenda do ponownej kompilacji Apache wyglądała następująco: LC_ALL=C ./build apache Nie zapomnij o spacji między LC_ALL=Cpoleceniem!

Czy stracę jakieś dane?

Jeśli używasz obecnie odwrotnej konfiguracji proxy, na przykład z Apache i Nginx, powinieneś przywrócić ją z powrotem do Apache, w którym to przypadku rzeczywiście stracisz pliki konfiguracyjne Nginx. Jeśli wykonałeś niestandardowe konfiguracje VirtualHost (czy to za pośrednictwem wiersza poleceń, czy samego DirectAdmin), powinieneś zmienić je dla poszczególnych domen, aby wersje Apache pozostały aktywne. Nie stracisz żadnych danych w odniesieniu do danych użytkownika, treści strony internetowej, baz danych itp.

Czy te niestandardowe wersje powstrzymają mnie przed aktualizacją pakietów i oprogramowania w przyszłości?

Zasadniczo nie trzeba się tym martwić. Biorąc pod uwagę modułową konfigurację DirectAdmin (a tym samym CustomBuild), powinieneś być w stanie obniżyć lub uaktualnić do innych wersji oprogramowania w przyszłości bez żadnych problemów. Chociaż zmiany należy udokumentować na wypadek, gdyby w przyszłości wymagana była alternatywna ścieżka uaktualnienia, nie trzeba się martwić o wersje niezgodne z nowymi wersjami oprogramowania.

DirectAdmin nie oferuje HTTP / 2 po wyjęciu z pudełka; z pewnością oznacza to, że nie jest kompatybilny lub mają swoje powody, by tego nie robić. Dlaczego to obejście jest wymagane?

Opisane poniżej metody instalowania i włączania HTTP / 2 to nie tyle obejścia, ale jedynie aktualizacje pakietów i zmiany konfiguracji. Ze względu na modułową konfigurację DirectAdmin, zmiany te są całkowicie poprawne i nie powinny powodować problemów ani innych problemów. Trudno jest ustalić, dlaczego DirectAdmin nie obsługuje tego po wyjęciu z pudełka, biorąc pod uwagę, że autorzy nie wyjaśnili tego. Jednak dość solidny wniosek jest taki, że DirectAdmin korzysta z pakietów wersji przez system operacyjny. Zazwyczaj nie są one tak aktualne, jak poniższe pakiety. Nie ma nic złego w HTTP / 2, samej technologii i jej kompatybilności. Podobnie jak wiele innych technologii, natywna adaptacja może zająć trochę czasu.

Jakie jest możliwe ryzyko aktywacji HTTP / 2 za pomocą Apache?

W aktywacji HTTP / 2 (składającej się z procesu aktualizacji i konfiguracji) istnieje wiele zmiennych, które mogą okazać się niestandardowe. Największe ryzyko wiąże się jednak z błędami ludzkimi. Zrób migawkę wcześniej, pamiętaj o ogłoszeniu konserwacji użytkownikom (jeśli są na serwerze poza tobą) i bądź ostrożny. Ponadto nie kopiuj i wklejaj poleceń bez zastanowienia się, co zrobią najpierw.

Zdecydowanie polecam tymczasowe utworzenie osobnej instancji chmury Vultr za pomocą DirectAdmin i przejście przez kolejne kroki. Jeśli coś pójdzie nie tak przy „świeżej” instalacji, będziesz wiedział, gdzie i jak to debugować, abyś nie musiał tego robić w środowisku produkcyjnym.

Część 1: Apache (serwer WWW)

Jeśli obecnie korzystasz z odwrotnego proxy, powróć do środowiska tylko Apache. Wynika to z faktu, że HTTP / 2 jest bardzo trudny do debugowania, jeśli coś pójdzie nie tak. Korzystając ze zintegrowanej funkcjonalności HTTP / 2 Apache, możesz skutecznie wyeliminować bardzo dużą część problemów.

Krok 1: Aktualizacja OpenSSL

W wielu przypadkach twoja wersja OpenSSL nie jest kompatybilna z ALPN, który jest wymagany dla HTTP / 2. Dlatego włączmy ALPN poprzez aktualizację OpenSSL.

Po pierwsze, upewnijmy się, że twoja wersja OpenSSL nie jest kompatybilna, wykonując:

openssl version

Jeśli twoja wersja OpenSSL jest mniejsza niż 1.1.0f, wykonaj następujące czynności jako root. W przeciwnym razie przejdź do kroku 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

Krok 2: Instalowanie nghttp2

Aby HTTP / 2 działał, musimy zainstalować nghttp2. Nghttp2 to implementacja HTTP / 2 (i HPACK) w C. Nghttp2 to połączona wersja klienta / serwera HTTP i proxy w C.

Aby zainstalować nghttp2, wykonaj następujące polecenia. Na szczęście nghttp2 można zbudować bezpośrednio z CustomBuild.

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

Krok 3: Włączanie HTTP / 2 w Apache

Musimy zmienić kilka wartości w pliku konfiguracyjnym Apache, aby mógł korzystać z HTTP / 2. Gdy serwer internetowy nie otrzymuje instrukcji używania alternatywnej wersji HTTP, nie korzysta z niej. Dlatego musimy dodać HTTP / 2 do pliku konfiguracyjnego.

Aby zmiany odniosły skutek, konieczna jest przebudowa Apache poprzez CustomBuild. Ponieważ parametry i wartości używane przez CustomBuild podczas budowania oprogramowania są określone w dedykowanym pliku konfiguracyjnym, najlepszą praktyką jest umieszczenie tych zmian w dedykowanym niestandardowym pliku konfiguracyjnym.

Uwaga: jeśli nie umieścisz tych zmian w pliku niestandardowym, najprawdopodobniej zostaną one nadpisane, a instalacja się zepsuje. Postępuj zgodnie z instrukcjami opisanymi poniżej.

Wykonaj następujące polecenia, aby utworzyć plik i wypełnić go wartościami domyślnymi, abyśmy mogli go później zmienić:

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

Na razie mamy niestandardowy plik, który jest identyczny z domyślnym plikiem konfiguracyjnym dla Apache używanym przez CustomBuild. Musimy zmienić /usr/local/directadmin/custombuild/custom/ap2/configure.apacheplik, zastępując następujący ciąg:

"--with-ssl=/usr" \

z:

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

Uwaga: Upewnij się, że po jednym z ukośników odwrotnych nie ma białych znaków . Nadmiar białych znaków spowoduje przerwanie kompilacji.

Następnie odbuduj Apache. CustomBuild użyje właśnie utworzonego pliku niestandardowej konfiguracji:

./build apache

Krok 4: Zmiana konfiguracji Apache

Apache został teraz przebudowany, w tym niezbędne moduły i ustawienia dla HTTP / 2. Oznacza to, że mamy teraz wersję Apache zainstalowaną na naszym serwerze z obsługą HTTP / 2, ale musimy najpierw powiedzieć Apache, aby faktycznie z niego korzystała.

Dodaj następujące wiersze w /etc/httpd/conf/extra/httpd-includes.conf:

ProtocolsHonorOrder On
Protocols h2 h2c http/1.1

Zapisz te zmiany i przepisz pliki konfiguracyjne, aby były trwałe podczas przebudowy:

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

HTTP / 2 powinien być teraz aktywny na serwerze WWW (Apache).

Krok 5: Uruchom ponownie serwer

Uruchom ponownie serwer, aby upewnić się, że nasze zmiany będą się utrzymywać podczas ponownego uruchamiania. Uruchom ponownie serwer za pomocą panelu sterowania Vultr lub wykonując rebootpolecenie.

Krok 6: Przetestuj HTTP / 2

Funkcjonalność HTTP / 2 można łatwo przetestować za pomocą następującego narzędzia: Test HTTP / 2

Biorąc pod uwagę, że HTTP / 2 jest specyficzne dla serwera i nie może być ograniczone do konkretnej pary domen lub stron internetowych, wprowadzenie dowolnej nazwy domeny wskazującej na serwer, a nawet adres IP serwera powinien działać.

Test pokaże, czy jest w stanie uzyskać dostęp do serwera WWW przez HTTP / 2. W przypadku, gdy narzędzie mówi, że HTTP / 2 jest aktywowany na twoim serwerze, do stron DirectAdmin można teraz dotrzeć poprzez HTTP / 1.1 lub HTTP / 2. W przypadku, gdy obsługa klienta HTTP / 2 nie jest dostępna, jego przeglądarka wróci do wersji HTTP / 1.1.

Jeśli narzędzie nie może połączyć się z twoim serwerem internetowym przez HTTP / 2, ponownie wykonaj powyższe kroki. Ogólnie (ponieważ powyższe kroki nie zastępują niczego aktywnie), nie spowoduje to uszkodzenia ani zepsucia konfiguracji.

Część 2: cURL

Polecam aktualizację cURL, aby mógł uzyskać dostęp do serwerów z obsługą HTTP / 2. W przypadku, gdy serwer nie obsługuje HTTP / 2, nastąpi powrót do HTTP / 1.1.

Krok 1: Dodanie niestandardowego pliku konfiguracyjnego

Podobnie jak w przypadku Apache, stworzymy niestandardowy plik konfiguracyjny, więc cURL zbudowany przez CustomBuild użyje naszych niestandardowych ustawień.

Utwórz katalog:

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

Utwórz plik:

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

Skopiuj i wklej następującą zawartość do pliku:

#!/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

Jak widać, te treści nakazują kompilację cURL przy użyciu lib_http2biblioteki SSL.

Zapisz plik i nadaj mu poprawne uprawnienia:

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

Krok 2: Budowanie cURL

Następnie wystarczy zbudować cURL.

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

cURL został teraz skompilowany z obsługą HTTP 2.