Hiperteksto perdavimo protokolas nuo pat jo sukūrimo labai patobulėjo, o HTTP/2 yra vienas didžiausių šuolių į priekį duomenų perdavimo pasauliniame žiniatinklyje srityje. Jei per pastaruosius kelerius metus pastebėjote, kad tinklalapiai kraunasi greičiau, didelė tikimybė, kad HTTP/2 veikia užkulisiuose.
Šiame vadove pateikiama viskas, ką reikia žinoti apie HTTP/2 – nuo pagrindinės mechanikos ir našumo privalumų iki praktinių diegimo žingsnių. Nesvarbu, ar esate programuotojas, norintis optimizuoti savo žiniatinklio serverį, ar tiesiog domitės, kas lemia šiuolaikinių svetainių veikimą, čia rasite naudingų įžvalgų.
Greitas atsakymas: Kas yra HTTP/2 ir kodėl tai svarbu
HTTP/2 yra esminė hiperteksto perdavimo protokolo 1.1 versijos, kurią interneto inžinerijos darbo grupė standartizavo RFC 7540 (2015 m. gegužė), versija. Joje daugiausia dėmesio skiriama vėlavimo mažinimui, geresniam tinklo išteklių panaudojimui ir žymiai greitesniam tinklalapių įkėlimui – visa taiišlaikant visišką atgalinį suderinamumą su esama HTTP semantika.
2026 m. HTTP/2 naudojimas bus beveik visuotinis. Remiantis „W3Techs” duomenimis, daugiau nei 1/3 populiariausių svetainių aktyviai naudoja HTTP/2, o dauguma pagrindinių CDN („Cloudflare”, „AWS CloudFront”, „Fastly”) pagal numatytuosius nustatymus jį įjungia HTTPS srautui. Jei jūsų svetainė veikia per HTTPS su šiuolaikiniu žiniatinklio serveriu, tikėtina, kad jau naudojatės HTTP/2 be jokios papildomos konfigūracijos.
Protokole įdiegtos kelios pagrindinės funkcijos, kuriomis sprendžiami HTTP 1.1 našumo trūkumai:
- Multipleksavimas: Keli duomenų srautai vienu metu keliauja per vieną TCP ryšį
- antraštės glaudinimas (HPACK): Įdiegtas antraštės laukų suspaudimas, kuris gerokai sumažina nereikalingų HTTP antraštės metaduomenų kiekį.
- Dvejetainis įrėminimo sluoksnis: Visiškai bendras kadrų sluoksnis, kuriame tekstinės komandos pakeičiamos veiksmingais dvejetainiais pranešimais.
- Serverio stūmimas: Aktyvus išteklių pristatymas prieš tai, kai naršyklė jų aiškiai paprašo.
- srauto prioritetų nustatymas: Kliento užuominos, nurodančios serveriams, kurie ištekliai yra svarbiausi
Štai ką tai reiškia praktiškai:
- Greitesnis puslapių įkėlimas, ypač daug išteklių turinčiose svetainėse.
- Vienai kilmei reikia mažiau TCP jungčių
- Geresnis veikimas judriojo ryšio tinkluose su dideliu vėlavimu
- Geresnis tinklo panaudojimas visose srityse
Nuo HTTP/0.9 iki HTTP/2: trumpa istorija
Nuo tada, kai 1991 m. Timas Bernersas-Lee pristatė HTTP/0.9 kaip paprastą HTML dokumentų gavimo mechanizmą, HTTP protokolas nuėjo ilgą kelią. 1996 m. buvo sukurtas HTTP/1.0 protokolas, į kurį įtrauktos antraštės ir būsenos kodai, o HTTP/1.1 protokolas buvo standartizuotas RFC 2068 (1997 m.) ir vėliau patobulintas RFC 2616 (1999 m.). Beveik du dešimtmečius HTTP/1.1 buvo kliento ir serverio bendravimo internete pagrindas.
Tačiau žiniatinklis labai pasikeitė. Šiuolaikiniai tinklalapiai iš paprastų dokumentų virto sudėtingomis programomis, kuriose yra dešimtys „JavaScript” paketų, CSS failų, paveikslėlių ir API skambučių. Net ir naudojant plačiajuostį ryšį ir galingą techninę įrangą, HTTP/1.1 architektūra sudarė kliūčių:
- Linijos galvos blokavimas: Kiekviena TCP jungtis vienu metu galėjo apdoroti tik vieną užklausą, todėl buvo nereikalingas tinklo duomenų srautas, nes ištekliai laukė eilėje.
- Jungties pridėtinės išlaidos: Kad apeitų šį apribojimą, stalinių kompiuterių ir mobiliosios interneto naršyklės paprastai atidaro 6-8 lygiagrečius TCP ryšius vienai kilmei.
- Perteklinės antraštės: Kiekvienoje HTTP užklausoje pakartotinai siunčiamos tos pačios žodinės antraštės (slapukai, vartotojo agentas, „accept” antraštės).
„Google” pripažino šias problemas ir 2009 m. pradėjo SPDY projektą. Pirmą kartą įdiegtas „Chrome” naršyklėje apie 2010 m., SPDY įdiegė keletą naujovių:
- Dvejetainiai rėmai vietoj tekstinių protokolų
- Kelių užklausų multipleksavimas per vieną ryšį
- Antraštės glaudinimas siekiant sumažinti pridėtines išlaidas
- Svarbiausių išteklių srauto prioritetų nustatymas
IETF HTTP darbo grupė įžvelgė SPDY potencialą ir 2012 m. patvirtino jį kaip HTTP/2 pradinį tašką. Po intensyvaus ITTF http darbo grupės darbo 2015 m. gegužės mėn. paskelbti RFC 7540 (HTTP/2) ir RFC 7541 (HPACK).
Naršyklės buvo greitai pritaikytos:
- Nuo „Chrome 51” (2016 m. gegužės mėn.) „Chrome” atsisakė SPDY ir pradėjo naudoti HTTP/2.
- „Firefox” papildė HTTP/2 palaikymą 36 versijoje (2015 m. vasario mėn.)
- „Safari” 9 versijoje (2015 m. rugsėjis)
- „Microsoft Edge” nuo pat pirmosios versijos buvo tiekiamas su HTTP/2 palaikymu
- „Windows 8.1” ir naujesnėse versijose HTTP/2 palaikoma net „Internet Explorer 11
Projektavimo tikslai ir pagrindiniai skirtumai nuo HTTP/1.1
HTTP/2 visiškai atitinka HTTP/1.1 semantiką. Tokie metodai kaip GET ir POST veikia identiškai. Būsenos kodai išlieka nepakitę. URI ir HTTP antraštės laukai atitinka tas pačias taisykles. Keičiasi tik tai, kaip šie duomenys juda laidais – transporto sluoksnio mechanikos, lemiančios faktinį apkrovos greitį.
Protokolo projektavimo tikslai buvo aiškūs:
| Tikslas | Kaip tai pasiekiama HTTP/2 |
|---|---|
| Sumažinti vėlavimą | Multipleksavimas pašalina HTTP lygmens linijos blokavimą |
| Geresnis ryšio naudojimas | Visos užklausos į kilmės šalį pateikiamos per vieną TCP ryšį. |
| Iškirpti antraštę virš galvos | HPACK suspaudimas sumažina anksčiau perduotas antraštės vertes |
| Mobiliojo ryšio našumo gerinimas | Mažiau jungčių ir mažesnės antraštės naudingos didelio vėlavimo tinklams |
Šios konstrukcijos grožis – atgalinis suderinamumas taikomosios programos lygmeniu. Jūsų esamo žiniatinklio programos kodo – maršrutų, tvarkyklių, atsakymo logikos – keisti nereikia. Tik kliento ir serverio stekas turi palaikyti HTTP/2, kad pajustumėte naudą.
Tai labai skiriasi nuo HTTP/1.1 apėjimo būdų, kuriuos kūrėjai turėjo įdiegti rankiniu būdu:
- Domeno dalijimas: Turto paskirstymas keliuose domenuose, kad būtų atidaryta daugiau jungčių
- Turto sujungimas: CSS ir „JavaScript” failų sujungimas siekiant sumažinti užklausų skaičių
- Paveikslėlių spritai: Kelių vaizdų sujungimas į vieną failą
- Įdėklai: CSS ir „JavaScript” įterpimas tiesiai į HTML
Pagrindinės HTTP/2 mechanikos, kurios pakeičia šiuos įsilaužimus:
- Dvejetainis įrėminimo sluoksnis: Pranešimai, suskirstyti į rėmelius, efektyviai perduoda duomenis kaip dvejetainiai protokolo vienetai
- Daugialypiai srautai: Keli vienu metu vykstantys mainai per tą patį ryšį
- HPACK antraštės suspaudimas: Dinaminės lentelės seka antraštes, todėl nebelieka perteklinių duomenų.
- Serverio stūmimas: Serveriai aktyviai siunčia išteklius, kurių reikės klientui.
- srauto prioritetų nustatymas: Klientai praneša, kurie ištekliai yra svarbiausi, naudodami srauto priklausomybės svorius.
Dvejetainis įrėminimas, srautai, pranešimai ir multipleksavimas
HTTP/2 esmė – dvejetainis įrėminimo sluoksnis, kuris iš esmės skiriasi nuo HTTP/1.1 tekstinio formato. Kiekvienas HTTP pranešimas suskirstomas į dvejetainius rėmus, kurių išdėstymas yra nuoseklus: 9 baitų rėmo antraštė, kurioje yra ilgio, tipo, vėliavų ir srauto identifikatoriai, o po jų – neprivalomi naudingosios apkrovos duomenys.
Norint suprasti hierarchiją, reikia suvokti tris sąvokas:
Srautai yra nepriklausomi dvikrypčiai kanalai viename ryšyje. Kiekvienas srautas turi unikalų 31 bito identifikatorių. Klientai inicijuoja srautus su nelyginio numerio identifikatoriais (1, 3, 5…), o serverio inicijuotiems srautams, pavyzdžiui, „push”, serveriai naudoja lyginio numerio identifikatorius (2, 4, 6…). Netikėtas srauto identifikatorius sukelia klaidą. Didžiausio vienu metu veikiančio srauto nustatymas kontroliuoja, kiek srautų gali būti aktyvūs vienu metu.
Žinutėse pateikiamos visos HTTP užklausos arba atsakymai. Visą antraštės bloką sudaro vienas ar daugiau rėmelių, o atsakymo turinį gali sudaryti keli duomenų rėmai. Kai imtuvas susiduria su antraštės bloko fragmentais, jis juos vėl surenka, kad atkurtų visą pranešimą.
Rėmeliai yra mažiausi laidų vienetai. Dažniausiai pasitaikantys rėmelių ir klaidų tipai:
- DUOMENŲ rėmai: Perduodamas užklausos/atsakymo turinys
- Rėmelis su antraštėmis: Sudėtyje yra HTTP antraštės laukai, kurie gali būti padalyti į kelis rėmus, vadinamus antraštės bloko fragmentais.
- NUSTATYMAI: Ryšio valdymo pranešimai, skirti konfigūravimui
- WINDOW_UPDATE: srauto valdymo lango koregavimas
- PUSH_PROMISE: Skelbia serverio stūmimą
- RST_STREAM: Nutraukia srautą su klaidos kodu
- GOAWAY: Inicijuoja laipsnišką ryšio išjungimą
Stebuklingas dalykas įvyksta dėl daugkartinio sujungimo. Kadangi kelių vienu metu atidarytų srautų kadrai gali būti perskirstomi per vieną TCP ryšį, o bet kuris galinis taškas perskirsto kadrus pagal poreikį, nereikia laukti. Imtuvas perskirsto kadrus pagal srauto identifikatorių.
Apsvarstykite tipinio tinklalapio, kuriam reikia:
- index.html (10 KB)
- styles.css (25 KB)
- app.js (100 KB)
- logo.png (15 KB)
- hero-image.jpg (200 KB)
Naudojant HTTP/1.1, naršyklė lygiagrečiai atidaro kelis ryšius, kad gautų šiuos duomenis, ir taip vis dar pažeidžiami apribojimai. Naudojant HTTP/2, visi penki ištekliai vienu metu perduodami vienu ryšiu kaip keli duomenų srautai. Skirtingų srautų duomenų kadrai persipina, o klientas ir serveris efektyviai valdo visą ryšį.
Dėl to nereikia kelių TCP jungčių, sumažėja ryšio srauto valdymo lango apkrova ir labai pagerėja žiniatinklio našumas.
Antraštės glaudinimas naudojant HPACK
HPACK, apibrėžtas RFC 7541 (paskelbtas kartu su HTTP/2 2015 m. gegužės mėn.), užtikrina antraštės suspaudimą, specialiai pritaikytą HTTP/2. Tai svarbu, nes HTTP/1.1 antraštės buvo žodingos ir visiškai nesuspaustos, todėl kiekviena užklausa sukeldavo nereikalingą tinklo duomenų srautą.
Panagrinėkite tipinės HTTP užklausos antraštes:
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)...
Accept: text/html,application/xhtml+xml,application/xml;q=0.9...
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Cookie: session=abc123def456; tracking=xyz789...Šios antraštės dažnai viršija 700-800 baitų vienai užklausai. Su slapukais jos gali išaugti iki kelių kilobaitų. Padauginus iš dešimčių užklausų vienam puslapiui, eikvojamas didelis duomenų srauto pralaidumas – ypač skaudus mobiliuosiuose tinkluose.
HPACK suspaudžia antraštes naudodamas tris mechanizmus:
- Statinė lentelė: 61 iš anksto apibrėžtų bendrų antraštės laukų ir verčių porų (pvz., :method: GET arba :status: 200), kurių niekada nereikia perduoti
- Dinaminė lentelė: Lentelė, skirta konkrečiam ryšiui, kurią klientas ir serveris sukuria kartu ir kurioje saugomos anksčiau perduotos antraščių vertės, kad jas būtų galima naudoti pakartotinai.
- Huffmano kodavimas: Teksto reikšmės koduojamos naudojant iš anksto nustatytą Huffmano lentelę, todėl teksto atvaizdai mažinami.
Rezultatas dramatiškas. Po pirmosios užklausos, kai dinaminėje lentelėje nustatomos bendros antraštės, vėlesnėmis užklausomis gali būti perduodamos tik indeksų nuorodos. Pradžioje buvusios kilobaitų dydžio antraštės sumažėja iki dešimčių baitų.
HPACK buvo specialiai sukurta siekiant išvengti tokių saugumo spragų kaip CRIME ir BREACH, kurios turėjo įtakos ankstesnėms glaudinimo schemoms, pavyzdžiui, SPDY DEFLATE. Naudojant statinius Huffmano kodus ir kruopščiai tvarkant lenteles, HPACK neleidžia įsilaužėliams naudoti suspaudimo santykio analizės, kad išgautų paslaptis iš mišrių įsilaužėlio ir aukos duomenų.
Verta paminėti, kad HPACK veikia tik su HTTP antraštėmis. Atsakymų korpusai vis dar naudoja standartinius turinio kodavimo mechanizmus, tokius kaip gzip ar Brotli, HTTP lygmenyje, visiškai atskirai nuo antraštės suspaudimo.
Serverio „Push” ir srauto prioritetų nustatymas
HTTP/2 įdiegtos dvi optimizavimo funkcijos, kuriomis siekiama pakeisti HTTP/1.1 apėjimo būdus: serverio stūmimo funkcija, skirta aktyviam išteklių pristatymui, ir srauto prioritetų nustatymas, skirtas pažangiam išteklių užsakymui.
Serverio stūmimas
Serverio stūmimas leidžia žiniatinklio serveriui siųsti išteklius klientui prieš tai, kai jų aiškiai paprašoma. Šis mechanizmas veikia per PUSH_PROMISE rėmelius:
- Kliento užklausos /index.html
- Serveris atsako HTML, bet taip pat siunčia PUSH_PROMISE rėmelius, kuriuose skelbiama, kad bus siunčiami /styles.css ir /app.js
- Serveris siunčia šiuos išteklius naujais serverio inicijuotais srautais (srauto identifikatoriams naudojami lyginiai skaičiai pagal mažesnės vertės srauto identifikatoriaus priskyrimo taisykles).
- Naršyklė gauna išteklius prieš analizuodama HTML, kai nustato, kad jų reikia.
Taip išvengsite kelionių į abi puses. Vietoj:
- Užklausa HTML → Gauti HTML
- Išnagrinėkite HTML, atraskite reikalingus CSS → Užklausa CSS
- CSS analizė, reikalingų šriftų paieška → Prašyti šriftų
Serverio stūmimo metu 2-3 žingsniai susilieja į 1 žingsnį.
Tačiau praktikoje paaiškėjo, kad serverio stūmimas yra problemiškas:
- Naršyklėse jau gali būti įrašyti ištekliai į talpyklą, todėl stūmimai yra nenaudingi.
- Netinkamai sukonfigūruoti serveriai per daug agresyviai stumia duomenis, todėl eikvojamas dažnių juostos plotis
- Spartinančiosios talpyklos kodavimo mechanizmai niekada nebuvo plačiai naudojami
- Daugelis CDN ir naršyklių dabar pagal nutylėjimą riboja arba išjungia stūmimą
Klientai gali visiškai išjungti „push” funkciją, nustatydami SETTINGS_ENABLE_PUSH = 0 savo ryšio įžangoje. Kai kliento sujungimo priešistorė iš karto išjungia „push”, serverio sujungimo priešistorę sudaro patvirtinimas ir atitikimas.
Srauto prioritetų nustatymas
Nustatydami srauto prioritetus klientai gali pranešti apie išteklių svarbą ir padėti serveriams efektyviai paskirstyti pralaidumą. Mechanizmas naudoja:
- Svoris: 1-256 reikšmės, rodančios santykinę svarbą
- Priklausomybės: Srautai gali priklausyti nuo kitų srautų, sudarant priklausomybių medį per srauto priklausomybės deklaracijas.
Praktinis pavyzdys:
- HTML srautas (svoris 256, nėra priklausomybės) – didžiausias prioritetas
- CSS srautas (svoris 200, priklauso nuo HTML) – didelis prioritetas
- Virš puslapio esantys paveikslėliai (svoris 100, priklauso nuo CSS)
- „Analytics JavaScript” (svoris 16, priklauso nuo HTML) – mažas prioritetas
Taip užtikrinama, kad svarbiausi atvaizdavimo kelio ištekliai būtų pasiekiami pirmieji, todėl padidėja suvokiama įkėlimo sparta, net jei bendras perdavimo laikas išlieka panašus.
Svarbūs įspėjimai:
- Prioritetų nustatymas yra patariamasis, o ne privalomas.
- Serverių įgyvendinimo būdai labai skiriasi pagal tai, kaip jie atsižvelgia į prioritetus
- Tarpininkai (tarpininkai, CDN) gali keisti kadrų eiliškumą
- Derinant reikia atlikti bandymus su realiu srautu, o ne daryti prielaidas.
Skelbiama vienu metu veikiančio srauto riba lemia, kiek srautų vienu metu gali turėti aktyvius prioritetus.
Srauto valdymas, klaidų tvarkymas ir saugumo aspektai
„HTTP/2” įgyvendina savo srauto valdymą ir klaidų tvarkymą virš TCP, todėl sprendžiami scenarijai, kai taikomojo lygmens intelektas pranoksta transporto lygmens numatytąsias nuostatas.
Srauto valdymas
Srauto kontrolė neleidžia greitiems siuntėjams užgožti lėtų imtuvų. HTTP/2 naudoja kreditais pagrįstą sistemą su WINDOW_UPDATE rėmeliais:
- Kiekvienas srautas turi savo imtuvo srauto valdymo langą
- Ryšys taip pat turi ryšio srauto valdymo langą
- Numatytasis lango dydis: 65 535 baitų (64 KB)
- Siųstuvai negali perduoti DATA kadrų, viršijančių imtuvo turimą langą
- Gavėjai siunčia WINDOW_UPDATE rėmelius, kad suteiktų daugiau kredito
Pagrindinės savybės:
- Srauto kontrolė yra „hop-by-hop” (taikoma kiekvienai siuntėjo ir gavėjo porai)
- Jos negalima išjungti
- Į langą įskaičiuojami tik DATA kadrai; kiti privalomi kadro duomenys neįskaičiuojami.
- Tiek srauto srauto valdymas, tiek ryšio srauto valdymas veikia nepriklausomai.
Tai neleidžia vienam greitam srautui monopolizuoti ryšio išteklių, o tai ypač svarbu, kai tarp klientų ir pradinių serverių yra tarpiniai serveriai arba CDN.
Klaidų tvarkymas
„HTTP/2” teikia išsamius klaidų signalus:
- srauto lygmens klaidos: RST_STREAM iš karto nutraukia vieną srautą, nedarydamas poveikio kitiems, ir pateikia tokius klaidų kodus kaip PROTOCOL_ERROR arba FLOW_CONTROL_ERROR.
- Ryšio lygio klaidos: GOAWAY grakščiai išjungia ryšį, kad būtų galima užbaigti skrydžio užklausas, bet neleidžiama pateikti naujų užklausų.
Protokole apibrėžiamas klaidų kodų registras, įskaitant:
- PROTOCOL_ERROR (0x1): Bendras protokolo pažeidimas
- FLOW_CONTROL_ERROR (0x3): Pažeistos srauto valdymo taisyklės
- FRAME_SIZE_ERROR (0x6): Rėmelis viršijo SETTINGS_MAX_FRAME_SIZE
- INADEQUATE_SECURITY (0xc): Nepakankama transporto lygmens saugumo konfigūracija
Saugumo aspektai
Nors RFC 7540 techniškai nereikalauja šifravimo, visose pagrindinėse žiniatinklio naršyklėse reikalaujama, kad HTTP/2 būtų saugomas naudojant transporto sluoksnio saugumą (TLS). Dėl to TLS 1.2+ yra faktinis bazinis standartas:
- Ryšys pradedamas TLS rankiniu suvedimu, įskaitant ALPN (Application-Layer Protocol Negotiation).
- ALPN plėtinys derasi dėl „h2” identifikatoriaus, skirto HTTP/2
- Serveriai turi vengti silpnų šifrų rinkinių, įtrauktų į juodąjį sąrašą pagal specifikaciją
- Šifrų rinkiniai, kuriuose naudojami RC4 arba kiti nebenaudojami algoritmai, sukelia INADEQUATE_SECURITY klaidas
Privatumo aspektai:
- Nustatymai ir prioritetų modeliai gali imti klientų pirštų atspaudus
- Vienas ryšys kiekvienai kilmės šaliai susieja visą naudotojo veiklą su ta kilmės šalimi.
- Dvejetainis protokolas užgožia srautą, bet neslepia jo nuo tinklo stebėtojų
„TCP Head-of-Line” blokavimas
HTTP/2 išsprendžia HTTP lygmens „head of line” blokavimo problemą dėl multipleksavimo, tačiau TCP lygmens blokavimas išlieka. Praradus TCP paketą, visi to ryšio srautai stabdomi, kol bus baigtas pakartotinis perdavimas, net ir tie, kurių duomenys buvo sėkmingai gauti.
Šis apribojimas paskatino HTTP/3, kuris veikia per QUIC (UDP pagrindu), kad būtų užtikrintas tikras nepriklausomumas nuo srauto. Paketo praradimas, paveikęs vieną srautą, neblokuoja kitų.
HTTP/2 diegimas ir naudojimas praktikoje
2026 m. įjungti HTTP/2 nesudėtinga. Dauguma šiuolaikinių žiniatinklio serverių ir CDN palaiko ją iškart, pirmiausia per HTTPS. HTTP atnaujinimo mechanizmas derybas tvarko skaidriai.
Kliento pusės reikalavimai
Naudotojams nereikia atlikti jokių specialių veiksmų:
- Visos šiuolaikinės darbalaukio naršyklės („Chrome”, „Firefox”, „Safari”, „Edge”) pagal nutylėjimą palaiko HTTP/2.
- Mobiliosios žiniatinklio naršyklės („Chrome” „Android”, „Safari” „iOS”) visiškai palaiko
- Suderinamumas užtikrinamas naudojant dabartines naršyklės versijas
- HTTP/2 derybos vyksta automatiškai, kai yra galimybė
Serverio pusės konfigūracija
„Apache” HTTP serveris (2.4.17+):
- Įjunkite mod_http2 modulį (ne senesnį mod_spdy)
- Protokolų h2 http/1.1 įtraukimas į TLS virtualius prievadus
- Įsitikinkite, kad „OpenSSL” versija palaiko ALPN
„Nginx” (1.9.5+):
server {
listen 443 ssl http2;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
# ... rest of configuration
}IIS (Windows Server 2016+):
- HTTP/2 pagal numatytuosius nustatymus įjungtas HTTPS su TLS 1.2+
- Nereikia jokios papildomos konfigūracijos
CDN teikėjai:
- „Cloudflare”: HTTP/2 įjungtas pagal numatytuosius nustatymus visuose planuose
- „AWS CloudFront”: Pagal numatytuosius nustatymus įjungtas HTTPS platinimams
- Fastly: palaikoma ir įjungta pagal numatytuosius nustatymus
Patikrinimas ir trikčių šalinimas
Šiuo kontroliniu sąrašu patvirtinkite, kad HTTP/2 veikia:
- Naršyklės „DevTools”: Atverkite skirtuką „Tinklas”, įjunkite stulpelį „Protokolas”, ieškokite „h2”.
- Komandinė eilutė: curl –http2 -I https://example.com rodo HTTP/2 atsakymą
- Internetiniai įrankiai: HTTP/2 bandomosios paslaugos patikrinti konfigūraciją
- Patikrinkite tarpininkus: CDN arba atvirkštinis tarpinis serveris turi palaikyti HTTP/2, ne tik kilmės serveris
Dažniausiai pasitaikančios problemos, trukdančios HTTP/2:
- Per sena „OpenSSL” versija ALPN palaikymui
- Tik TLS 1.0/1.1 konfigūracija
- Silpni šifrų rinkiniai, sukeliantys grįžtamąjį ryšį
- Netinkamai sukonfigūruotas tarpinis serveris atima HTTP/2 palaikymą
„HTTP/2” ir ne tik
HTTP/2 išlieka dominuojančiu šiuolaikinio žiniatinklio ryšio protokolu, net ir pradėjus diegti HTTP/3 (RFC 9114, paskelbtas 2022 m.). HTTP/3 sprendžia TCP „head-of-line” blokavimo problemą, nes veikia per QUIC, tačiau HTTP/2 vieno TCP ryšio modelis ir toliau veiksmingai aptarnauja didžiąją dalį žiniatinklio srauto.
Daugumoje svetainių HTTP/2 gerokai pagerina žiniatinklio našumą, o konfigūravimo pastangos minimalios. Pradėkite keistis rėmeliais per HTTP/2 jau šiandien, ir jūsų naudotojai – tiek kompiuterio, tiek mobiliųjų įrenginių naudotojai – galės greičiau ir efektyviau įkelti puslapius.
Pagrindinės išvados
- „HTTP/2” keičia žiniatinklio našumą dėl multipleksavimo, leidžiančio vienu metu vykdyti kelis mainus per vieną ryšį.
- HPACK antraštės suspaudimas pašalina nereikalingą antraštės perdavimą, o tai ypač naudinga mobiliesiems naudotojams.
- Serverio stūmimas ir srauto prioritetų nustatymas optimizuoja išteklių pristatymą, nors įgyvendinimas skiriasi
- Srauto valdymas apsaugo nuo išteklių stygiaus keliuose srautuose
- Šiuolaikiniuose serveriuose diegimas nesudėtingas, visų pirma reikia HTTPS konfigūracijos.
- Visos pagrindinės naršyklės palaiko HTTP/2, todėl galutiniai naudotojai gali be vargo priimti šį protokolą.
Tolesni žingsniai
Jei savo žiniatinklio serveryje dar nepatikrinote HTTP/2, dabar pats laikas. Atidarykite naršyklės kūrėjų įrankius, įkelkite svetainę ir patikrinkite stulpelį Protokolas. Jei vietoj „h2” matote „http/1.1”, peržiūrėkite savo serverio konfigūraciją – taip galite gerokai padidinti našumą.
Tiems, kurie jau naudoja HTTP/2, apsvarstykite galimybę stebėti savo serverio HTTP/2 ryšio rodiklius. Supratimas, kaip keli vienu metu veikiantys srautai elgiasi esant realiam duomenų srautui, padeda nustatyti optimizavimo galimybes, kol vartotojai nepastebėjo problemų.