Protokol za prenos hiperteksta se je od svojega nastanka močno razvil, HTTP/2 pa predstavlja enega najpomembnejših preskokov v načinu prenosa podatkov po svetovnem spletu. Če ste v zadnjih nekaj letih opazili, da se spletne strani nalagajo hitreje, obstaja velika verjetnost, da HTTP/2 deluje v ozadju.
V tem vodniku je opisano vse, kar morate vedeti o protokolu HTTP/2 – odnjegove osnovne mehanike in prednosti za zmogljivost do praktičnih korakov uvajanja. Ne glede na to, ali ste razvijalec, ki želi optimizirati svoj spletni strežnik, ali pa vas preprosto zanima, kaj omogoča sodobna spletna mesta, boste v tem priročniku našli uporabna spoznanja.
Hitri odgovor: V tem primeru je treba uporabiti hiter odgovor: Kaj je HTTP/2 in zakaj je pomemben
HTTP/2 je večja revizija protokola za prenos hiperteksta različice 1.1, ki jo je projektna skupina za internetno inženirstvo standardizirala v dokumentu RFC 7540 (maj 2015). Osredotoča se na zmanjšanje zakasnitev, izboljšanje izkoriščenosti omrežnih virov in bistveno hitrejše nalaganje spletnih strani – vse toob ohranjanju popolne povratne združljivosti z obstoječo semantiko HTTP.
Leta 2026 bo protokol HTTP/2 skoraj povsod sprejet. Po podatkih W3Techs več kot tretjina najboljših spletnih mest aktivno uporablja HTTP/2, večina večjih CDN (Cloudflare, AWS CloudFront, Fastly) pa ga privzeto omogoča za promet HTTPS. Če vaše spletno mesto deluje v protokolu HTTPS s sodobnim spletnim strežnikom, vam HTTP/2 verjetno že koristi brez dodatne konfiguracije.
Protokol uvaja več glavnih funkcij, ki odpravljajo ozka grla zmogljivosti protokola HTTP 1.1:
- Multipleksiranje: Več podatkovnih tokov hkrati potuje prek ene same povezave TCP
- Stiskanje glave (HPACK): Uvedba stiskanja polj glave, ki bistveno zmanjša odvečne metapodatke v glavi HTTP.
- Binarni okvirni sloj: Popolnoma splošna plast okvirja, ki besedilne ukaze nadomešča z učinkovitim uokvirjanjem binarnih sporočil.
- Potiskanje strežnika: Proaktivno dostavljanje virov, preden jih brskalnik izrecno zahteva.
- Prednostno razvrščanje tokov: Odjemalčevi namigi, ki strežnikom sporočajo, kateri viri so najpomembnejši.
To v praksi pomeni naslednje:
- Hitrejše nalaganje strani, zlasti na spletnih mestih z veliko viri.
- Manj potrebnih povezav TCP na izvor
- Boljša zmogljivost v mobilnih omrežjih z visoko latenco
- Izboljšana vsesplošna izkoriščenost omrežja
Od HTTP/0.9 do HTTP/2: kratka zgodovina
Protokol HTTP je od leta 1991, ko je Tim Berners-Lee predstavil HTTP/0.9 kot preprost mehanizem za pridobivanje dokumentov HTML, prehodil dolgo pot. Leta 1996 je sledil HTTP/1.0, ki je dodal glave in kode stanja, HTTP/1. 1 pa je bil standardiziran v RFC 2068 (1997) in kasneje izboljšan v RFC 2616 (1999). Skoraj dve desetletji je HTTP/1.1 služil kot hrbtenica komunikacije med odjemalcem in strežnikom v spletu.
Toda splet se je močno spremenil. Sodobne spletne strani so iz preprostih dokumentov postale zapletene aplikacije z več deset paketi JavaScript, datotekami CSS, slikami in klici API. Arhitektura protokola HTTP/1.1 je tudi pri širokopasovnih povezavah in zmogljivi strojni opremi povzročala ozka grla:
- Blokiranje na čelu linije: Vsaka povezava TCP je lahko hkrati obdelala le eno zahtevo, kar je povzročilo nepotreben omrežni promet, saj so se viri čakali v vrsti.
- Režijski stroški povezave: Spletni brskalniki za namizne računalnike in mobilne naprave običajno odprejo 6-8 vzporednih povezav TCP na izvor, da zaobidejo to omejitev.
- Odvečni naslovi: Vsak zahtevek HTTP je večkrat poslal enake glave (piškotki, uporabniški agent, glave accept).
Google je prepoznal te težave in leta 2009 začel izvajati projekt SPDY. Projekt SPDY, ki je bil prvič uporabljen v brskalniku Chrome okoli leta 2010, je uvedel več novosti:
- Binarno uokvirjanje namesto besedilnih protokolov
- Multipleksiranje več zahtevkov prek ene povezave
- Stiskanje glave za zmanjšanje režijskih stroškov
- Prednostno razvrščanje tokov za kritične vire
Delovna skupina IETF za HTTP je videla potencial protokola SPDY in ga leta 2012 sprejela kot izhodišče za HTTP/2. Po obsežnem delu delovne skupine ITTF http sta bila maja 2015 objavljena protokola RFC 7540 (HTTP/2) in RFC 7541 (HPACK).
Sprejetje brskalnikov je bilo hitro:
- Chrome je s Chromom 51 (maj 2016) ukinil SPDY v korist HTTP/2.
- Firefox je v različici 36 (februar 2015) dodal podporo za HTTP/2.
- Safari sledi v različici 9 (september 2015)
- Microsoft Edge ima podporo za HTTP/2 že od prve izdaje
- Tudi Internet Explorer 11 je dobil podporo za HTTP/2 v operacijskem sistemu Windows 8.1 in novejšem
Cilji zasnove in ključne razlike glede na HTTP/1.1
HTTP/2 ohranja popolno združljivost s semantiko HTTP/1.1. Metodi, kot sta GET in POST, delujeta enako. Kode stanja ostajajo nespremenjene. URI in polja glave HTTP upoštevajo ista pravila. Spremeni se le način, kako se ti podatki prenašajo po žici – mehanika transportne plasti, ki določa dejansko hitrost nalaganja.
Cilji oblikovanja protokola so bili jasni:
| Cilj | Kako to doseže HTTP/2 |
|---|---|
| Zmanjšanje zakasnitve | Multipleksiranje odpravlja blokiranje na ravni HTTP v glavi linije |
| Boljša uporaba povezave | Ena sama povezava TCP obdeluje vse zahteve do izvora. |
| Rezanje glave nad glavo | Stiskanje HPACK skrči predhodno prenesene vrednosti glave. |
| Izboljšanje učinkovitosti mobilnih naprav | Manjše število povezav in manjši naslovniki koristijo omrežjem z visoko zakasnitvijo |
Lepota te zasnove je v povratni združljivosti na ravni aplikacije. Vaše obstoječe kode spletne aplikacije – poti, obdelave, logike odziva – ni treba spreminjati. Da bi bile koristi vidne, morata HTTP/2 podpirati le odjemalec in strežnik.
To je v velikem nasprotju z obvozi HTTP/1.1, ki so jih morali razvijalci izvajati ročno:
- Razdelitev domen: Razpršitev sredstev na več domen za odprtje več povezav
- Povezovanje sredstev: Združevanje datotek CSS in JavaScript za zmanjšanje števila zahtevkov
- Slikovni spriti: Združevanje več slik v eno samo datoteko
- Vložki: Vstavljanje CSS in JavaScript neposredno v HTML
Osnovna mehanika protokola HTTP/2, ki nadomešča te okvare:
- Binarni okvirni sloj: Sporočila, razdeljena v okvirje, učinkovito prenašajo podatke kot enote binarnega protokola
- Multipleksirani tokovi: Več hkratnih izmenjav poteka prek iste povezave
- Stiskanje glave HPACK: Dinamične tabele sledijo glavi in odpravljajo odvečne podatke.
- Potiskanje strežnika: Strežniki proaktivno pošiljajo vire, ki jih bo odjemalec potreboval.
- Prednostno razvrščanje tokov: Odjemalci sporočajo, kateri viri so najpomembnejši, z utežmi odvisnosti od toka.
Binarno uokvirjanje, tokovi, sporočila in multipleksiranje
Bistvo protokola HTTP/2 je binarni okvirni sloj, ki je bistven odmik od besedilne oblike protokola HTTP/1.1. Vsako sporočilo HTTP je razdeljeno na binarne okvirje z dosledno razporeditvijo okvirja: 9-bajtni glavi okvirja, ki vsebuje dolžino, vrsto, oznake in identifikatorje toka, sledijo pa mu neobvezni podatki o koristnem tovoru.
Za razumevanje hierarhije je treba razumeti tri koncepte:
Tokovi so neodvisni dvosmerni kanali v eni sami povezavi. Vsak tok ima edinstven 31-bitni identifikator. Odjemalci sprožijo tokove z neparnimi identifikatorji (1, 3, 5 …), medtem ko strežniki uporabljajo parne identifikatorje (2, 4, 6 …) za tokove, ki jih sproži strežnik, kot je push. Nepričakovan identifikator toka povzroči napako. Nastavitev največjega števila sočasnih tokov določa, koliko tokov je lahko aktivnih hkrati.
Sporočila predstavljajo popolne zahteve ali odzive HTTP. Celoten blok glave je sestavljen iz enega ali več okvirjev, odgovori pa lahko vključujejo več podatkovnih okvirjev za telo. Ko sprejemnik naleti na fragmente bloka glave, jih ponovno sestavi in tako rekonstruira celotno sporočilo.
Okvirji so najmanjše enote na žici. Običajne vrste okvirjev in napak vključujejo:
- Podatkovni okvirji: Prenašajo vsebino zahtevka/odgovora
- OKVIRI ZA NASLOVICE: Vsebuje polja glave HTTP, po možnosti razdeljena na več okvirjev, imenovanih fragmenti bloka glave.
- NASTAVITVE: Sporočila za nadzor povezave za konfiguracijo
- WINDOW_UPDATE: Prilagoditve okna za nadzor pretoka
- PUSH_PROMISE: Napoveduje potiskanje strežnika
- RST_STREAM: Prekinitev toka s kodo napake
- DOBRODELNA NAGRADA: sproži gracilno zaustavitev povezave
Čarovnija se zgodi z multipleksiranjem. Ker se lahko okvirji iz več sočasno odprtih tokov prepletajo prek ene same povezave TCP – pri čemer vsaka od končnih točk prepleta okvirje po potrebi -, ni čakanja. Sprejemnik ponovno sestavi okvirje po identifikatorju toka.
Razmislite o nalaganju tipične spletne strani, ki potrebuje:
- index.html (10 KB)
- styles.css (25 KB)
- app.js (100 KB)
- logo.png (15 KB)
- hero-image.jpg (200 KB)
Pri protokolu HTTP/1.1 brskalnik odpre več povezav za vzporedno pridobivanje podatkov, pri čemer še vedno naleti na omejitve. Pri HTTP/2 se vseh pet virov hkrati prenaša prek ene povezave kot več podatkovnih tokov. Podatkovni okviri iz različnih tokov se prepletajo, odjemalec in strežnik pa učinkovito upravljata celotno povezavo.
Tako ni več potrebe po več povezavah TCP, s čimer se zmanjša režija oken za nadzor pretoka povezave in bistveno izboljša zmogljivost spleta.
Stiskanje glave s HPACK
HPACK, opredeljen v standardu RFC 7541 (objavljen skupaj s protokolom HTTP/2 maja 2015), zagotavlja stiskanje glave, posebej zasnovano za protokol HTTP/2. To je pomembno, ker so bile glave HTTP/1.1 razglabljajoče in popolnoma nestisnjene, kar je pri vsakem zahtevku povzročilo nepotreben omrežni promet.
Oglejte si glave tipične zahteve HTTP:
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...Te glave pogosto presegajo 700-800 bajtov na zahtevo. S piškotki lahko dosežejo več kilobajtov. Če to pomnožite z več deset zahtevami na stran, zapravljate veliko pasovne širine, kar je še posebej boleče v mobilnih omrežjih.
HPACK stisne glave s tremi mehanizmi:
- Statična tabela: 61 vnaprej določenih parov skupnih polj/vrednosti glave (kot sta :method: GET ali :status: 200), ki jih nikoli ni treba prenesti
- Dinamična tabela: V tabelo, ki je specifična za povezavo in jo odjemalec in strežnik sestavita skupaj, se shranjujejo predhodno prenesene vrednosti glave za ponovno uporabo.
- Huffmanovo kodiranje: Vrednosti nizov se kodirajo s pomočjo vnaprej določene Huffmanove tabele, ki skrči predstavitve besedila.
Rezultat je dramatičen. Ko prva zahteva vzpostavi skupne glave v dinamični tabeli, lahko naslednje zahteve posredujejo samo reference na indekse. Glave, ki so na začetku obsegale kilobajte, se skrčijo na desetine bajtov.
HPACK je bil zasnovan posebej za preprečevanje varnostnih ranljivosti, kot sta CRIME in BREACH, ki so prizadele prejšnje sheme stiskanja, kot je DEFLATE SPDY. Z uporabo statičnih Huffmanovih kod in skrbnim upravljanjem tabel HPACK napadalcem preprečuje, da bi z analizo razmerja stiskanja pridobili skrivnosti iz mešanih podatkov napadalca/žrtve.
Omeniti velja, da HPACK deluje samo na glave HTTP. Telesa odgovorov še vedno uporabljajo standardne mehanizme kodiranja vsebine, kot sta gzip ali Brotli, na ravni HTTP, povsem ločeno od stiskanja glave.
Prednostno razvrščanje strežnika in toka
HTTP/2 uvaja dve funkciji za optimizacijo, ki naj bi nadomestili rešitve HTTP/1.1: strežniško potiskanje za proaktivno dostavo virov in prednostno razvrščanje tokov za inteligentno razporejanje virov.
Potiskanje strežnika
Storitev strežnik push omogoča spletnemu strežniku, da odjemalcu pošlje vire, preden so ti izrecno zahtevani. Mehanizem deluje prek okvirjev PUSH_PROMISE:
- Odjemalec zahteva /index.html
- Strežnik se odzove s HTML, vendar pošlje tudi okvire PUSH_PROMISE, v katerih napove, da bo potisnil /styles.css in /app.js
- Strežnik ta sredstva pošlje v novih tokovih, ki jih sproži strežnik (z identifikatorji tokov s sodimi številkami v skladu s pravili za dodeljevanje identifikatorjev tokov z nižjimi vrednostmi).
- Brskalnik prejme vire, preden pri razčlenjevanju HTML ugotovi, da jih potrebuje.
To odpravlja povratne vožnje. Namesto:
- Zahteva HTML → Prejem HTML
- Razčlenite HTML in odkrijte potrebne CSS → Zahtevajte CSS
- Razčlenjevanje CSS, odkrivanje potrebnih pisav → Zahtevajte pisave
Strežniški potisk združi korake 2-3 v korak 1.
Vendar se je potiskanje strežnika v praksi izkazalo za problematično:
- Brskalniki imajo morda že shranjene v predpomnilniku vire, zato je potiskanje potratno.
- Napačno konfigurirani strežniki preveč agresivno pritiskajo, kar povzroča izgubo pasovne širine.
- Mehanizmi predpomnilnika nikoli niso bili splošno sprejeti
- Številni CDN in brskalniki zdaj privzeto omejujejo ali onemogočajo potiskanje
Odjemalci lahko popolnoma onemogočijo potiskanje tako, da v predgovoru povezave nastavijo SETTINGS_ENABLE_PUSH = 0. Če predgovor povezave odjemalca takoj onemogoči potiskanje, je predgovor povezave strežnika sestavljen iz potrditve in skladnosti.
Prednostna razvrstitev tokov
S prednostno razvrstitvijo toka lahko odjemalci sporočajo pomembnost virov, kar pomaga strežnikom učinkovito dodeljevati pasovno širino. Mehanizem uporablja:
- Uteži: Vrednosti od 1-256, ki označujejo relativno pomembnost
- Odvisnosti: Tokovi so lahko odvisni od drugih tokov in tvorijo drevo odvisnosti z izjavami o odvisnosti tokov.
Praktični primer:
- Tok HTML (utež 256, brez odvisnosti) – najvišja prednostna naloga
- Tok CSS (utež 200, odvisno od HTML) – visoka prioriteta
- Slike nad zgibom (teža 100, odvisno od CSS)
- Analitika JavaScript (utež 16, odvisno od HTML) – nizka prednostna naloga
To zagotavlja, da kritični viri poti upodabljanja prispejo prvi, kar izboljša zaznano hitrost nalaganja, čeprav skupni čas prenosa ostane podoben.
Pomembna opozorila:
- Določanje prednostnih nalog je priporočljivo in ne obvezno.
- Strežniške implementacije se zelo razlikujejo po tem, kako upoštevajo prednostne naloge.
- Posredniki (posredniki, CDN) lahko spremenijo vrstni red okvirjev
- Pri prilagajanju je treba testirati z dejanskim prometom in ne s predpostavkami.
Oglaševana omejitev hkratnega toka vpliva na to, koliko tokov ima lahko hkrati aktivne prednostne naloge.
Nadzor pretoka, ravnanje z napakami in varnostni vidiki
HTTP/2 izvaja lasten nadzor pretoka in obravnavo napak nad TCP, kar je namenjeno scenarijem, v katerih inteligenca aplikacijske plasti presega privzete nastavitve transportne plasti.
Nadzor pretoka
Nadzor pretoka preprečuje, da bi hitri pošiljatelji preobremenili počasne sprejemnike. HTTP/2 uporablja sistem, ki temelji na kreditih, z okvirji WINDOW_UPDATE:
- Vsak tok ima svoje okno za nadzor pretoka sprejemnika.
- Povezava ima tudi okno za nadzor pretoka povezave
- Privzeta velikost okna: 65.535 bajtov (64 KB)
- Pošiljatelji ne morejo pošiljati okvirjev DATA, ki presegajo sprejemnikovo razpoložljivo okno.
- Sprejemniki pošljejo okvire WINDOW_UPDATE za dodelitev več kredita.
Glavne značilnosti:
- Nadzor pretoka je po sistemu hop-by-hop (velja za vsak par pošiljatelj/sprejemnik).
- Ni ga mogoče onemogočiti.
- V okno se štejejo samo okvirji DATA; drugi obvezni podatki okvirja se ne štejejo.
- Nadzor pretoka in nadzor pretoka povezave delujeta neodvisno.
To preprečuje, da bi en sam hiter tok monopoliziral vire povezave, kar je še posebej pomembno, kadar so med odjemalci in izvori posredniki ali CDN.
Ravnanje z napakami
HTTP/2 omogoča podrobno signaliziranje napak:
- Napake na ravni toka: RST_STREAM nemudoma prekine en tok, ne da bi to vplivalo na druge, pri čemer se pojavijo kode napak, kot sta PROTOCOL_ERROR ali FLOW_CONTROL_ERROR
- Napake na ravni povezave: GOAWAY elegantno prekine povezavo in omogoči dokončanje trenutnih zahtevkov, hkrati pa prepreči nove.
Protokol opredeljuje register kod napak, ki vključuje:
- PROTOCOL_ERROR (0x1): Splošna kršitev protokola
- FLOW_CONTROL_ERROR (0x3): Kršena pravila za nadzor pretoka
- FRAME_SIZE_ERROR (0x6): Okvir je presegel SETTINGS_MAX_FRAME_SIZE
- INADEQUATE_SECURITY (0xc): Konfiguracija varnosti transportne plasti je nezadostna
Varnostni vidiki
Čeprav standard RFC 7540 tehnično ne zahteva šifriranja, vsi glavni spletni brskalniki zahtevajo HTTP/2 z varnostjo transportne plasti (TLS). Zaradi tega je TLS 1.2+ dejansko osnovna različica:
- Povezava se začne z rokovanjem TLS, ki vključuje ALPN (pogajanja o protokolu aplikacijskega nivoja).
- Razširitev ALPN se pogaja o identifikatorju “h2” za HTTP/2
- Strežniki se morajo izogibati šibkim nizom šifer, ki so na črnem seznamu specifikacije
- šifrirni kompleti, ki uporabljajo RC4 ali druge zastarele algoritme, sprožijo napake INADEQUATE_SECURITY
V zvezi z zasebnostjo je treba upoštevati naslednje vidike:
- NASTAVITVE in prednostni vzorci lahko odjemalcem odvzamejo prstne odtise.
- Ena sama povezava na izvor povezuje vse dejavnosti uporabnika s tem izvorom.
- Binarni protokol zakrije promet, vendar ga ne skrije pred opazovalci omrežja
Blokiranje vodilnega dela linije TCP
HTTP/2 z multipleksiranjem rešuje blokiranje na ravni protokola HTTP, vendar blokiranje na ravni protokola TCP ostaja. Ko se paket TCP izgubi, se vsi tokovi na tej povezavi ustavijo, dokler se ponovna pošiljka ne zaključi – tudi tokovi, katerih podatki so uspešno prispeli.
Ta omejitev je spodbudila protokol HTTP/3, ki deluje prek protokola QUIC (na osnovi UDP), da bi zagotovil resnično neodvisnost od toka. Izguba paketa, ki prizadene en tok, ne blokira drugih.
Uvajanje in uporaba HTTP/2 v praksi
Leta 2026 je omogočanje protokola HTTP/2 preprosto. Večina sodobnih spletnih strežnikov in CDN ga podpira že v osnovi, predvsem prek HTTPS. Mehanizem za nadgradnjo HTTP pregledno vodi pogajanja.
Zahteve na strani odjemalca
Uporabnikom ni treba storiti ničesar posebnega:
- Vsi sodobni namizni spletni brskalniki (Chrome, Firefox, Safari, Edge) privzeto podpirajo HTTP/2.
- Mobilni spletni brskalniki (Chrome za Android, Safari za iOS) vključujejo popolno podporo
- Združljivost z aktualnimi različicami brskalnikov
- HTTP/2 se pogaja samodejno, ko je na voljo
Konfiguracija na strani strežnika
Strežnik Apache HTTP (2.4.17+):
- Omogočite modul mod_http2 (ne starejšega mod_spdy)
- Dodajanje protokolov h2 http/1.1 v virtualne gostitelje TLS
- Zagotovite, da različica OpenSSL podpira 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 je privzeto omogočen za HTTPS s TLS 1.2+
- Dodatna konfiguracija ni potrebna
Ponudniki CDN:
- Cloudflare: HTTP/2 privzeto omogočen v vseh načrtih
- AWS CloudFront: Privzeto omogočeno za distribucije HTTPS
- Fastly: Podprto in privzeto omogočeno
Preverjanje in odpravljanje težav
S tem kontrolnim seznamom potrdite delovanje protokola HTTP/2:
- Browser DevTools: Odprite zavihek Omrežje, omogočite stolpec Protokol, poiščite “h2”.
- Ukazna vrstica: curl –http2 -I https://example.com prikazuje HTTP/2 v odgovoru
- Spletna orodja: Testne storitve HTTP/2 preverite konfiguracijo
- Preverite posrednike: CDN ali obratni posrednik mora podpirati HTTP/2, ne le izvorni strežnik
Pogoste težave, ki preprečujejo HTTP/2:
- Različica OpenSSL je za podporo ALPN prestara
- Konfiguracija samo TLS 1.0/1.1
- Šibki šifrirni kompleti, ki sprožijo nadomestno delovanje
- Napačno konfiguriran proxy, ki onemogoča podporo HTTP/2
HTTP/2 in več
HTTP/2 ostaja prevladujoči protokol za sodobno spletno komunikacijo, čeprav se HTTP/3 (RFC 9114, objavljen 2022) začenja uporabljati. HTTP/3 rešuje blokiranje glavnega dela linije TCP z delovanjem prek QUIC, vendar model ene povezave TCP protokola HTTP/2 še naprej učinkovito služi večini spletnega prometa.
Za večino spletnih mest HTTP/2 zagotavlja znatno izboljšanje spletne zmogljivosti z minimalnim naporom za konfiguracijo. Že danes začnite izmenjevati okvirje prek protokola HTTP/2 in vaši uporabniki – ne glede na to, ali gre za namizne ali mobilne naprave – bodo deležni hitrejšega in učinkovitejšega nalaganja strani.
Ključne ugotovitve
- HTTP/2 z multipleksiranjem, ki omogoča več hkratnih izmenjav prek ene same povezave, revolucionarno izboljšuje zmogljivost spleta.
- Stiskanje glave HPACK odpravlja odvečen prenos glave, kar je še posebej koristno za mobilne uporabnike.
- Strežniško potiskanje in prednostno razvrščanje tokov optimizirata dostavo virov, čeprav se izvajanje razlikuje.
- Nadzor pretoka preprečuje pomanjkanje virov v več tokovih.
- Namestitev na sodobnih strežnikih je preprosta, potrebna je predvsem konfiguracija HTTPS.
- HTTP/2 podpirajo vsi glavni brskalniki, zato ga končni uporabniki lahko brez težav sprejmejo.
Naslednji koraki
Če še niste preverili protokola HTTP/2 v spletnem strežniku, je zdaj pravi čas. Odprite orodja za razvijalce v brskalniku, naložite svoje spletno mesto in preverite stolpec Protokol. Če namesto “h2” vidite “http/1.1”, preverite konfiguracijo strežnika – na mizi puščate precejšnje povečanje zmogljivosti.
Tisti, ki že uporabljajo HTTP/2, naj spremljajo metriko povezav HTTP/2 v strežniku. Razumevanje obnašanja več hkratnih tokov v resničnem prometu pomaga prepoznati priložnosti za optimizacijo, še preden uporabniki opazijo težave.