Hypertextový prenosový protokol sa od svojho vzniku výrazne vyvinul a protokol HTTP/2 predstavuje jeden z najvýznamnejších skokov v spôsobe prenosu údajov cez celosvetový web. Ak ste si v posledných rokoch všimli rýchlejšie načítavanie webových stránok, je veľká pravdepodobnosť, že v pozadí funguje HTTP/2.
V tejto príručke nájdete všetko, čo potrebujete vedieť o protokole HTTP/2 – odjeho základných mechanizmov a výkonnostných výhod až po praktické kroky nasadenia. Či už ste vývojár, ktorý chce optimalizovať svoj webový server, alebo vás jednoducho zaujíma, čo robí moderné webové stránky takými, aké sú, nájdete tu užitočné poznatky.
Rýchla odpoveď: Čo je HTTP/2 a prečo je to dôležité
HTTP/2 je významná revízia hypertextového prenosového protokolu verzie 1.1, ktorú štandardizovala Internet Engineering Task Force v dokumente RFC 7540 (máj 2015). Zameriava sa na zníženie latencie, zlepšenie využitia sieťových zdrojov a výrazné zrýchlenie načítavania webových stránok – to všetkopri zachovaní plnej spätnej kompatibility s existujúcou sémantikou protokolu HTTP.
V roku 2026 bude používanie protokolu HTTP/2 takmer všadeprítomné. Podľa údajov spoločnosti W3Techs viac ako 1/3 najlepších webových stránok aktívne používa protokol HTTP/2 a väčšina hlavných sietí CDN (Cloudflare, AWS CloudFront, Fastly) ho predvolene zapína pre prevádzku HTTPS. Ak vaša stránka beží na HTTPS s moderným webovým serverom, pravdepodobne už využívate výhody protokolu HTTP/2 bez akejkoľvek ďalšej konfigurácie.
Protokol zavádza niekoľko hlavných funkcií, ktoré riešia výkonnostné nedostatky protokolu HTTP 1.1:
- Multiplexovanie: Viacero dátových prúdov prechádza súčasne cez jedno spojenie TCP
- Kompresia hlavičky (HPACK): Zavedenie kompresie polí hlavičiek, ktorá výrazne znižuje množstvo nadbytočných metadát hlavičiek HTTP
- Binárna vrstva rámovania: Úplne všeobecná rámcová vrstva, ktorá nahrádza textové príkazy efektívnym binárnym rámcovaním správ
- Posunutie servera: Proaktívne poskytovanie zdrojov pred tým, ako si ich prehliadač výslovne vyžiada
- Prioritizácia tokov: Nápovedy klienta, ktoré serverom oznamujú, ktoré zdroje sú najdôležitejšie
Čo to znamená v praxi:
- Rýchlejšie načítanie stránok, najmä na lokalitách náročných na zdroje
- Menší počet potrebných spojení TCP na jeden pôvod
- Lepší výkon v mobilných sieťach s vysokou latenciou
- Lepšie využitie siete vo všetkých oblastiach
Od HTTP/0.9 k HTTP/2: krátka história
Protokol HTTP prešiel dlhú cestu od roku 1991, keď Tim Berners-Lee predstavil protokol HTTP/0. 9 ako jednoduchý mechanizmus na načítanie dokumentov HTML. V roku 1996 nasledoval HTTP/1. 0, ktorý pridal hlavičky a stavové kódy, a HTTP/1.1 bol štandardizovaný v RFC 2068 (1997) a neskôr zdokonalený v RFC 2616 (1999). Takmer dve desaťročia slúžil HTTP/1.1 ako základ komunikácie medzi klientom a serverom na webe.
Web sa však výrazne zmenil. Moderné webové stránky sa zmenili z jednoduchých dokumentov na komplexné aplikácie, ktoré načítavajú desiatky zväzkov JavaScriptu, súborov CSS, obrázkov a volaní API. Dokonca aj pri širokopásmovom pripojení a výkonnom hardvéri vytvárala architektúra HTTP/1.1 úzke miesta:
- Blokovanie hlavy linky: Každé spojenie TCP mohlo naraz spracovať len jednu požiadavku, čo spôsobovalo zbytočnú sieťovú prevádzku, pretože zdroje sa radili do fronty
- Režijné náklady na pripojenie: Webové prehliadače pre stolové počítače a mobilné webové prehliadače zvyčajne otvárajú 6-8 paralelných spojení TCP na pôvod, aby toto obmedzenie obišli.
- Zbytočné hlavičky: Pri každej požiadavke HTTP sa opakovane posielajú rovnaké slovné hlavičky (cookies, user-agent, accept headers).
Spoločnosť Google si tieto problémy uvedomila a v roku 2009 spustila projekt SPDY. Projekt SPDY bol prvýkrát implementovaný v prehliadači Chrome okolo roku 2010 a priniesol niekoľko inovácií:
- Binárne rámovanie namiesto textových protokolov
- Multiplexovanie viacerých požiadaviek cez jedno pripojenie
- Kompresia hlavičky na zníženie réžie
- Prioritizácia tokov pre kritické zdroje
Pracovná skupina IETF pre HTTP videla potenciál SPDY a v roku 2012 ho prijala ako východiskový bod pre HTTP/2. Po rozsiahlej práci pracovnej skupiny ITTF http boli v máji 2015 zverejnené RFC 7540 (HTTP/2) a RFC 7541 (HPACK).
Prijatie prehliadača prebehlo rýchlo:
- Chrome od verzie Chrome 51 (máj 2016) zrušil SPDY v prospech HTTP/2
- Firefox pridal podporu HTTP/2 vo verzii 36 (február 2015)
- Safari vo verzii 9 (september 2015)
- Microsoft Edge sa dodáva s podporou HTTP/2 od svojho prvého vydania
- Dokonca aj Internet Explorer 11 získal podporu HTTP/2 v systéme Windows 8.1 a novších verziách
Ciele návrhu a hlavné rozdiely oproti HTTP/1.1
Protokol HTTP/2 zachováva úplnú kompatibilitu so sémantikou protokolu HTTP/1.1. Metódy ako GET a POST fungujú rovnako. Stavové kódy zostávajú nezmenené. URI a polia hlavičiek HTTP sa riadia rovnakými pravidlami. Mení sa len spôsob, akým sa tieto údaje presúvajú po vedení – mechanika transportnej vrstvy, ktorá určuje skutočnú rýchlosť načítania.
Ciele návrhu protokolu boli jasné:
| Cieľ | Ako to HTTP/2 dosahuje |
|---|---|
| Zníženie oneskorenia | Multiplexovanie eliminuje blokovanie na úrovni HTTP |
| Lepšie využitie pripojenia | Všetky požiadavky na pôvodný počítač sa spracúvajú prostredníctvom jedného spojenia TCP. |
| Rezanie hlavičky nad hlavou | Kompresia HPACK zmenšuje predtým prenesené hodnoty hlavičky |
| Zlepšenie výkonu mobilných zariadení | Menší počet spojení a menšie hlavičky sú výhodné pre siete s vysokou latenciou |
Krása tohto návrhu spočíva v spätnej kompatibilite na úrovni aplikácie. Váš existujúci kód webovej aplikácie – trasy, obslužné programy, logika odpovede – sa nemusí meniť. Aby ste videli výhody, musí HTTP/2 podporovať iba klient a server.
To je v ostrom kontraste s obchádzaním protokolu HTTP/1.1, ktoré museli vývojári implementovať ručne:
- Rozdeľovanie domén: Rozloženie aktív do viacerých domén s cieľom otvoriť viac spojení
- Spojenie aktív: Spájanie súborov CSS a JavaScript na zníženie počtu požiadaviek
- Obrázkové sprajty: Kombinovanie viacerých obrázkov do jedného súboru
- Vloženie: Vkladanie CSS a JavaScriptu priamo do HTML
Základná mechanika protokolu HTTP/2, ktorá nahrádza tieto hacky:
- Binárna vrstva rámovania: Správy rozdelené do rámcov efektívne prenášajú údaje ako binárne protokolové jednotky
- Multiplexované prúdy: Viacero súbežných výmen prebieha cez to isté pripojenie
- Kompresia hlavičky HPACK: Dynamické tabuľky sledujú hlavičky, čím sa eliminuje redundancia
- Posunutie servera: Servery proaktívne posielajú zdroje, ktoré bude klient potrebovať.
- Prioritizácia tokov: Klienti signalizujú, ktoré zdroje sú najdôležitejšie, prostredníctvom váh závislosti od toku
Binárne rámovanie, prúdy, správy a multiplexovanie
Základom protokolu HTTP/2 je binárna rámcová vrstva, ktorá predstavuje zásadný odklon od textového formátu protokolu HTTP/1.1. Každá správa HTTP sa rozdelí do binárnych rámcov s konzistentným rozložením rámcov: 9-bajtová hlavička rámca obsahuje dĺžku, typ, príznaky a identifikátory toku, za ktorými nasledujú voliteľné údaje užitočného zaťaženia.
Pochopenie hierarchie si vyžaduje pochopenie troch pojmov:
Streamy sú nezávislé obojsmerné kanály v rámci jedného pripojenia. Každý prúd má jedinečný 31-bitový identifikátor. Klienti iniciujú toky s nepárnymi identifikátormi (1, 3, 5…), zatiaľ čo servery používajú párne identifikátory (2, 4, 6…) pre toky iniciované serverom, napríklad push. Neočakávaný identifikátor prúdu vyvolá chybu. Nastavenie maximálneho počtu súbežných streamov riadi, koľko ich môže byť aktívnych súčasne.
Správy predstavujú úplné požiadavky alebo odpovede HTTP. Kompletný blok hlavičky pozostáva z jedného alebo viacerých rámcov a odpovede môžu obsahovať viacero dátových rámcov tela. Keď prijímač narazí na fragmenty bloku hlavičky, opätovne ich zloží, aby zrekonštruoval celú správu.
Rámčeky sú najmenšie jednotky na drôte. Medzi bežné typy rámcov a chýb patria:
- Rámce DÁT: Prenášajú obsah tela žiadosti/odpovede
- Rámček HEADERS: Obsahuje polia hlavičky HTTP, prípadne rozdelené do viacerých rámcov nazývaných fragmenty bloku hlavičky
- NASTAVENIA: Hlásenia o riadení pripojenia pre konfiguráciu
- WINDOW_UPDATE: Úpravy okna riadenia toku
- PUSH_PROMISE: Oznamuje server push
- RST_STREAM: Ukončí prúd s chybovým kódom
- GOAWAY: Spustí postupné vypínanie pripojenia
Kúzlo sa deje prostredníctvom multiplexovania. Pretože rámce z viacerých súčasne otvorených prúdov sa môžu prelínať cez jedno spojenie TCP – pričom oba koncové body môžu rámce prelínať podľa potreby -, nemusíte čakať. Príjemca opätovne skladá rámce podľa identifikátora toku.
Zoberme si načítanie typickej webovej stránky, ktorá potrebuje:
- index.html (10 KB)
- styles.css (25 KB)
- app.js (100 KB)
- logo.png (15 KB)
- hero-image.jpg (200 KB)
Pri protokole HTTP/1.1 prehliadač paralelne otvára viacero spojení na ich načítanie, pričom stále naráža na limity. Pri protokole HTTP/2 sa všetkých päť zdrojov prenáša súbežne cez jedno spojenie ako viacero dátových tokov. Dátové rámce z rôznych tokov sa prelínajú, pričom klient aj server efektívne spravujú celé spojenie.
Tým sa eliminuje potreba viacerých spojení TCP, znižuje sa réžia okien riadenia toku spojenia a výrazne sa zlepšuje výkon webu.
Kompresia hlavičky pomocou HPACK
HPACK, definovaný v dokumente RFC 7541 (uverejnenom spolu s protokolom HTTP/2 v máji 2015), poskytuje kompresiu hlavičiek špeciálne navrhnutú pre protokol HTTP/2. Je to dôležité, pretože hlavičky HTTP/1.1 boli slovné a úplne nekomprimované, čo spôsobovalo zbytočnú sieťovú prevádzku pri každej požiadavke.
Zoberme si typické hlavičky požiadavky 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...Tieto hlavičky často presahujú 700-800 bajtov na jednu požiadavku. Pri súboroch cookie sa môžu zväčšiť až na niekoľko kilobajtov. Vynásobte to desiatkami požiadaviek na stránku a strácate značnú šírku pásma – čo je obzvlášť nepríjemné v mobilných sieťach.
HPACK komprimuje hlavičky tromi mechanizmami:
- Statická tabuľka: 61 preddefinovaných spoločných dvojíc polí/hodnot (ako napríklad :method: GET alebo :status: 200), ktoré nikdy nie je potrebné prenášať
- Dynamická tabuľka: Tabuľka špecifická pre pripojenie, ktorú klient a server vytvárajú spoločne a v ktorej sa ukladajú predtým prenesené hodnoty hlavičiek na opätovné použitie.
- Huffmanovo kódovanie: Hodnoty reťazcov sa kódujú pomocou preddefinovanej Huffmanovej tabuľky, čím sa zmenšuje reprezentácia textu.
Výsledok je dramatický. Po tom, čo prvá požiadavka vytvorí spoločné hlavičky v dynamickej tabuľke, môžu nasledujúce požiadavky prenášať len odkazy na indexy. Hlavičky, ktoré na začiatku predstavovali kilobajty, sa zmenšia na desiatky bajtov.
HPACK bol špeciálne navrhnutý tak, aby sa vyhol bezpečnostným zraniteľnostiam, ako sú CRIME a BREACH, ktoré postihovali predchádzajúce kompresné schémy, ako napríklad DEFLATE SPDY. Použitím statických Huffmanových kódov a starostlivou správou tabuliek HPACK zabraňuje útočníkom použiť analýzu kompresného pomeru na získanie tajomstiev zo zmiešaných údajov útočníka/obete.
Stojí za zmienku, že HPACK pracuje iba s hlavičkami HTTP. Telá odpovedí stále používajú štandardné mechanizmy kódovania obsahu ako gzip alebo Brotli na vrstve HTTP, úplne oddelené od kompresie hlavičiek.
Server Push a prioritizácia toku
Protokol HTTP/2 zavádza dve optimalizačné funkcie, ktoré majú nahradiť obchádzanie protokolu HTTP/1.1: server push na proaktívne doručovanie zdrojov a prioritizáciu toku na inteligentné zoraďovanie zdrojov.
Server Push
Funkcia Server push umožňuje webovému serveru odosielať zdroje klientovi ešte pred ich výslovným vyžiadaním. Tento mechanizmus funguje prostredníctvom rámcov PUSH_PROMISE:
- Požiadavky klienta /index.html
- Server odpovedá HTML, ale zároveň posiela rámce PUSH_PROMISE, v ktorých oznamuje, že bude posielať /styles.css a /app.js
- Server odošle tieto prostriedky na nové toky iniciované serverom (s identifikátormi tokov používajúcimi párne čísla podľa pravidiel prideľovania identifikátorov tokov s nižšou hodnotou).
- Prehliadač dostane zdroje predtým, ako pri analyzovaní HTML zistí, že ich potrebuje
Tým sa eliminujú okružné jazdy. Namiesto:
- Žiadosť HTML → Prijatie HTML
- Rozbor HTML, zistenie potrebných CSS → Vyžiadanie CSS
- Rozbor CSS, zistenie potrebných fontov → Vyžiadanie fontov
Stlačením servera sa kroky 2-3 zhrnú do kroku 1.
V praxi sa však ukázalo, že server push je problematický:
- Prehliadače už môžu mať zdroje uložené v medzipamäti, takže tlačenie je zbytočné
- Nesprávne nakonfigurované servery tlačia príliš agresívne, čím plytvajú šírkou pásma
- Mechanizmy prehrávania vyrovnávacej pamäte sa nikdy nedočkali širokého prijatia
- Mnohé siete CDN a prehliadače teraz predvolene obmedzujú alebo zakazujú funkciu push
Klienti môžu úplne vypnúť funkciu push nastavením SETTINGS_ENABLE_PUSH = 0 v predvoľbe pripojenia. Keď klientská predvoľba pripojenia okamžite zakáže funkciu push, predvoľba pripojenia servera pozostáva z potvrdenia a splnenia požiadaviek.
Prioritizácia tokov
Prioritizácia toku umožňuje klientom signalizovať dôležitosť zdrojov, čo pomáha serverom efektívne prideľovať šírku pásma. Tento mechanizmus využíva:
- Hmotnosti: Hodnoty od 1-256 označujúce relatívnu dôležitosť
- Závislosti: Streamy môžu závisieť od iných streamov a vytvárať strom závislostí prostredníctvom deklarácií závislostí streamov.
Praktický príklad:
- HTML stream (váha 256, bez závislosti) – najvyššia priorita
- CSS stream (váha 200, závisí od HTML) – vysoká priorita
- Obrázky nad záhybom (hmotnosť 100, závisí od CSS)
- Analytický JavaScript (váha 16, závisí od HTML) – nízka priorita
Tým sa zabezpečí, že kritické zdroje vykresľovacej cesty prídu ako prvé, čím sa zvýši vnímaná rýchlosť načítania, aj keď celkový čas prenosu zostane podobný.
Dôležité upozornenia:
- Stanovenie priorít je odporúčané, nie povinné
- Implementácie serverov sa značne líšia v tom, ako dodržiavajú priority
- Sprostredkovatelia (proxy, CDN) môžu meniť poradie rámcov
- Ladenie si vyžaduje testovanie s reálnou prevádzkou, nie s predpokladmi
Inzerovaný limit súbežného toku ovplyvňuje, koľko tokov môže mať súčasne aktívne priority.
Riadenie toku, spracovanie chýb a bezpečnostné aspekty
Protokol HTTP/2 implementuje vlastné riadenie toku a spracovanie chýb nad protokolom TCP, čím rieši scenáre, v ktorých inteligencia aplikačnej vrstvy prekonáva predvolené nastavenia transportnej vrstvy.
Riadenie toku
Riadenie toku zabraňuje tomu, aby rýchli odosielatelia zahltili pomalé prijímače. HTTP/2 používa systém založený na kreditoch s rámcami WINDOW_UPDATE:
- Každý prúd má vlastné okno riadenia toku prijímača
- Spojenie má tiež okno riadenia toku spojenia
- Predvolená veľkosť okna: 65 535 bajtov (64 KB)
- Odosielatelia nemôžu prenášať rámce DATA, ktoré presahujú dostupné okno prijímača
- Prijímatelia posielajú rámce WINDOW_UPDATE, aby poskytli viac kreditu
Kľúčové vlastnosti:
- Riadenie toku je hop-by-hop (platí medzi každým párom odosielateľ/prijímateľ)
- Nemožno ho vypnúť
- Do okna sa započítavajú len DATA rámce; ostatné povinné údaje o rámcoch sa nezapočítavajú.
- Riadenie toku prúdu aj riadenie toku pripojenia fungujú nezávisle
Tým sa zabráni monopolizácii zdrojov pripojenia jediným rýchlym tokom, čo je dôležité najmä vtedy, keď sa medzi klientmi a pôvodnými servermi nachádzajú proxy servery alebo siete CDN.
Spracovanie chýb
Protokol HTTP/2 poskytuje granulárne signalizovanie chýb:
- Chyby na úrovni toku: RST_STREAM okamžite ukončí jeden prúd bez toho, aby ovplyvnil ostatné, a nesie chybové kódy ako PROTOCOL_ERROR alebo FLOW_CONTROL_ERROR
- Chyby na úrovni pripojenia: GOAWAY elegantne ukončí pripojenie, čím umožní dokončenie požiadaviek počas letu a zároveň zabráni novým požiadavkám.
Protokol definuje register kódov chýb vrátane:
- PROTOCOL_ERROR (0x1): Porušenie všeobecného protokolu
- FLOW_CONTROL_ERROR (0x3): Pravidlá riadenia toku porušené
- FRAME_SIZE_ERROR (0x6): Rámec prekročil SETTINGS_MAX_FRAME_SIZE
- INADEQUATE_SECURITY (0xc): Nedostatočná konfigurácia zabezpečenia transportnej vrstvy
Bezpečnostné aspekty
Hoci RFC 7540 technicky nevyžaduje šifrovanie, všetky hlavné webové prehliadače vyžadujú HTTP/2 cez zabezpečenie transportnej vrstvy (TLS). Tým sa TLS 1.2+ stáva de facto základnou verziou:
- Spojenie sa začína podaním protokolu TLS vrátane ALPN (Application-Layer Protocol Negotiation)
- Rozšírenie ALPN vyjednáva identifikátor „h2“ pre HTTP/2
- Servery sa musia vyhýbať slabým súborom šifier, ktoré sú na čiernej listine špecifikácie
- Šifrové sady používajúce RC4 alebo iné zastarané algoritmy vyvolávajú chyby INADEQUATE_SECURITY
Ochrana osobných údajov zahŕňa:
- NASTAVENIA a vzory priorít môžu klientom odoberať odtlačky prstov
- Jedno spojenie na jeden pôvod koreluje všetku aktivitu používateľa s týmto pôvodom
- Binárny protokol zahmlieva prevádzku, ale neskrýva ju pred pozorovateľmi siete
Blokovanie vedúcich liniek TCP
Protokol HTTP/2 rieši blokovanie na úrovni HTTP prostredníctvom multiplexovania, ale blokovanie na úrovni TCP zostáva. Keď sa stratí paket TCP, všetky toky na danom spojení sa zastavia, kým sa nedokončí opakované odoslanie – dokonca aj toky, ktorých údaje boli úspešne doručené.
Toto obmedzenie motivovalo HTTP/3, ktorý beží cez QUIC (založený na UDP), aby poskytol skutočnú nezávislosť od toku. Strata paketu, ktorá ovplyvní jeden tok, nezablokuje ostatné.
Nasadenie a používanie protokolu HTTP/2 v praxi
V roku 2026 je povolenie protokolu HTTP/2 jednoduché. Väčšina moderných webových serverov a CDN ho podporuje hneď po vybalení, predovšetkým cez HTTPS. Mechanizmus aktualizácie HTTP transparentne spracúva vyjednávanie.
Požiadavky na strane klienta
Používatelia nemusia robiť nič špeciálne:
- Všetky moderné webové prehliadače (Chrome, Firefox, Safari, Edge) podporujú HTTP/2 v predvolenom nastavení
- Mobilné webové prehliadače (Chrome pre Android, Safari pre iOS) obsahujú plnú podporu
- Kompatibilita s aktuálnymi verziami prehliadačov
- HTTP/2 vyjednáva automaticky, keď je k dispozícii
Konfigurácia na strane servera
Server Apache HTTP (2.4.17+):
- Povolenie modulu mod_http2 (nie staršieho mod_spdy)
- Pridanie protokolov h2 http/1.1 do virtuálnych hostiteľov TLS
- Uistite sa, že verzia OpenSSL podporuje 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+):
- Predvolene povolený protokol HTTP/2 pre protokol HTTPS s TLS 1.2+
- Nie je potrebná žiadna ďalšia konfigurácia
Poskytovatelia CDN:
- Cloudflare: HTTP/2 predvolene povolený vo všetkých plánoch
- AWS CloudFront: Predvolene povolené pre distribúcie HTTPS
- Fastly: Podporované a predvolene povolené
Overovanie a riešenie problémov
Pomocou tohto kontrolného zoznamu potvrďte, že protokol HTTP/2 funguje:
- Nástroje DevTools prehliadača: Otvorte kartu Sieť, zapnite stĺpec Protokol, vyhľadajte „h2“.
- Príkazový riadok: curl –http2 -I https://example.com zobrazuje HTTP/2 v odpovedi
- Online nástroje: Testovacie služby HTTP/2 overujú konfiguráciu
- Skontrolujte sprostredkovateľov: CDN alebo reverzný proxy server musí podporovať HTTP/2, nielen origin server
Bežné problémy brániace protokolu HTTP/2:
- Príliš stará verzia OpenSSL pre podporu ALPN
- Konfigurácia len TLS 1.0/1.1
- Slabé sady šifier spúšťajúce núdzové riešenie
- Nesprávne nakonfigurovaný proxy server odoberajúci podporu protokolu HTTP/2
HTTP/2 a viac
Protokol HTTP/2 zostáva dominantným protokolom pre modernú webovú komunikáciu, aj keď sa začína zavádzať protokol HTTP/3 (RFC 9114, publikovaný v roku 2022). HTTP/3 rieši blokovanie TCP head-of-line tým, že beží cez QUIC, ale model jedného spojenia TCP protokolu HTTP/2 naďalej efektívne slúži väčšine webovej prevádzky.
Pre väčšinu webov prináša protokol HTTP/2 podstatné zlepšenie výkonu webu s minimálnym úsilím o konfiguráciu. Začnite si vymieňať rámce cez HTTP/2 ešte dnes a vaši používatelia – či už na počítači alebo na mobilnom zariadení – budú mať rýchlejšie a efektívnejšie načítanie stránok.
Kľúčové závery
- Protokol HTTP/2 prináša revolúciu vo výkone webu vďaka multiplexovaniu, ktoré umožňuje viacero súbežných výmen cez jedno pripojenie.
- Kompresia záhlavia HPACK eliminuje nadbytočný prenos záhlavia, z čoho profitujú najmä mobilní používatelia
- Server push a prioritizácia toku optimalizujú poskytovanie zdrojov, hoci implementácia sa líši
- Riadenie toku zabraňuje nedostatku zdrojov vo viacerých prúdoch
- Nasadenie je na moderných serveroch jednoduché, vyžaduje si predovšetkým konfiguráciu HTTPS
- Všetky hlavné prehliadače podporujú protokol HTTP/2, takže jeho prijatie je pre koncových používateľov bezproblémové
Ďalšie kroky
Ak ste ešte neoverili protokol HTTP/2 na svojom webovom serveri, teraz je ten správny čas. Otvorte nástroje pre vývojárov vo svojom prehliadači, načítajte svoju stránku a skontrolujte stĺpec Protokol. Ak namiesto „h2“ vidíte „http/1.1“, skontrolujte konfiguráciu svojho servera – nechávate na stole významný nárast výkonu.
Tí, ktorí už používajú protokol HTTP/2, zvážte monitorovanie metrík pripojenia HTTP/2 na svojom serveri. Pochopenie správania sa viacerých súbežných tokov pri reálnej prevádzke pomáha identifikovať možnosti optimalizácie skôr, ako si používatelia všimnú problémy.