Već više od 20 godina pregledavamo web stranice putem HTTP protokola. Većina korisnika uopće ne razmišlja o tome što to zapravo jest i kako to funkcionira. Drugi znaju da se negdje ispod HTTP-a nalaze TLS, a ispod njega TCP, a ispod TCP-a IP i tako dalje. A treći – heretici – smatraju da je TCP prošlost, žele nešto brže, pouzdanije i sigurnije. No, u svojim pokušajima da izume novi idealan protokol, vratili su se tehnologijama iz 80-ih godina i pokušavaju na njima izgraditi svoj divni novi svijet.
Malo povijesti: HTTP/1.1
Godine 1997. godine protokol za razmjenu tekstualnih informacija HTTP verzije 1.1 dobio je svoj RFC. U to vrijeme protokol su koristili preglednici već nekoliko godina, a novi standard trajao je još petnaest. Protokol je radio isključivo prema principu zahtjev-odgovor i bio je namijenjen, prije svega, za prijenos tekstualnih informacija.
HTTP je projektiran za rad preko TCP protokola, koji jamči pouzdanu isporuku paketa do odredišta. Rad TCP-a temelji se na uspostavljanju i održavanju pouzdane veze između krajnjih točaka i dijeljenju prometa na segmente. Segmenti imaju svoj redni broj i kontrolnu sumu. Ako iznenada neki od segmenata ne dođe ili dođe s netočnom kontrolnom sumom, prijenos će se zaustaviti dok se ne obnovi izgubljeni segment.
U HTTP/1.0 TCP veza se zatvarala nakon svake zahtjeva. To je bilo izuzetno rasipno, jer uspostava TCP veze (3-Way-Handshake) nije brz proces. U HTTP/1.1 uveden je mehanizam keep-alive, koji omogućava ponovno korištenje jedne veze za više zahtjeva. Međutim, s obzirom na to da to može lako postati usko grlo, u različitim implementacijama HTTP/1.1 dopušteno je otvaranje više TCP veza prema jednom hostu. Na primjer, u Chromeu i najnovijim verzijama Firefoxa dopušteno je do šest veza.
Šifriranje se također predložilo prepustiti drugim protokolima, i za to je preko TCP-a počeo koristiti protokol TLS, koji je dovoljno pouzdano štitio podatke, ali je dodatno povećavao vrijeme potrebno za uspostavu veze. Na kraju, proces rukovanja postao je ovakav:
Ilustracija Cloudflare
Tako je HTTP/1.1 imao niz problema:
- Sporo uspostavljanje veze.
- Podaci se prenose u tekstualnom formatu, što znači da prenos slika, videa i druge netextualne informacije nije efikasan.
- Jedna TCP veza se koristi za jedan zahtev, što znači da ostali zahtevi moraju ili pronaći drugu vezu ili čekati dok trenutni zahtev ne završi.
- Podržava se samo pull model. U standardu nema ništa o server-push.
- Zaglavlja se prenose kao tekst.
Ako se server-push nekako implementira putem WebSocket protokola, ostale probleme trebalo je rešavati radikalnije.
Malo savremenosti: HTTP/2
2012. godine je unutar Googlea započet rad na SPDY protokolu (izgovara se „spidi“). Protokol je trebao rešiti glavne probleme HTTP/1.1 i istovremeno zadržati unazadne kompatibilnosti. Godine 2015. radna grupa IETF je predstavila specifikaciju HTTP/2, baziranu na SPDY protokolu. Evo koje su razlike bile u HTTP/2:
- Binarna serijalizacija.
- M multiplexiranje više HTTP zahteva u jednu TCP vezu.
- Server-push iz kutije (bez WebSocket).
Protokol je postao veliki korak napred. Znatno i ne zahteva stvaranje više TCP veza: svi zahtevi prema jednom hostu se multiplexiraju u jednu. To znači da u jednoj vezi postoji nekoliko takozvanih strimova, svaki sa svojim ID-om. Bonus dolazi u obliku kutijastog server-push.
Međutim, multiplexiranje dovodi do drugog temeljnog problema. Zamislite da asinhrono izvršavamo 5 zahteva prema jednom serveru. Pri korišćenju HTTP/2, svi ovi zahtevi će se izvršavati u okviru jedne TCP veze, što znači da, ako jedan od segmenata bilo kojeg zahteva izgubi ili stigne neispravno, prenos svih zahteva i odgovora će se zaustaviti dok se izgubljeni segment ne obnovi. Očigledno je da što je kvalitet veze lošiji, HTTP/2 radi sporije. , u uslovima kada izgubljeni paketi čine 2% ukupnog, HTTP/1.1 u pregledniku pokazuje bolje rezultate od HTTP/2 jer otvara 6 veza, a ne jednu.
Ovaj problem se naziva „head-of-line blocking“ i, nažalost, nije moguće rešiti ga korišćenjem TCP-a.
Ilustracija Daniel Steinberg
Kao rezultat, developeri HTTP/2 standarda su odradili ogroman posao i učinili gotovo sve što se moglo postići na aplikacijskom nivou OSI modela. Došlo je vreme da se spustimo na transportni nivo i izumimo novi transportni protokol.
Potrebna nam je nova protokol: UDP vs TCP
Relativno brzo je postalo jasno da je implementacija potpuno novog transportnog protokola u današnjim okvirima zadatak koji je teško izvesti. Stvar je u tome što o transportnom nivou znaju hardver ili srednji uređaji (ruter, vatrozid, NAT serveri...), a poučiti ih nečemu novom izuzetno je složeno. Pored toga, podrška za transportne protokole je ugrađena u jezgro operativnih sistema, a jezgra se ne menjaju baš lako.
I ovde bismo mogli da odustanemo i kažemo: „Naravno, izumet ćemo novi HTTP/3 sa favoritima i kurtizanama, ali implementirati će biti potrebno 10-15 godina (otprilike toliko vremena će proći pre nego što se većina hardvera zameni)”, ali postoji još jedna, ne tako očigledna opcija: koristiti UDP protokol. Da, da, taj isti protokol kojim smo razmenjivali fajlove po lokalnoj mreži krajem devedesetih i početkom dvehiljaditih. Gotovo svi današnji hardveri znaju kako da rade s tim.
Koje su prednosti UDP-a u odnosu na TCP? Prvo, nemamo sesiju transportnog nivoa o kojoj hardver zna. To nam omogućava da sami definišemo sesiju na krajnjim tačkama i tamo rešavamo eventualne konflikte. Dakle, nismo ograničeni na jednu ili nekoliko sesija (kao kod TCP-a), već možemo kreirati koliko god sesija nam je potrebno. Drugo, prenos podataka putem UDP-a je brži nego putem TCP-a. Tako da, u teoriji, možemo probiti današnji brzinski plafon postignut u HTTP/2.
Međutim, UDP ne garantuje pouzdanost prenosa podataka. U suštini, jednostavno šaljemo pakete, nadajući se da će ih na drugom kraju primiti. Nisu ih primili? Pa, nije nam išlo. Ovoga je bilo dovoljno za prenos videa za odrasle, ali za ozbiljnije stvari potrebna je pouzdanost, što znači da ćemo morati dodati nešto dodatno preko UDP-a.
Kao i u slučaju HTTP/2, rad na stvaranju novog protokola započeo je u Googleu 2012. godine, otprilike u vreme kada je započet rad na SPDY-u. Godine 2013. Jim Roskind je predstavio javnosti , a već 2015. godine je podnesen Internet Draft za standardizaciju u IETF-u. Već u to vrijeme, protokol koji je razvio Roskind u Googleu značajno se razlikovao od onoga koji je ponuđen za standardizaciju, pa se googleova verzija počela zvati gQUIC.
Što je QUIC
Prvo, kao što je već spomenuto, to je omotač nad UDP-om. Iznad UDP-a se uspostavlja QUIC-connection, u kojem, slično HTTP/2, mogu postojati više streamova. Ovi streamovi postoje samo na krajnjim točkama i obrađuju se neovisno. Ako dođe do gubitka paketa u jednom streamu, ostali to neće ni na koji način utjecati.
Ilustracija Daniel Steinberg
Drugo, enkripcija je sada implementirana ne kao odvojeni sloj, već uključena u protokol. To omogućuje uspostavljanje veze i razmjenu javnih ključeva u jednom rukovanju, kao i korištenje pametnog mehanizma 0-RTT handshake, što uopće omogućuje izbjegavanje kašnjenja tijekom rukovanja. Osim toga, sada je moguće enkriptirati pojedinačne pakete podataka. To omogućuje da se ne čeka završetak prijema podataka iz streama, već da se primljeni paketi dešifriraju neovisno. Ovakav način rada bio je potpuno nemoguć u TCP-u, jer su TLS i TCP radili neovisno jedno o drugome, a TLS nije mogao znati na koje dijelove će TCP razbijati podatke. Stoga nije mogao pripremiti svoje segmente kako bi se oni poklapali s TCP segmentima jedan na jedan i mogli biti dešifrirani neovisno. Sva ta poboljšanja omogućuju QUIC-u smanjenje latencije u usporedbi s TCP-om.
Treće, koncept laganih streamova omogućuje odvajanje veze od IP adrese klijenta. To je važno, na primjer, kada se klijent prebacuje s jedne Wi-Fi točke na drugu, mijenjajući svoj IP. U ovom slučaju, prilikom korištenja TCP-a, dolazi do dugog procesa, tijekom kojeg postojeće TCP veze propadaju zbog isteka vremena i stvaraju se nove veze s novim IP-om. U slučaju QUIC-a, klijent jednostavno nastavlja slati pakete poslužitelju s novog IP-a sa starim ID-em streama. Budući da je ID streama sada jedinstven i ne ponovo se koristi, poslužitelj shvaća da je klijent promijenio IP, šalje izgubljene pakete i nastavlja komunikaciju na novoj adresi.
Četvrto, QUIC se implementira na razini aplikacije, a ne operativnog sustava. S jedne strane, to omogućuje brže promjene protokola, jer je dovoljno ažurirati biblioteku umjesto da se čeka nova verzija OS-a. S druge strane, to dovodi do značajnog povećanja potrošnje procesora.
Za kraj, naslovi. Kompresija naslova je jedan od elemenata koji se razlikuju u QUIC-u i gQUIC-u. Ne vidim smisao posvećivati tome previše vremena, reći ću samo da je u verziji koja je podnesena za standardizaciju, kompresija naslova učinjena što sličnijom kompresiji naslova u HTTP/2. Više se može pročitati .
Koliko je brži?
To je složeno pitanje. Naime, još nemamo standard, pa nema puno toga za mjerenje. Možda su jedini statistički podaci koji imamo – podaci Googlea, koji koristi gQUIC od 2013. godine i 2016. , da oko 90% prometa koji ide do njihovih servera iz preglednika Chrome sada koristi QUIC. U istoj prezentaciji navode da se putem gQUIC-a stranice učitavaju otprilike 5% brže, a kod streaminga video sadržaja na 30% manje zamrzavanja u usporedbi s TCP-om.
U 2017. godini grupa istraživača predvođena Arashom Molavi Kakhkijem objavila je o usporedbi performansi gQUIC-a i TCP-a.
Istraživanje je otkrilo nekoliko slabosti gQUIC-a, poput nestabilnosti na miješanju mrežnih paketa, nepoštenja u propusnosti kanala i sporiju prijenos malih (do 10 kB) objekata. Posljednje se, međutim, može nadoknaditi korištenjem 0-RTT. U svim ostalim ispitivanim slučajevima gQUIC je pokazao porast brzine u usporedbi s TCP-om. O konkretnim brojkama ovdje je teško govoriti. Bolje je pročitati ili .
Ovdje treba napomenuti da su to podaci isključivo o gQUIC-u, i oni nisu aktualni za razvijeni standard. Što će biti za QUIC: još uvijek je tajna, ali postoji nada da će slabosti uočene kod gQUIC-a biti uzete u obzir i ispravljene.
Malo o budućnosti: što je s HTTP/3?
Evo ovdje je sve kristalno jasno: API se nikako neće promijeniti. Sve će ostati onako kako je bilo u HTTP/2. Ako API ostaje isti, prijelaz na HTTP/3 trebat će se rješavati korištenjem nove verzije biblioteke na backendu koja podržava transport preko QUIC-a. Međutim, još će dugo trebati zadržati fallback na stare verzije HTTP-a, jer internet trenutno nije spreman za puni prijelaz na UDP.
Tko već podržava
Evo postojeće implementacije QUIC-a. Unatoč nedostatku standarda, popis je solidan.
Nitko od preglednika trenutno ne podržava QUIC u produkcijskoj verziji. Nedavno je bilo informacija da je Chrome uključio podršku za HTTP/3, ali trenutno samo u Canary verziji.
Od backendova, HTTP/3 podržava samo i , ali još uvijek eksperimentalno. NGINX je krajem proljeća 2019. godine , da su počeli raditi na podršci za HTTP/3, ali još nisu završili.
Koji su problemi
Živimo u stvarnom svijetu, gdje nijedna velika tehnologija ne može proći u mase bez susretanja otpora, a QUIC nije iznimka.
Najvažnije je objasniti pregledniku da "https://" sada ne znači nužno da vodi na 443. TCP port. Tamo možda uopće nema TCP-a. Za to se koristi Alt-Svc zaglavlje. Ono omogućava obavijestiti preglednik da je ova web stranica također dostupna na određenom protokolu na određenoj adresi. U teoriji, to bi trebalo funkcionirati besprijekorno, ali u praksi ćemo se susresti s time da UDP može biti, na primjer, zabranjen na vatrozidu kako bi se spriječili DDoS napadi.
Ali čak i ako UDP nije zabranjen, klijent može biti iza NAT usmjerivača koji je konfiguriran za održavanje TCP sesije po IP adresi, a budući da koristimo UDP, koji nema hardversku sesiju, NAT neće održavati vezu, i QUIC sesija .
Svi ovi problemi vezani su uz činjenicu da UDP prije nije korišten za prijenos internet sadržaja, i proizvođači hardvera nisu mogli predvidjeti da će se nešto takvo ikada dogoditi. Slično tome, administratori još uvijek ne razumiju najbolje kako ispravno konfigurirati svoje mreže za rad s QUIC-om. Ova situacija će se polako mijenjati, i u svakom slučaju, slične promjene trajat će manje vremena nego implementacija novog transportnog protokola.
Osim toga, kao što je već opisano, QUIC značajno povećava korištenje procesora. Daniel Stenberg rast korištenja procesora do tri puta.
Kada će doći HTTP/3
Standard do svibnja 2020. godine, no s obzirom na to da su trenutno nedovršeni dokumenti planirani za srpanj 2019., može se reći da će datum vjerojatno biti odgođen.
Google svoju implementaciju gQUIC koristi još od 2013. godine. Ako pogledamo HTTP zahtjev koji se šalje Google pretraživaču, možemo vidjeti ovo:
Zaključci
QUIC trenutno izgleda kao prilično sirova, ali vrlo perspektivna tehnologija. S obzirom na to da se posljednjih 20 godina sve optimizacije transportnih protokola uglavnom tiču TCP-a, QUIC, koji u većini slučajeva pobjeđuje po performansama, već sada izgleda prilično dobro.
Međutim, još uvijek postoje neriješeni problemi s kojima ćemo se morati suočiti u sljedećih nekoliko godina. Proces bi se mogao odužiti zbog opreme koja se ne voli ažurirati, no sve probleme izgledaju rješivo, i prije ili kasnije svi ćemo imati HTTP/3.
Budućnost nije daleko!
Izvor: habr.com
