HTTP je jedným zo štandardov, na ktorých stojí internet. Pôvodne vznikol, aby poskytoval dokumenty uložené na serveroch, dnes sa ale používa okrem dokumentov aj na výmenu údajov, a to nie len medzi používateľom a serverom, ale aj medzi servermi navzájom. Výhodou HTTP je jeho jednoduchosť, ale zároveň aj schopnosť prispôsobiť sa. Svet IT ale neustále napreduje a na všetko sú kladené nové požiadavky (funkčné, výkonnostné, bezpečnostné). Preto sa podarilo po dlhej dobe štandardizovať novú verziu – HTTP/2. Poďme sa pozrieť na to, čo je nové v HTTP/2.

Ak sa pozrieme trochu do histórie, zistíme, že pred HTTP/2 existovali 3 verzie HTTP. Verzie 0.9, 1.0 a 1.1. Tá prvá podporovala len GET príkaz a nevedela prenášať hlavičky (to je len na ukážku, ako to všetko začalo). Prvým štandardnom sa stala až verzia 1.1, a to v roku 1997. Odvtedy sa dlho nič nedialo – vlastne sa toho v IT (a v internete zvlášť) udialo strašne veľa, ale HTTP vďaka svojej jednoduchosti a flexibilite (je možné pridávať ľubovoľné hlavičky, obsah správy môže byť tiež čokoľvek – HTML, JSON, XML…) to všetko dokázal prežiť.

Samozrejme ideálne to nie je a HTTP 1.1 trpí mnohými nedostatkami a jeden z nich – výkon – si vybral Google, keď začal pracovať na novom protokole SPDY, ktorý by mohol HTTP nahradiť. Nakoniec sa stalo to, čo sa v IT deje bežné, že z existujúceho riešenia sa stane štandard. A tak zo SPDY vznikol nový štandard HTTP/2 (písal sa rok 2015 – teda 18 rokov po tom, čo bol štandardizovaný HTTP 1.1).

Ako som už napísal. Google si z tých mnohých problémov, ktorými HTTP 1.1 trpel, vybral ako najväčší výkon. A tomu aj zodpovedajú nové vlastnosti, ktoré dvojková verzia oproti verzii 1.1 dostala:

• Multiplex – pri starších verziách klient poslal cez TCP požiadavku a čakal za odpoveďou. A až keď prišla, tak mohol (aj tým istým TCP spojením) poslať ďalšiu. Pri HTTP/2 môžu cez kanál prúdiť naraz niekoľko dotazov a odpovedí. Ako presne, to rozoberiem o chvíľu.
• Komprimácia hlavičiek – HTTP/1.1 umožňuje komprimovať obsah správy. HTTP/2 k tomu pridáva aj komprimáciu hlavičiek. Komprimačný štandard je HPACK, ktorý bol vyvinutý spolu s HTTP/2, ale je to samostatný štandard.
• Flow control – dotazy v rámci jedného TCP spojenia je možné prioritizovať.
• Server push – server sa vie za určitých okolností rozhodnúť poslať klientovi aj dáta, ktoré si nevyžiadal.

Najväčšou zmenou je určite zmena singleplexového kanála na mutliplexový (ak by ste si mali o HTTP/2 odniesť nejaký poznatok, tak je to ten tento). Ak ste niekedy sledovali vo vývojárskych nástrojoch prehliadača načítanie komplikovanejšej stránky, mohli ste si všimnúť, že sa deje v určitých skokoch. Načítajú sa štyri dotazy, keď dobehnú, spustia sa ďalšie, aťd. Graf, ktorý zobrazuje časy načítania pripomína šikmú plochu – nové dotazy sa spustia, až keď predchádzajúce skončia. A to nie je dobre.

Tento problém sa označuje názvom head-of-line blocking (alebo HOL blocking). Prehliadače obmedzujú množstvo paralelne otvorených spojení na server (kvôli riziku preťaženia serverov). Ak si teda vypýtajú nejaké súbory zo servera, musí sa čakať, kým sa tieto údaje stiahnu a potom sa pýtajú ďalšie (pričom sa opäť použije existujúce TCP spojenie). V jednom TCP spojení sa teda sťahuje len jeden súbor (singleplex) a počet TCP spojení je obmedzený – a to je hlavné úzke hrdlo HTTP 1.1.

HTTP/2 funguje inak. Stačí mu jedno TCP spojenie, a tým paralelne začne sťahovať veľké množstvo údajov. Každá požiadavka a každá odpoveď je rozdelená na framy (alebo chunky), a tie sú postupne posielané cez TCP spojenie na server, pričom sa to deje naraz pre viacero súborov. Server potom z chunkov vyskladá požiadavku, vypočíta odpoveď a pošle ju rovnakým spôsobom späť.

Aby toto mohol server robiť, správy na server a späť už nemôžu byť uchované ako obyčajný text (plain text), ale binárne. To je ďalšia zmena oproti HTTP 1.1. Vďaka tomuto bolo tiež možné zapracovať do protokolu komprimáciu hlavičiek. Okrem toho, multiplex so sebou prináša škálu možností (a niekedy aj škálu problémov), ako je napríklad prioritizácia požiadaviek alebo riadenie flowu (akou kadenciou má server odpovedať na požiadavky klientovi, aby ich ten stíhal spracovávať).

HTTP/2 bol teda navrhnutý hlavne tak, aby zvýšil výkon. Z toho vyplývajú aj najväčšie zmeny oproti predchádzajúcej verzii. Z pohľadu bezpečnosti stojí za to zmieniť, že HTTP/2 vie komunikovať už len cez HTTPS – takže aj bezpečnosť dostala nejaké vylepšenie.

Budúcnosť by bola žiarivá a HTTP/2 by bol všade, ak by tu neboli isté komplikácie. HTTP/2 vyžaduje jeho znalosť na úrovni klienta aj servera. Klientske aplikácie (v prevažnej väčšine prehliadače) HTTP/2 ovládajú už dávno. So servermi je to trochu horšie. Nie, že by podpora pre HTTP/2 nebola zapracovaná do najbežnejších webových serveroch (Apache, nginx, IIS…), ale tie často využívajú časti OS, ktoré implementujú IP/TCP technologický zásobník. Takže upgrade na HTTP/2 skončí tým, že je nutné aktualizovať niektoré časti OS, a to už je náročnejšia činnosť ako si aktualizovať prehliadač.

Samotnú kapitolu problémov pri zavádzaní HTTP/2 tvoria tzv. middle boxy. To sú proxy, firewall-y a akékoľvek iné sieťové prvky medzi klientom a severom, ktoré pracujú na úrovniach vyšších ako je TCP. Oni totiž tiež môžu HTTP správy kontrolovať alebo modifikovať, a teda im musia rozumieť. Ak nepoznajú HTTP/2, tak ich správanie môže byť nevypočítateľné. A aktualizovať tieto sieťové prvky je niekedy komplikovanejšie ako aktualizovať servery.

Ale vývoj nekončí (a v IT to platí dvojnásobne), a v čase keď toto píšem, je už na ceste HTTP/3 (zatiaľ ako draft). Tá je postavená na ďalšom protokole, ktorý vznikol v dielni Googlu – QUICK. Ten so sebou prináša ešte viac zmien a tou hlavnou je, že namiesto TCP používa UDP protokol. Ten je jednoduchší a negarantuje doručenie. Takže o túto garanciu sa po novom stará HTTP/3, ktorý to robí efektívnejšie ako TCP. Nie že by vývoj TCP zastal, ale vo všeobecnosti platí, že je ľahšie aktualizovať protokoly vo vyšších vrstvách ako v tých nižších. Takže sa HTTP/3 vybralo tou cestou, že bude rýchlejšie použiť jednoduchý, ale zavedený protokol a nad ním na ďalšej vrstve postaviť nový, hoci komplikovanejší protokol. Každopádne ide o väčšiu zmenu ako medzi HTTP 1.1 a HTTP/2, takže bude zaujímavé sledovať, ako veľmi úspešná bude.