Kako aktivirati podporo HTTP/2 v DirectAdmin (CentOS)

HTTP/2 je najnovejša različica protokola HTTP, ki temelji na SPDY. Njegov razvoj je začel Google in HTTP/2 v veliki meri temelji na kodni bazi in konceptih SPDY.

SPDY je zdaj opuščen in v teku je sprejetje HTTP/2 po vsem svetu. Številna gostiteljska podjetja so že zagotovila podporo za HTTP/2 zaradi njegove dodane hitrosti.

V času pisanja DirectAdmin ne ponuja načina za omogočanje HTTP/2 z enim klikom. Vendar pa obstaja več načinov za dosego podpore HTTP/2. Spodaj opisana metoda se je izkazala za najbolj robusten in stabilen pristop.

Več komponent je treba posodobiti, da HTTP/2 začne veljati. Zaradi tega vam močno svetujem, da naredite posnetek. Če je mogoče, sledite tem navodilom na popolnoma novem strežniku.

Ta priročnik je sestavljen iz dveh delov: omogočanja podpore HTTP/2 v spletnem strežniku (Apache) za odjemalce (obiskovalce) in aktivacije HTTP/2 v cURL. Če omogočite HTTP v2 za cURL, prisilite zahteve cURL, ki izvirajo iz vašega strežnika, da uporabijo HTTP/2 za ciljne strežnike, če je to mogoče.

Ključne točke

• Za uporabo HTTP/2 ni treba posodobiti tako Apache kot cURL. V redu je, če sledite enemu od navodil, saj delujeta ločeno drug od drugega.
• Bilo je nekaj nenavadnih primerov, ko se zdi, da Apache in HTTP/2 delujeta v redu, vendar nalaganje uspe v "naključnih" brskalnikih in spletna mesta postanejo nedosegljiva (časovna omejitev) v drugih. Preprosta vrnitev na prvotno konfiguracijo Apache bo to odpravila, saj Apache ne bo vedel za HTTP/2 in ne bo poskušal posredovati vsebine preko njega.
• Vedno naredite varnostno kopijo ali naredite posnetek vnaprej. Omogočanje HTTP/2 je lahko razmeroma krhek proces, zato je pomembno, da lahko po potrebi razveljavite spremembe.
• Ponovno prevajanje programske opreme lahko vedno povzroči rahel izpad. V nekaterih primerih je to manj kot minuto, vendar ni mogoče natančno povedati. Pripravljeni bi morali biti vsaj na nekaj izpadov.
• Za ta priročnik potrebujete root dostop do strežnika. Če nimate možnosti povišanja ravni dovoljenj na root, se obrnite na skrbnika strežnika, da omogoči HTTP/2 na strežniku.

HTTP/2 in SSL

Čeprav to ni tehnična zahteva samega HTTP/2, boste v večini primerov za uporabo HTTP/2 potrebovali potrdilo SSL. Kot že omenjeno, HTTP/2 tega tehnično ne zahteva, vendar so mnogi brskalniki (Safari, Chrome, Firefox itd.) ustvarili ta standard. Vsebina ne bo prikazana prek HTTP/2, če se stran naloži brez SSL s temi brskalniki. Glede na to, da večina uporabnikov uporablja te brskalnike (in druge), ki prav tako sodelujejo v tem standardu, bi morali uporabiti potrdilo SSL.

Če iščete brezplačen SSL certifikat, si oglejte enega od naših vodnikov Let's Encrypt:

Priporočeno: namestitev Let's Encrypt v DirectAdmin

Alternativne nadzorne plošče:

• Šifrirajmo na Plesku
• Šifrirajmo na cPanelu

Splošna navodila:

• Nastavitev LetsEncrypt v Linuxu
• Namestitev Let's Encrypt With Apache na Ubuntu 14.04
• Namestitev Let's Encrypt With Apache na Ubuntu 16.04

Pogosta vprašanja

Ali ta priročnik dokumentira namestitev Brotlija?

Ne, v tem članku ni opisane metode za namestitev Brotlija poleg HTTP/2.

Prevajanje ne uspe brez razloga in sledil sem natančnim korakom, opisanim v tem članku. Kako naj to rešim?

Čeprav je za to veliko možnih razlogov, ob upoštevanju različnih okolij in podobno, morda vaše nastavitve področne nastavitve niso pravilne. Poskusite postaviti LC_ALL=Cpred svoje ukaze, da bi ukaz za ponovno prevajanje Apache izgledal na primer takole: LC_ALL=C ./build apache Ne pozabite na presledek med LC_ALL=Cin ukazom!

Ali bom izgubil kakšne podatke?

Če trenutno uporabljate nastavitev povratnega proxyja, na primer z Apache in Nginx, ga morate vrniti nazaj na Apache, v tem primeru bi dejansko izgubili svoje konfiguracijske datoteke Nginx. V primeru, da ste naredili konfiguracije VirtualHost po meri (pa naj bo to prek ukazne vrstice ali samega DirectAdmin), jih morate spremeniti za vsako domeno, tako da bodo različice Apache ostale aktivne. Ne boste izgubili nobenih podatkov v zvezi z uporabniškimi podatki, vsebino spletne strani, bazami podatkov itd.

Ali mi te različice po meri preprečijo posodabljanje paketov in programske opreme v prihodnosti?

Na splošno ni treba skrbeti glede tega. Ob upoštevanju modularne namestitve DirectAdmin (in s tem CustomBuild-a) bi morali v prihodnosti brez težav spremeniti ali nadgraditi na druge različice programske opreme. Čeprav bi morali dokumentirati spremembe, če bo v prihodnosti potrebna nadomestna pot nadgradnje, vam ni treba skrbeti zaradi nezdružljivosti različic z novimi izdajami programske opreme.

DirectAdmin ne ponuja HTTP/2 iz škatle; zagotovo to pomeni, da ni združljiv ali pa imajo svoje razloge, da ni. Zakaj je ta rešitev potrebna?

Spodaj opisane metode za namestitev in omogočanje HTTP/2 niso toliko rešitve, temveč zgolj posodobitve paketov in spremembe konfiguracije. Zaradi modularne namestitve DirectAdmin so te spremembe popolnoma v redu in ne bi smele povzročati težav ali drugih težav. Težko je ugotoviti, zakaj DirectAdmin tega ne podpira takoj, saj avtorji za to niso podali pojasnila. Vendar pa je precej trden sklep, da DirectAdmin uporablja pakete različic operacijskega sistema. Ti običajno niso tako posodobljeni kot spodnji paketi. S HTTP/2, samo tehnologijo in njeno združljivostjo ni nič narobe. Tako kot mnoge druge tehnologije lahko traja nekaj časa, da se naravna prilagoditev.

Kakšna so možna tveganja pri aktiviranju HTTP/2 z Apache?

Pri aktivaciji HTTP/2 (sestavljen iz postopka nadgradnje in konfiguracije) je veliko spremenljivk, ki se lahko izkažejo za nestandardne. Največje tveganje pa je v človeški napaki. Vnaprej naredite posnetek, ne pozabite najaviti vzdrževanja svojim uporabnikom (če jih je na strežniku poleg vas) in bodite previdni. Poleg tega ne kopirajte in prilepite ukazov, ne da bi najprej pomislili, kaj naredijo.

Zelo priporočam, da z DirectAdmin začasno obrnete ločen primerek oblaka Vultr in se sprehodite po korakih. Če bi šlo kaj narobe pri "sveži" namestitvi, boste vedeli, kje in kako odpraviti napake, da vam ne bo treba v produkcijskem okolju.

1. del: Apache (spletni strežnik)

Če trenutno uporabljate povratni proxy, se morate vrniti v okolje, ki je samo za Apache. To je zato, ker je HTTP/2 zelo težko odpraviti napake, če gre kaj narobe. Če lahko uporabite integrirano funkcionalnost HTTP/2 Apache, lahko učinkovito odpravite zelo velik del težav.

1. korak: Nadgradnja OpenSSL

V mnogih primerih vaša različica OpenSSL ni združljiva z ALPN, ki je potreben za HTTP/2. Zato omogočimo ALPN s posodobitvijo OpenSSL.

Najprej se prepričajmo, da vaša različica OpenSSL ni združljiva, tako da izvedemo:

openssl version

Če je vaša različica OpenSSL manjša od 1.1.0f, izvedite naslednje kot root. V nasprotnem primeru preskočite na 2. korak.

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

2. korak: Namestitev nghttp2

Da bi HTTP/2 deloval, moramo namestiti nghttp2. Nghttp2 je implementacija HTTP/2 (in HPACK) v C. Nghttp2 je kombinirana različica odjemalca HTTP/2, strežnika in proxyja v C.

Če želite namestiti nghttp2, izvedite naslednje ukaze. Na srečo je nghttp2 mogoče zgraditi neposredno iz CustomBuild.

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

3. korak: Omogočanje HTTP/2 v Apache

V konfiguracijski datoteki Apache moramo spremeniti nekaj vrednosti, da bo lahko uporabljala HTTP/2. Ko spletni strežnik ne prejme navodil za uporabo alternativne različice HTTP, je ne bo uporabil. Zato moramo v konfiguracijsko datoteko dodati HTTP/2.

Da bi te spremembe začele veljati, je potrebna ponovna izdelava Apache prek CustomBuild. Ker so parametri in vrednosti, ki jih uporablja CustomBuild pri gradnji programske opreme, določeni v namenski konfiguracijski datoteki, je najboljša praksa, da te spremembe shranite v namensko konfiguracijsko datoteko po meri.

Opomba: če teh sprememb ne vnesete v datoteko po meri, bodo najverjetneje prepisane in vaša nastavitev se bo zlomila. Sledite spodnjim navodilom.

Izvedite naslednje ukaze, da ustvarite datoteko in jo vnaprej napolnite s privzetimi vrednostmi, da jo lahko pozneje spremenimo:

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

Trenutno imamo datoteko po meri, ki je identična privzeti konfiguracijski datoteki za Apache, ki jo uporablja CustomBuild. /usr/local/directadmin/custombuild/custom/ap2/configure.apacheDatoteko moramo spremeniti tako, da zamenjamo naslednji niz:

"--with-ssl=/usr" \

z:

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

Opomba: Prepričajte se, da za katero koli poševnico nazaj ni belega prostora . Presežek presledka bo povzročil zlom gradnje.

Nato znova zgradite Apache. CustomBuild bo uporabil konfiguracijsko datoteko po meri, ki ste jo pravkar ustvarili:

./build apache

4. korak: Spreminjanje konfiguracije Apache

Apache je bil zdaj obnovljen, vključno s potrebnimi moduli in nastavitvami za HTTP/2. To pomeni, da imamo zdaj na našem strežniku nameščeno različico Apache s podporo za HTTP/2, vendar moramo Apacheu povedati, da jo najprej dejansko uporabi.

Dodajte naslednje vrstice v /etc/httpd/conf/extra/httpd-includes.conf:

ProtocolsHonorOrder On
Protocols h2 h2c http/1.1

Shranite te spremembe in ponovno napišite konfiguracijske datoteke, tako da bodo obstojne med ponovnimi gradnji:

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

HTTP/2 bi moral biti zdaj aktiven na vašem spletnem strežniku (Apache).

5. korak: Znova zaženite strežnik

Znova zaženite strežnik, da se prepričate, da se naše spremembe ohranijo med ponovnimi zagoni. Znova zaženite strežnik prek nadzorne plošče Vultr ali z izvajanjem rebootukaza.

6. korak: preizkusite HTTP/2

Funkcionalnost HTTP/2 je mogoče enostavno preizkusiti z naslednjim orodjem: HTTP/2 Test

Glede na to, da je HTTP/2 specifičen za strežnik in ga ni mogoče omejiti na določen par domen ali spletnih mest, bi moralo delovati vnos katerega koli imena domene, ki kaže na strežnik, ali celo naslova IP strežnika.

Test vam bo povedal, ali lahko doseže spletni strežnik prek HTTP/2. V primeru, da orodje pravi, da je HTTP/2 aktiviran na vašem strežniku, je do spletnih mest DirectAdmin zdaj mogoče dostopati prek HTTP/1.1 ali HTTP/2. V primeru, da podpora HTTP/2 za odjemalca (obiskovalca) ni na voljo, se njegov brskalnik vrne na HTTP/1.1.

Če orodje ne more doseči vašega spletnega strežnika prek HTTP/2, znova sledite zgornjim korakom. Na splošno (ker zgornji koraki ne prepišejo ničesar) to ne bo poškodovalo ali pokvarilo vaše nastavitve.

2. del: cURL

Priporočam, da posodobite cURL, da bo lahko dosegel strežnike s podporo HTTP/2. V primeru, da strežnik ne podpira HTTP/2, se bo vrnil na HTTP/1.1.

1. korak: Dodajanje konfiguracijske datoteke po meri

Tako kot pri Apacheu bomo ustvarili konfiguracijsko datoteko po meri, tako da bo cURL, ki ga je zgradil CustomBuild, uporabljal naše nastavitve po meri.

Ustvarite imenik:

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

Ustvarite datoteko:

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

Kopirajte in prilepite naslednjo vsebino v datoteko:

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

Kot lahko vidite, ta vsebina pove, da se cURL prevede s pomočjo lib_http2knjižnice SSL.

Shranite datoteko in ji dajte ustrezna dovoljenja:

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

2. korak: Izdelava cURL

Nato vse, kar moramo storiti, je zgraditi cURL.

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

cURL je zdaj preveden s podporo za HTTP 2.