Hüperteksti ülekandeprotokoll on alates selle loomisest märkimisväärselt edasi arenenud ja HTTP/2 on üks olulisemaid hüppeid selles, kuidas me andmeid üle maailma veebi edastame. Kui olete viimastel aastatel märganud, et veebilehed laadivad kiiremini, siis on suur tõenäosus, et HTTP/2 töötab kulisside taga.
Selles juhendis kirjeldatakse kõike, mida peate teadma HTTP/2kohta – alatesselle põhilistest mehaanikatest ja jõudluse eelistest kuni praktiliste rakendussammudeni. Olenemata sellest, kas olete arendaja, kes soovib oma veebiserverit optimeerida, või lihtsalt uudishimulik, mis paneb moodsad veebisaidid tiksuma, leiate siit kasulikke teadmisi.
Kiire vastus: Mis on HTTP/2 ja miks see on oluline
HTTP/2 on hüpertekstisiirdeprotokolli versiooni 1.1 oluline muudatus, mille standardiseeris Internet Engineering Task Force RFC 7540 (mai 2015). See keskendub latentsuse vähendamisele, võrguressursside paremale kasutamisele ja veebilehtede oluliselt kiiremale laadimisele, säilitades samal ajal täieliku ühilduvuse olemasoleva HTTP-semantikaga.
Aastal 2026 on HTTP/2 kasutusel peaaegu kõikjal. W3Techi andmetel
Protokolliga võetakse kasutusele mitu peamist funktsiooni, mis käsitlevad HTTP 1.1 jõudluse kitsaskohti:
- Multipleksimine: Mitme andmevoo liikumine ühe TCP-ühenduse kaudu samaaegselt.
- Pealkirjade tihendamine (HPACK): Pealkirjaväljade pakkimise kasutuselevõtt, mis vähendab märkimisväärselt üleliigseid HTTP-pealkirjade metaandmeid.
- Binaarne raamkihi: Täiesti üldine raamkihi, mis asendab tekstipõhised käsud tõhusa binaarsete sõnumite raamimisega.
- Server push: Proaktiivne ressursside tarnimine enne, kui brauser neid selgesõnaliselt taotleb.
- Voogude prioriseerimine: Kliendi vihjed, mis ütlevad serveritele, millised ressursid on kõige olulisemad.
Mida see praktikas tähendab:
- Kiirem lehe laadimine, eriti ressursirikastel saitidel
- Vähem TCP-ühendusi päritolu kohta
- Parem jõudlus suure latentsusega mobiilsidevõrkudes
- Parem võrgu kasutamine kogu ulatuses
Alates HTTP/0.9-st kuni HTTP/2-ni: lühike ajalugu
HTTP-protokoll on teinud pika arengu alates sellest, kui Tim Berners-Lee tutvustas 1991. aastal HTTP/0.9 kui lihtsat mehhanismi HTML-dokumentide kättesaamiseks. HTTP/1.0 järgnes 1996. aastal, lisades päised ja staatuskoodid, ning HTTP/1.1 standardiseeriti RFC 2068 (1997) ja hiljem täiustati RFC 2616 (1999). Peaaegu kaks aastakümmet oli HTTP/1.1 kliendi-serveri suhtluse selgroog kogu veebis.
Kuid veeb muutus kardinaalselt. Kaasaegsed veebilehed muutusid lihtsatest dokumentidest keerukateks rakendusteks, mis laadivad kümneid JavaScript-komplekte, CSS-faile, pilte ja API-kõnesid. Isegi lairibaühenduse ja võimsa riistvara puhul tekitas HTTP/1.1 arhitektuur kitsaskohti:
- Liinide blokeerimine: Iga TCP-ühendus võis korraga käsitleda ainult ühte päringut, mis põhjustas ebavajalikku võrguliiklust, kuna ressursid seisid järjekorras.
- Ühenduse üldkulud: Lauaarvuti- ja mobiiliveebibrauserid avasid tavaliselt 6-8 paralleelset TCP-ühendust päritolu kohta, et seda piirangut vältida.
- Üleliigsed päised: Iga HTTP päring saatis korduvalt samu sõnalisi päiseid (küpsised, kasutaja-agent, aktsepteeri päised).
Google tunnistas neid probleeme ja käivitas 2009. aastal SPDY projekti. Esimest korda rakendati SPDY 2010. aasta paiku Chrome’is ja see tõi kaasa mitmeid uuendusi:
- Binaarne raamimine tekstipõhiste protokollide asemel
- Mitme päringu multipleksimine ühe ühenduse kaudu
- Pealkirjade tihendamine üldkulude vähendamiseks
- Voogude prioriseerimine kriitiliste ressursside jaoks
IETF HTTP töörühm nägi SPDY potentsiaali ja võttis selle 2012. aastal HTTP/2 lähtepunktiks. Pärast ietf http töörühma ulatuslikku tööd avaldati 2015. aasta mais RFC 7540 (HTTP/2) ja RFC 7541 (HPACK) .
Brauserite kasutuselevõtt toimus kiiresti:
- Chrome kaotas alates Chrome 51-st (mai 2016) SPDY kasutamise HTTP/2 kasuks.
- Firefox lisas HTTP/2 toe versioonis 36 (veebruar 2015)
- Safari järgnes versioonis 9 (september 2015)
- Microsoft Edge’ile on algsest versioonist alates lisatud HTTP/2 tugi
- Isegi Internet Explorer 11 sai HTTP/2 toe Windows 8.1 ja hilisemates versioonides.
Disaini eesmärgid ja peamised erinevused HTTP/1.1-st
HTTP/2 säilitab täieliku ühilduvuse HTTP/1.1 semantikaga. Meetodid nagu GET ja POST töötavad identselt. Staatusekoodid jäävad muutumatuks. URId ja HTTP päise väljad järgivad samu reegleid. Muutub see, kuidas need andmed üle juhtme liiguvad – transpordikihi mehaanika, mis määrab tegeliku koormuse kiiruse.
Protokolli koostamise eesmärgid olid selged:
| Eesmärk | Kuidas HTTP/2 seda saavutab |
|---|---|
| Vähendada latentsust | Multipleksimine välistab HTTP-tasandi liinipoolse blokeerimise |
| Parem ühenduse kasutamine | Üks TCP-ühendus tegeleb kõigi päringutega päritoluriigile. |
| Lõigake päise ülevalt alla | HPACKi pakkimine vähendab varem edastatud päise väärtusi |
| Parandada mobiilset jõudlust | Väiksemad ühendused ja väiksemad päised on kasulikud suure latentsusega võrkudele. |
Selle disaini ilu seisneb tagasiulatuvas ühilduvuses rakenduse tasandil. Teie olemasolevat veebirakenduse koodi – marsruute, käitlejaid, vastusloogikat – ei ole vaja muuta. Ainult kliendi ja serveri virn peab toetama HTTP/2, et sellest kasu saada.
See on teravas vastuolus HTTP/1.1 lahendustega, mida arendajad pidid rakendama käsitsi:
- Domeeni jagamine: Varade jagamine mitme domeeni vahel, et avada rohkem ühendusi.
- Varade ühendamine: CSS- ja JavaScript-failide ühendamine päringute vähendamiseks
- Pildispritsid: Mitme pildi ühendamine üheks failiks
- Sisestamine: CSS-i ja JavaScripti sisestamine otse HTML-i
HTTP/2 tuumikmehhanismid, mis asendavad neid häkke:
- Binaarne raamkihi: Kaadriteks jaotatud sõnumid kannavad andmeid tõhusalt binaarsete protokolliühikutena.
- Multipleksitud andmevooge: Mitu samaaegset andmevahetust toimub sama ühenduse kaudu.
- HPACKi päise tihendamine: Dünaamilised tabelid jälgivad pealkirju, kõrvaldades üleliigse töö.
- Server push: Serverid saadavad ennetavalt ressursse, mida klient vajab.
- Voogude prioriseerimine: Kliendid annavad voo sõltuvuse kaalude kaudu märku, millised ressursid on kõige olulisemad.
Binaarne raamimine, voogedastused, sõnumid ja multipleksimine
HTTP/2 keskmes on binaarne raamkihi, mis on põhimõtteline erinevus HTTP/1.1 tekstipõhisest formaadist. Iga HTTP-sõnum jaotatakse binaarseteks raamideks, millel on ühtne raami paigutus: 9baidine raami päis, mis sisaldab pikkuse, tüübi, lipud ja voogude identifikaatorid, millele järgnevad vabatahtlikud kasuliku koormuse andmed.
Hierarhia mõistmine nõuab kolme mõiste mõistmist:
Vood on iseseisvad, kahesuunalised kanalid ühe ühenduse sees. Igal andmevoolul on unikaalne 31-bitine identifikaator. Kliendid algatavad voogusid paaritu numbriga ID-dega (1, 3, 5…), samal ajal kui serverid kasutavad paraja numbriga ID-d (2, 4, 6…) serveri algatatud voogude jaoks, nagu push. Ootamatu voo identifikaator põhjustab vea. Maksimaalse samaaegse voo seadistus kontrollib, kui palju vooge võib olla samaaegselt aktiivne.
Sõnumid kujutavad endast täielikke HTTP-päringuid või -vastuseid. Täielik päiseplokk koosneb ühest või mitmest raamist, ja vastused võivad sisaldada mitu andmeraamistikku. Kui vastuvõtja kohtab päisebloki fragmente, paneb ta need uuesti kokku, et rekonstrueerida täielik sõnum.
Raamid on kõige väiksemad üksused juhtmes. Tavalised kaadri- ja veatüübid on järgmised:
- ANDMETE raamid: Kandvad päringu/vastuse sisu
- HEADERSi raam: Sisaldab HTTP päise väljad, mis võivad olla jaotatud mitmesse raami, mida nimetatakse päisebloki fragmentideks.
- SEADISTUSED: Ühendust kontrollivad sõnumid seadistamiseks
- WINDOW_UPDATE: Voolukontrolli akna kohandamine
- PUSH_PROMISE: Teatab serveri tõukamisest
- RST_STREAM: Lõpetab voo veakoodiga
- KINGITUS: Algatab graatsionaalse ühenduse sulgemise
Maagia toimub läbi multipleksimise. Kuna mitme samaaegselt avatud andmevoo kaadreid saab ühe TCP-ühenduse kaudu vahendada – kusjuures kumbki lõpp-punkt vahendab kaadreid vastavalt vajadusele -, siis ei ole ootamist. Vastuvõtja paneb raamid uuesti kokku voo identifikaatori järgi.
Mõelge tüüpilise veebilehe laadimisele, mis vajab:
- index.html (10 KB)
- styles.css (25 KB)
- app.js (100 KB)
- logo.png (15 KB)
- hero-pilt.jpg (200 KB)
HTTP/1.1 puhul avab teie brauser mitu ühendust, et neid paralleelselt kätte saada, ja see on ikka veel piiratud. HTTP/2 puhul edastavad kõik viis ressurssi üheaegselt ühe ühenduse kaudu mitme andmevooluna. Erinevate andmevoogude andmekaadrid liiguvad üksteise vahele, kusjuures nii klient kui ka server haldavad kogu ühendust tõhusalt.
See kõrvaldab vajaduse mitme TCP-ühenduse järele, vähendades ühenduse voojuhtimisakna koormust ja parandades oluliselt veebi jõudlust.
Pealkirjade tihendamine HPACKiga
HPACK, mis on määratletud RFC 7541-s (avaldatud koos HTTP/2-ga 2015. aasta mais), pakub spetsiaalselt HTTP/2 jaoks loodud päiste pakkimist. See on oluline, sest HTTP/1.1 päised olid laialivalguvad ja täiesti pakkimata, põhjustades iga päringu puhul tarbetut võrguliiklust.
Vaadake tüüpilise HTTP päringu päiseid:
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...Need päised ületavad sageli 700-800 baiti taotluse kohta. Küpsiste puhul võivad need ulatuda mitmete kilobaitideni. Kui korrutate kümneid päringuid lehekülje kohta, siis raiskate märkimisväärset ribalaiust – eriti valusalt mobiilivõrkudes.
HPACK tihendab päiseid kolme mehhanismi abil:
- Staatiline tabel: 61 eelnevalt määratletud ühise päise väli/väärtuse paari (nagu :method: GET või :status: 200), mis ei vaja kunagi edastamist.
- Dünaamiline tabel: Kliendi ja serveri poolt ühiselt koostatav ühendusspetsiifiline tabel, mis salvestab varem edastatud päise väärtused taaskasutamiseks.
- Huffmani kodeerimine: String-väärtused kodeeritakse eelnevalt määratud Huffmani tabeli abil, vähendades tekstiesitusi.
Tulemus on dramaatiline. Pärast seda, kui esimene päring loob dünaamilise tabeli ühised päised, võivad järgmised päringud edastada ainult indeksiviiteid. Pealkirjad, mis algasid kilobaitidena, kahanevad kümneteks baitideks.
HPACK loodi spetsiaalselt selleks, et vältida selliseid turvaauke nagu CRIME ja BREACH, mis mõjutasid varasemaid pakkimisskeeme nagu SPDY DEFLATE. Kasutades staatilisi Huffmani koode ja hoolikat tabelihaldust, takistab HPACK ründajatel kasutada pakkimissuhte analüüsi, et eraldada saladusi ründaja ja ohvri segatud andmetest.
Tasub märkida, et HPACK töötab ainult HTTP-pealkirjadega. Vastuse kehad kasutavad endiselt standardseid sisukodeerimismehhanisme nagu gzip või Brotli HTTP-kihis, mis on täiesti lahus päiste pakkimisest.
Server Push ja voogude prioritiseerimine
HTTP/2 võtab kasutusele kaks optimeerimisfunktsiooni, mis on mõeldud HTTP/1.1 lahenduste asendamiseks: serveri tõukamine ressursside proaktiivseks edastamiseks ja voogude prioritiseerimine ressursside arukaks järjestamiseks.
Server Push
Server push võimaldab veebiserveril saata kliendile ressursse enne nende selgesõnalist taotlemist. Mehhanism töötab PUSH_PROMISE raamide kaudu:
- Kliendi taotlused /index.html
- Server vastab HTML-iga, kuid saadab ka PUSH_PROMISE raamid, mis annavad teada, et ta lükkab /styles.css ja /app.js.
- Server saadab need ressursid uutesse serveri algatatud voogudesse (voogude identifikaatorite puhul kasutatakse paralleelseid numbreid vastavalt madalama väärtusega voogude identifikaatorite määramise reeglitele).
- Brauser saab ressursid enne HTMLi analüüsimist, kui ta avastab, et vajab neid.
See välistab ringreisid. Selle asemel:
- HTML päring → HTML vastuvõtmine
- Parseerib HTML-i, avastab vajaliku CSS-i → taotleb CSS-i
- Parseerib CSS-i, avastab vajalikud kirjatüübid → Taotleb kirjatüüpe
Serveri tõukamine koondab sammud 2-3 sammuks 1.
Serveri tõukamine on aga praktikas osutunud problemaatiliseks:
- Brauserid võivad olla juba ressursse vahemällu salvestanud, mis muudab tõuked raiskavaks
- Valesti konfigureeritud serverid suruvad liiga agressiivselt, raiskades ribalaiust
- Cache digesti mehhanismid ei ole kunagi saavutanud laialdast kasutuselevõttu.
- Paljud CDN-id ja brauserid piiravad või keelavad push’i vaikimisi.
Kliendid saavad push’i täielikult keelata, kui nad seavad oma ühenduse eessõnas SETTINGS_ENABLE_PUSH = 0. Kui kliendi ühenduse eessõna lülitab push’i kohe välja, koosneb serveri ühenduse eessõna kinnitamisest ja vastavusest.
Voolude prioriseerimine
Voogude prioritiseerimine võimaldab klientidel anda märku ressursi olulisusest, aidates serveritel jaotada ribalaiust tõhusalt. Mehhanism kasutab:
- Kaalud: Väärtused vahemikus 1-256, mis näitavad suhtelist tähtsust
- Sõltuvused: Voolud võivad sõltuda teistest voogudest, moodustades sõltuvuspuu voogude sõltuvusdeklaratsioonide kaudu.
Praktiline näide:
- HTML voog (kaal 256, sõltuvus puudub) – kõrgeim prioriteet
- CSS voog (kaal 200, sõltub HTML-ist) – kõrge prioriteediga
- Ülevalpool olevad pildid (kaal 100, sõltub CSS-st)
- Analytics JavaScript (kaal 16, sõltub HTML-ist) – madal prioriteet.
See tagab, et kriitilise tähtsusega renderdamisraja ressursid jõuavad esimesena kohale, mis parandab tajutavat laadimiskiirust, isegi kui kogu ülekande aeg jääb sarnaseks.
Olulised hoiatused:
- Prioriteetide seadmine on nõuandev, mitte kohustuslik
- Serverite rakendused erinevad suuresti selles, kuidas nad prioriteete austavad.
- Vahendajad (proxy’d, CDNid) võivad kaadreid ümber järjestada.
- Tuning nõuab testimist tegeliku liiklusega, mitte oletusi.
Reklaamitud samaaegse voo limiit mõjutab seda, kui paljudel voogudel võivad korraga olla aktiivsed prioriteedid.
Voolukontroll, veakäitlus ja turvakaalutlused
HTTP/2 rakendab omaenda voolukontrolli ja veakäitlust TCP-st kõrgemal, käsitledes stsenaariume, kus rakenduskihi intelligentsus on parem kui transpordikihi vaikimisi.
Voolukontroll
Voolukontroll takistab kiireid saatjaid aeglaste vastuvõtjate ülekoormamist. HTTP/2 kasutab krediidipõhist süsteemi WINDOW_UPDATE raamidega:
- Igal voogul on oma vastuvõtja voolujuhtimisaken
- Ühendusel on ka ühenduse voolujuhtimise aken
- Vaikimisi akna suurus: 65,535 baiti (64 KB)
- Saatjad ei saa edastada DATA kaadreid, mis ületavad vastuvõtja vaba akent.
- Vastuvõtjad saadavad WINDOW_UPDATE raame, et anda rohkem krediiti.
Peamised omadused:
- Voojuhtimine on hüppeliselt (kehtib iga saatja-vastuvõtja paari vahel).
- Seda ei saa keelata
- Ainult DATA kaadrid lähevad aknale arvesse; muud kohustuslikud kaadriandmed ei lähe arvesse.
- Nii voo voolujuhtimine kui ka ühenduse voolujuhtimine toimivad sõltumatult.
See takistab, et üks kiire voog monopoliseeriks ühendusressursse, mis on eriti oluline, kui klientide ja algandmete vahel asuvad proxy’d või CDN’id.
Veakäitlus
HTTP/2 pakub granuleeritud veamärguannet:
- Voolutustasandi vead: RST_STREAM lõpetab kohe ühe voo, ilma et see mõjutaks teisi, kandes selliseid veakoode nagu PROTOCOL_ERROR või FLOW_CONTROL_ERROR.
- Ühenduse tasandi vead: GOAWAY katkestab ühenduse graatsiliselt, võimaldades lennu ajal olevate taotluste lõpuleviimist, kuid takistades uute taotluste esitamist.
Protokollis on määratletud veakoodide register, mis sisaldab järgmist:
- PROTOCOL_ERROR (0x1): Üldine protokolli rikkumine
- FLOW_CONTROL_ERROR (0x3): Voolukontrolli reegleid rikutud
- FRAME_SIZE_ERROR (0x6): Kaadri suurus on ületatud SETTINGS_MAX_FRAME_SIZE
- INADEQUATE_SECURITY (0xc): Transpordikihi turvakonfiguratsioon ebapiisav
Turvalisuse kaalutlused
Kuigi RFC 7540 ei nõua tehniliselt krüpteerimist, nõuavad kõik suuremad veebibrauserid HTTP/2 üle transpordikihi turvalisuse (TLS). See muudab TLS 1.2+ de facto baastasemeks:
- Ühendus algab TLS käepigistusega, mis hõlmab ALPN (Application-Layer Protocol Negotiation).
- ALPN laiendus peab läbirääkimisi HTTP/2 jaoks “h2” identifikaatori üle.
- Serverid peavad vältima spetsifikaadi musta nimekirja kantud nõrku salastussarju.
- RC4 või muid aegunud algoritme kasutavad šifreeringud käivitavad INADEQUATE_SECURITY vead.
Privaatsusega seotud kaalutlused hõlmavad järgmist:
- SETTINGS ja prioriteetsusmustrid võivad klientide sõrmejälgi võtta
- Üks ühendus päritolu kohta korreleerib kogu kasutaja tegevuse selle päritoluga.
- Binaarne protokoll varjab liiklust, kuid ei peida seda võrgu vaatlejate eest.
TCP liinijuhi blokeerimine
HTTP/2 lahendab multipleksimise abil HTTP-tasandi blokeerimise, kuid TCP-tasandi blokeerimine jääb alles. Kui TCP-pakett läheb kaduma, peatuvad kõik selle ühenduse voogud, kuni taasedastus lõpetatakse – isegi need voogud, mille andmed on edukalt kohale jõudnud.
See piirang ajendas HTTP/3, mis töötab QUICi (UDP-põhise) kaudu, et tagada tõeline voogude sõltumatus. Pakettide kaotus, mis mõjutab üht voogu, ei blokeeri teisi vooge.
HTTP/2 kasutuselevõtt ja kasutamine praktikas
Aastal 2026 on HTTP/2 lubamine lihtne. Enamik moodsaid veebiservereid ja CDN-e toetavad seda kohe, peamiselt HTTPS-i kaudu. HTTP-uuendusmehhanism tegeleb läbirääkimistega läbipaistvalt.
Kliendipoolsed nõuded
Kasutajad ei pea midagi erilist tegema:
- Kõik kaasaegsed töölaua veebilehitsejad (Chrome, Firefox, Safari, Edge) toetavad vaikimisi HTTP/2.
- Mobiilsed veebibrauserid (Chrome Androidile, Safari iOSile) sisaldavad täielikku toetust.
- Ühilduvuse tagab brauseri praeguste versioonide kasutamine
- HTTP/2 peab automaatselt läbirääkimisi, kui see on saadaval
Serveri poolne konfiguratsioon
Apache HTTP server (2.4.17+):
- Võta kasutusele mod_http2 moodul (mitte vanem mod_spdy).
- Protokollide h2 http/1.1 lisamine TLS-i virtuaalsetele hostidele
- Veenduge, et OpenSSL-i versioon toetab ALPN-i
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 on HTTPS-i puhul TLS 1.2+ puhul vaikimisi lubatud.
- Täiendavat seadistamist ei ole vaja
CDN pakkujad:
- Cloudflare: HTTP/2 vaikimisi lubatud kõikides plaanides
- AWS CloudFront: Vaikimisi lubatud HTTPS-distributsioonide jaoks.
- Fastly: toetatud ja vaikimisi lubatud
Kontrollimine ja tõrkeotsing
Kinnitage, et HTTP/2 töötab selle kontrollnimekirjaga:
- Brauser DevTools: Avage vahekaart Network, aktiveerige veeru Protocol, otsige “h2”.
- Käsurea: curl –http2 -I https://example.com näitab vastuseks HTTP/2.
- Online-vahendid: HTTP/2 testteenused kontrollivad konfiguratsiooni
- Kontrollige vahendajaid: CDN või pöördproxy peab toetama HTTP/2, mitte ainult päritoluserverit.
Üldised probleemid, mis takistavad HTTP/2 kasutamist:
- OpenSSL versioon liiga vana ALPN-i toe jaoks
- Ainult TLS 1.0/1.1 konfiguratsioon
- Nõrgad salakomplektid, mis vallandavad tagasilöögi
- Vääralt konfigureeritud proxy eemaldas HTTP/2 toe
HTTP/2 ja kaugemale
HTTP/2 on endiselt domineeriv protokoll kaasaegse veebiside jaoks, isegi kui HTTP/3 (RFC 9114, avaldatud 2022) hakkab kasutusele võetama. HTTP/3 tegeleb TCP-peade blokeerimisega, kasutades QUICi, kuid HTTP/2 ühe TCP-ühenduse mudel teenindab jätkuvalt enamikku veebiliiklusest tõhusalt.
Enamiku veebisaitide puhul pakub HTTP/2 märkimisväärset veebi jõudluse paranemist minimaalse konfiguratsioonitööga. Alustage kaadrite vahetamist HTTP/2 kaudu juba täna ja teie kasutajad – nii laua- kui ka mobiiltelefonidel – saavad tunda kiiremat ja tõhusamat lehe laadimist.
Peamised järeldused
- HTTP/2 muudab veebi jõudluse revolutsiooniliseks tänu multipleksimisele, mis võimaldab mitut samaaegset andmevahetust ühe ühenduse kaudu.
- HPACKi päise tihendamine välistab üleliigse päise edastamise, mis on eriti kasulik mobiilikasutajatele.
- Server push ja voogude prioritiseerimine optimeerivad ressursside edastamist, kuigi rakendamine on erinev.
- Voolukontroll takistab ressursside näljutamist mitme voo puhul.
- Kasutuselevõtmine on tänapäevastes serverites lihtne, peamiselt on vaja HTTPS-i konfigureerimist.
- Kõik suuremad brauserid toetavad HTTP/2, mis muudab kasutuselevõtu lõppkasutajate jaoks sujuvaks.
Järgmised sammud
Kui te ei ole oma veebiserveris HTTP/2 kinnitanud, siis on nüüd õige aeg. Avage oma brauseri arendajatööriistad, laadige oma veebileht ja kontrollige veerus Protocol (protokoll). Kui näete “http/1.1” asemel “h2”, vaadake oma serveri konfiguratsioon üle – te jätate märkimisväärse jõudluse kasvu kasutamata.
Need, kes juba kasutavad HTTP/2-d, peaksid kaaluma oma serveri HTTP/2-ühendusmeetriate jälgimist. Mõistmine, kuidas mitu samaaegset voogu käituvad tegeliku liikluse korral, aitab tuvastada optimeerimisvõimalusi enne, kui teie kasutajad märkavad probleeme.