Dušan DINGARAC

1. septembar 2021.

Veb je servis koji je najzaslužniji za bum interneta. Tokom njegovog razvoja, u proteklih četrdeset godina možda se najmanje menjao http protokol koji je odgovoran za prenos svega onoga što gledamo na vebu. Usložnjavanje veb-stranica i njihovo stalno povećanje po svim aspektima, (veličina i broj fajlova koje stranica učitava) zahtevalo je unapređenja transportnog protokola. No, sada je, po prvi put, promena napravljena na jednom sasvim drugačijem nivou, koji će se u budućnosti odraziti na mnoge protokole na internetu.

Prethodni period

Poslednji put kada je http protokol menjan, „Svet kompjutera” je o tome pisao (SK 9/15, i.sk.rs/358117). No, kako je od tada prošlo šest godina, biće dobro da se podsetimo kako su se stvari odvijale od samog početka.

Veb je nastao 1991. godine. Tada je http protokol predstavljen u verziji 0.9. Ta rana vremena veba donela su zapažanja kako da se protokol finalizuje i unapredi i 1996. godine predstavljen je http 1.0. Praktično, tada je predstavljen protokol kakav i danas koristimo. Kod http 1.0 za svaki zahtev/odgovor između klijenta i servera kreira se zasebna TCP konekcija. To znači da svaki zahtev trpi kašnjenje, jer se TCP i TLS dogovaranja (handshake) kompletno obavljaju pre svakog zahteva. To funkcioniše tako što klijent uputi serveru TCP sinhronizacioni zahtev, server vrati taj zahtev klijentu sa potvrdom, a onda klijent to potvrdi serveru. Ako je u pitanju https zahtev, onda se ovakva procedura ponovi na TLS nivou, pa tek onda klijent može da uputi zahtev serveru i da mu server vrati neki podatak. Dok su se veb-stranice sastojale od teksta uz tek poneku sliku, ovakav protokol je bio zadovoljavajuć.

Međutim, html je napredovao sa svojim verzijama, slike su bile sve češće i već je u veb-prezentacijama počeo je da se pojavljuje i video-sadržaj, ali i prateći JavaScript, CSS i drugi fajlovi. Internet veze postajale su sve brže i brže. Ljudi su tražili i brži veb. U praksi, postoji u okviru TCP protokla sistem „zaštite” servera od toga da počne da šalje previše podataka klijentu, koje on, zbog brzine svoje konekcije, ne može da primi, pa se u praksi dešava jedan period kada server dozira količinu podataka koje šalje klijentu dok ne utvrdi kojom brzinom može da prima podatke. Ovo je poznato i pod nazivom „spori start”.

Da bi se izbeglo da svaki zahtev za pojedinačnim elementom veb-stranice mora da prođe TCP i eventualno TLS proces dogovaranja, već 1997. godine predstavljen je protokol http 1.1. Glavna izmena koju je on doneo je takozvana keep alive konekcija. Kada se uspostavi veza između klijenta i servera samo jednom se prođu inicijalna dogovaranja i nakon toga se http zahtevi šalju sekvencijalno preko te konekcije.

No, proizvođači klijenata počeli su da unapređuju svoje pregledače uspostavljanjem višestrukih konekcija ka serveru, kako bi paralelno dobijali više elemenata veb-stranice. Korišćenjem višestrukih konekcija, dobar deo prednosti koje je keep alive konekcija u http 1.1 donela, izgubljene su.

Prošlo je više od decenije, a da se ništa nije menjalo po pitanju http protokola. U takvoj situaciji, Google je kreirao svoj protokol SPDY. Očigedno, nastao kao skraćenica od reči brzina. Google je ovaj protokol razvijao, ali i testirao u praksi. Naime, prema nekim podacima, Google je u jednom trenutku imao nekih sedam odsto ukupnog veb-saobraćaja prema svojim serverima, a implementirajući SPDY podršku u Chrome i svoje servere, omogućio je da se veliki deo ovog saobraćaja odvija preko SPDY protokla. Kada je stvar sazrela, u verziji 2.0, protokol je dat na usvajanje nadležnim telima i nekoliko godina kasnije njegovom modifikacijom nastao je http 2.0 (2015. godine).

Šta je Google, zapravo, uradio? Najvažnija stvar bila je uvođenje koncepta http tokova. Reč je o apstrakciji, da se kroz jedan TCP kanal omogući istovremeni višestruki multipleks http zahteva. To znači da dok se dovlači neka .JPEG slika, istovremeno se dovlači i css fajl i nekoliko .GIF slika. Zapravo, sav taj saobraćaj se serijalizuje preko jednog TCP toka.

Ovakav koncept umnogome je ubrzao veb-servis. Međutim, nije rešio sve probleme. TCP je zadužen da isporuči podatke sa jednog na drugi kraj mreže u nizu malih paketa. Ukoliko se neki od paketa izgubi, odnosno, ne stigne na odredište i odredište ne javi izvorištu da je paket primljen, TCP mora da zaustavi dalje slanje novih paketa, pa time da zaustavi slanje podataka, dok se izgubljeni paket ne pošalje ponovo i ne dobije potvrda da je to uspešno obavljeno. Koncept je jasan, ali koliko se to često dešava? Da li je zbog ovog mehanizma ugrožena brzina veb-servisa ili se to dešava toliko retko da se može zanemariti?

Na ovo pitanje ne postoji jedinstven odgovor. Ukoliko je veza pouzdana, gubitak paketa dešava se veoma retko. Ali, ukoliko je veza nižeg kvaliteta, gubitak paketa i nije tako redak događaj. Iako je u razvijenim zemljama uvođenjem novih tehnologija kvalitet konekcija znatno poboljšan, u siromašnijim zemljama to nije slučaj. Sa druge strane, bežične veze koje su omasovljne (internet putem mobilnih telefona, WiFi, uskoro i sateliti u niskoj orbiti), znatno su nepouzdanije i gubici paketa nisu retkost.

Dakle, gubitak jednog paketa zaustavlja prenos svih istovremenih zahteva koji idu kroz jedan http stream.

Nova era

Očigledno, za efikasan veb-servis, posebno na nepouzdanim linijama, mora da se promeni nešto u korenu. TCP, jednostavno, nije dovoljno dobar da omogući to. OK, zašto onda ne bismo stvorili sasvim nov protokol? Protokol koji će da zameni TCP i koji će korišćenjem IP protokola omogućiti da u slučaju gubitka paketa bude privremeno zaustavljen samo jedan od istovrmenih tokova http zahteva. Ideja zvuči sjajno, no, gotovo je neizvodljiva u praksi.

Da bi novi protokol mogao da prenosi veb-saobraćaj od klijenta do servera i natrag, neophodno je da prođe kroz različitu mrežnu opremu. Ne samo velike rutere, već i razne male „internet kutije” koje se nalaze u kućama krajnjih korisnika interneta. Svi ovi uređaji ne poznaju taj hipotetički „novi” protokol, a promena njihovog softvera je nemoguća. Većina tih malih kutija radi i preko deset godina, bez ikakvog inoviranja svog softvera. Možda bi tako nešto moglo da se izvede na nekom broju većih rutera koji čine Mrežu, ali i ozbiljniji ruteri ne dobijaju apdejte automatski, a često se koriste i nakon isteka perioda podrške proizvođača.

Koliko je ovaj posao nemoguć možda najbolje govori podatak da je danas procenat http saobraćaja koji se obavlja po protokolu 2.0 tek oko pedeset odsto svog http saobraćaja. Dakle, šest godina je bilo potrebno da se polovina saobraćaja prebaci na novi protokol. Tu nisu problem klijenti, već serveri, a promena softvera na svim ruterima da prihvate novi protokol je tri reda veličine složeniji zahtev.

Google je ponovo pronašao jedno rešenje koje će moći da izbegne opisani problem zaustavljanja svih istovremenih transfera (tzv. head-of-line blocking), a ujedno da to omogući na postojećoj mrežnoj opremi. Goole je počeo da radi na ovom rešenju pre nego što je SPDY 2.0 poslao na „standardizaciju”.

Naime, TCP ima svoj bratski protokol UDP. Oba protokola su na višem nivou od IP protokola, ali imaju jednu suštinsku razliku. Dok se TCP brine o tome da se nijedan podatak ne izgubi i upravo zato vrši retransmisiju izgubljenih paketa, UDP ne brine o tome. On paket pošalje i baš ga briga da li je stigao na odredište.

Zbog toga je Google rešio da u okviru UDP protokola implementira dodatnu logiku, da je enkapsulira u UDP, a koja će se brinuti o tome da li je paket stigao na svoju destinaciju i ako nije, da uradi retransmisiju. Ali, ta implementacija omogućava da se istovremeni zahtevi evidentiraju kao odvojeni tokovi podataka, pa ne postoji problem head-of-line blockinga.

Međutim, i ovoga puta kada je protokol otišao na standardizaciju došlo je do izmena. Naime, logika koja se brine o integritetu paketa koja je enkapsulirana u UDP datagrame, a koja je nazvana QUIC (ponovo jedna skraćena reč engleskog jezika koja se kod nas može prevesti kao „brzo”), dobila je integraciju TLS 1.3 protokola. Zbog toga, nije moguće „proterati” http 2.0 preko QUIC protokola, zato što HPACK (shema kopmresije headera) veoma zavisi od redosleda kojim se različiti http zahtevi i odgovori isporučuju serveru i klijentu.

Dakle, kada pominjemo http/3, odnosno, http 3.0, moramo da znamo da on funkcioniše samo uz pomoć QUIC protokola i da se sve prenosi putem UDP datagrama.

Ne tako brzo

Eto, sada kada znamo kako izgleda novi http protokol možda je pravo pitanje šta ćemo u samoj praksi dobiti i koliko će se to brzo desiti?

Pre svega, na pouzdanim mrežama primena http 3.0 u odnosu na http 2.0 neće doneti neka vidna poboljšanja. Kada nema gubitaka podataka, nema ni head-of-line blockinga, pa ni usporenja. Kada su u pitanju sve manje pouzdane mreže, mobilne mreže, problematične WiFi mreže sa smetnjama, područja sa slabijim signalom, pa u budućnosti i satelitski servisi, poput Starlinka, tu će se osetiti poboljšanje, a učitavanje veb-stranica teći će mnogo „glatkije”.

Što se tiče procena kada će to sve zaživeti u nekom većem obimu, možda je nabolje da se osvrnemo na analogiju sa polovičnom zastupljenosti http 2.0 nakon šest godina. Da se razumemo, gotovo svi veb-pregledači već podržavaju ovaj protokol. Možemo sada da navodimo koji od njih od koje verzije podržava http 3.0 i QUIC. No, oni su najmanji problem. Veb-serveri su mnogo veći problem. Neki od njih još uvek su u probnim implementacijama (npr. NGINX), a neki će tek podržati ovaj protokol (npr. Apache). Velike CDN (Content Delivery Networks), poput Cloudfare, već ga podržavaju, ali ga postepeno uvode svojim klijentima. Već sada postoje biblioteke u raznim programskim jezicima koje podržavaju http 3.0, ali do njihove zrelosti proći će još vremena. Jednostavno, u pitanju je nova tehnologija i mnogi timovi rade na njenoj implementaciji.

Dodatni problemi mogu se očekivati na raznim firewall sistemima, posebno u velikim firmama koje zarad bezbednosti filtriraju sve i svašta od saobraćaja. Iako će http 3.0 raditi na portu 443, on nece raditi na TCP, već na UDP protokolu. A on je, uglavnom, filtriran, jer se retko upotrebljavao i često je bio povezan sa raznim neželjenim, tj. malicioznim transferima. Treba dodati tu i razne proxy sisteme koji će onemogućiti da http 3.0 automatski svuda proradi, a koji se koriste u velikim sistemima.

Port 80 polako odlazi u penziju, jer sa http 3.0 ostvareno je ono što, ipak, nije završilo kao obaveza u http 2.0 - da je sav saobraćaj enkriptovan putem TLS protokola. Upravo ovakav saobraćaj, koji ne može da se „nadgleda” na mrežnim uređajima, deluje sumnjivo i teško ga je razlikovati od malicioznog saobraćaja. Tokom razvoja protokola, postojali su pritisci da se omogući inspekcija saobraćaja, ali su tvorci standarda uspeli da se tome odupru.

Čitavu priču o protokolu smo ispričali u opštima crtama. On, svakako, ima i raznih detalja o kojima nismo govorili. Pomenimo samo da je jedna od karakteristika utvrđivanje raspoloživosti http 3.0 servisa i u slučaju da je raspoloživ, prosleđivanje klijentu njegove adrese, a ako nije, nastavak komunikacije po 2.0 standardu.

Zalog za budućnost...

Ako standard neće doneti neka posebna ubrzanja na pouzdanim mrežama, ako neće ni tako brzo da masovnije zaživi, zašto je onda to sve tako spektakularno? Sam http 3.0 nije nimalo spektakularan. Prava zvezda je QUIC, protokol koji mnogo obećava u budućnosti.

Pre svega, QUIC je protokol koji neće zavisiti od mrežnog hardvera. To će omogućiti brze promene u slučaju nekog unapređenja standarda. U QUIC je ugrađen TLS 1.3, što obezbeđuje da će se sav saobraćaj obavljati sa bezbednim šifrovanjem. To je drastična razlika u odnosu na sve stare internet protokole koji su svu komunikaciju obavljali bez bilo kakve zaštite i svako ko je mogao da „sluša” mrežni saobraćaj, mogao je da rekonstruiše svu komunikaciju. Naravno, na te stare protokole su kalemljene TLS i druge bezbedne metode, ali ovde pričamo o tome da je kroz dizajn protokola enkripcija obavezna.

Dalje, QUIC u okviru svojih paketa ne označava konekcije samo po izvorišnoj i odredišnoj adresi i portu po kome se obavlja komunikacija, već na dodatni način. To omogućava ne samo izbegavanje head-of-line blockinga, već mogućnost da prilikom promene mreže, pa time i IP adrese, a verovatno i porta po kome je konekcija ostvarena, ne dođe do prekida veze. Na primer, krećete od kuće gde ste započeli online meeting na mobilnom telefonu preko kućne WiFi mreže. Ulazite u automobil i gubitkom WiFi signala telefon se prebacuje na GPRS saobraćaj mobilne mreže, a po dolasku na posao, kači se na WiFi mrežu kompanije. QUIC u okviru svojih paketa numeriše konekciju i ovi prelazi sa mreže na mrežu se neće ni osetiti u kvalitetu prenosa online meetinga.

Naravno, ovaj scenario se očekuje u bliskoj budućnosti, jer za sada je QUIC implementiran sa http 3.0 standardom upravo da bi se zaokružio ceo koncept i očekivano je da će se u budućnosti veliki broj protokola i aplikacija realizovati putem QUIC protokola. Jedan od prvih koji je najavljen je DNS. Razne tehnike koje su sada „kalemljene” na DNS da bi se omogućila bezbednost ovog protokola postaće nebitne, jer će se on implementirati putem QUIC protokola, koji je po svom dizajnu šifrovan i podržava sistem kvalifikovanih sertifikata.

Naravno, pojedini proizvođači koji imaju „zatvorene” sisteme. Kada i server i klijent predstavljaju sopstveni proizvod, mogu odmah da implementiraju QUIC u svoje protokole. Tu svakako treba pomenuti Microsoft, koji je svoju implementaciju QUIC protokola, pod nazivom MsQuic, stavio u Open Source (i.sk.rs/358118) i planira da je implementira u SMB protokol i da ga koristi u Windowsu, Windows Serveru i Azure Files. Autor ovog teksta može da se zakune da je on već implementiran u novije verzije MS Teams, jer upravo scenario sa promenom mreža i konferencijskim razgovorom ne dovodi do prekida veze i korisniku daje ne samo sjajan komfor, već i osećaj slobode, da može da se slobodno kreće tokom komunikacije.

... koja je već počela

Verovatno ste čuli za OSI model računarskih mreža. Sa svojih sedam nivoa enkapsulacije on je formiran nekada davno, u vreme kada je internet već postojao. Tih sedam nivoa su se često, kao krugovi pakla, nadvijali i nad studentima i nad ljudima koji su pokušavali da objasne i sistematizuju sisteme koji su funkcionisali u praksi. Danas je sve više onih koji govore da je taj model prevaziđen i da nikada nije odgovarao pravom stanju stvari (i.sk.rs/358119). Možda je QUIC baš najbolji primer korenitih promena koje se dešavaju u mrežnom, internet i aplikativnom nivou nakon više decenija i možda će QUIC i zvanično poslati OSI model u penziju.

Ako vas je ova tematika dublje zainteresovala, predlažemo da pogledate video i pročitate knjigu Danijela Stenberga (i.sk.rs/358120), autora CURL. Materijal je star dve godine, alii nije ništa izgubio na aktuelnosti. Pogledajte i sajt IETF-ove radne grupe za CURL (quicvg.org), ali i dva sjajna bloga o http 3.0 (i.sk.rs/358121 i i.sk.rs/358122) kompanija Cloudfare i Kinsta, koje su među prvim pohitale da implementiraju http 3.0.