Šta nam donosi HTTP/3

18 фебруара, 2020

Od kada je u novembru 2018 IETF predložio novi Internet nacrt po kojem QUIC protokol treba da bude preimenovan u HTTP/3, u stručnoj javnosti je sve više počelo da se pominje ime HTTP/3 protokola.

Šta je to HTTP/3 i šta nam to novo donosi u odnosu na HTTP/2?

Pre svega važno je pojasniti da je HTTP/3 za sada još uvek u fazi razvoja i čini se da nije još na pomolu njegova definitivna standardizacija. U principu radi se o novoj verziji HTTP protokola koja se za razliku od prethodnih verzija, koje su bile zasnovane na TCP protokolu, zasniva na UDP protokolu. Mogao bi se ukratko definisati kao treća verzija HTTP protokola koji je prethodno bio poznat kao HTTP-over-QUIC.

QUIC (Quick Internet UDP Connections) je inicijalno razvijen od strane Google-a i praktično je naslednik HTTP/2 protokola. Kompanije kao što su Google i Facebook su već koristile QUIC kako bi ubrzale Internet.

Kratka istorija HTTP protokola

HTTP je danas opšteprihvaćen i najzastupljeniji protokol aplikativnog sloja na Internetu. Njegov razvoj u protokol savremenog doba započinje ne tako davne 1991. godine kada se pojavila verzija HTTP/0.9.

Gledano sa današnje tačke gledišta ovo je bio i ostao prilično jednostavan protokol. Zahtev od klijenta prema serveru se sastoji od jedne linije: GET metode i putanje ka traženom dokumentu. Nema zaglavlja ili bilo kojih drugih metapodataka – samo HTML dokument.

U periodu od 1991. do 1995. je došlo do ubrzanog razvoja HTML specifikacije. Javlja se veća potreba za korišćenjem Interneta od strane običnih korisnika, pa dolazi i do ubrzanog razvoja pretraživača. U takvim uslovima se nameće potreba za unapređenjem postojeće verzije HTTP protokola (HTTP/0.9), pa se javlja verzija HTTP/1.0, a nakon toga već 1997. i prva naredna standardizovana verzija pod nazivom HTTP/1.1.

Ova verzija je donela dosta značajnih promena i rešava neke nedostatke i ograničenja prethodne verzije: neki od njih su recimo keep-alive konekcija i dodatni mehanizmi keširanja podataka.

Sledeća verzija je bila HTTP/2.

Malo o HTTP/2

Kao što je poznato HTTP/2 je u ovoj verziji nastao na osnovu eksperimentalnog SPDY protokola koji je razvijen od strane Google-a. Nasledio je prethodnu veliku verziju HTTP/1.1. Standardizacija HTTP/2 je obavljena 2015. i od tada počinje postepena implementacija na web-u. Naredne godine je pokrivao nekih 7-9% Interneta, da bi 2019. ovaj broj porastao na nekih 35-40%. U pitanju je protokol koji je još uvek u fazi usvajanja od strane web-a i sigurno će proći još dosta vremena dok ne bude u većini prihvaćen.

Jedna od velikih novina koje nam je doneo HTTP/2 u odnosu na svoje prethodnike je sposobnost da po jednoj TCP konekciji distribuira više paketa različitih sadržaja. To je takozvano multipleksiranje (multiplexing).

Svaki zahtev dodeljuje se posebnom toku, a tokovi se multipleksiraju preko zajedničke TCP konekcije. U ovom slučaju zahtevi nemaju međusobni uticaj, dok server simultano odgovara na njih. Pored rešavanja problema blokiranja zahteva, redukovan je broj TCP konekcija.

Multipleksiranje

Slika 1

Na slici 1 je prikazana razlika između načina prenosa paketa u verziji HTTP/1.1 i verziji HTTP/2, gde je slikovito prikazan način transporta. Činjenica je da se multipleksiranjem značajno optimizuje rad veb-servera i skraćuje vreme prenosa paketa/sadržaja, što svakako ide u prilog HTTP/2.

Još jedna značajna novina koju nam je doneo HTTP/2 jeste server push funkcija Najznačajnije poboljšanje koje donosi HTTP/2 ogleda se u server push funkciji (slika 2).

Ovo zapravo znači da ukoliko klijent zahteva određeni resurs, server može predvideti prateće resurse i proslediti ih klijentu bez prethodnih zahteva. Ova funkcija uvodi značajnu kompleksnost u procedure podešavanja i održavanja, međutim značajno smanjuje vreme odziva, odnosno vreme učitavanja veb-stranice.

Server Push

Slika 2

Na primeru na slici 2 vidimo da je klijent zahtevao HTML stranicu, koju mu je server ujedno isporučio, ali je uz nju isporučio i CSS i PNG file koje klijent nije tražio. Kao što smo pomenuli, time se značajno štedi na vremenu učitavanja sadržaja sa servera, što na kraju ima za rezultat biolje korisničko iskustvo na klijentskoj strani.

Postoji još dosta novina koje je HTTP/2 doneo, ali se njima nećemo detaljnije baviti u ovom tekstu. Za više informacija na ovu temu možete pogledati tekst ovde.

HTTP/3

Glavno pitanje koje se nameće pri pominjanju HTTP/3 jeste da li nam je on u ovom trenutku zaista potreban i koje nam sve novine donosi u odnosu na HTTP/2.

Pre svega da se kratko osvrnemo na glavne razlike između ove dve verzije protokola.

HTTP/2 je baziran na TCP protokolu, dok je HTTP/3 baziran na UDP protokolu. U pitanju su dva različita koncepta/protokola prenosa paketa podataka. TCP je uređeni prenos koji je zasnovan na kontroli tog prenosa, odnosno ukoliko tokom prenosa dođe do gubitka nekog paketa, taj paket odmah mora biti ponovo poslat na odredište. Tom prilikom se zaustavlja dalji prenos preostalih paketa, dok se ponovo ne isporuči paket koji je izgubljen. Na taj način se prilikom eventualnih gubitaka paketa, nešto produžava njihov prenos.

Za razliku od TCP protokola, UDP nema takvu vrstu kontrole i zbog toga je previđeno da se ona vrši u aplikativnom sloju. To znači da je na ovom nivou prepuštena kontrola koju će biti vršena na aplikativnom nivou i moći će da bude primenjena u skladu sa konkretnim situacijama tokom prenosa. To implicira da uz dobru implementaciju na aplikativnom nivou, UDP može biti brži od TCP-a jer ne postoji latencija u slučaju gubitka paketa.

HTTP/3 je baziran na QUIC protokolu/transportnom sloju koji je inicijalno razvio Google, a kasnije unapredio IEFT. Ta verzija se razlikuje od Google-ove verzije, ali je zadržala i dosta originalnih funkcionalnosti koje su kao takve ugrađene u temelje HTTP/3.

Slika 3 prikazuje neke osnovne razlike između HTTP/2 i HTTP/3.

HTTP2 vs HTTP3

Slika 3

Važno je napomenuti da se HTTP/3 u dobroj meri oslanja na TLS 1.3 i kao takav stoji u prilično zavisnom odnosu od njega.

HTTP/3 podrazumeva enkripciju koju praktično radi na TLS-u, ali ga direktno ne koristi. Jedan od glavnih izazova u implementaciji HTTP/3 su TLS/SSL biblioteke koje je trebalo izmeniti da bi se dodale nove funkcionalnosti vezane za samu enkripciju. Ova promena je bila neophodna jer se HTTP/3 razlikuje od HTTPS-a u delu onoga što se zapravo enkriptuje. U starijom verzijama HTTPS-a enkriptuju TLS-om, dok transportni metapodaci ostaju vidiljivi. U HTTP/3 i podaci i transportni metapodaci su zaštićeni. Ovo je svakako funkcionalnost koja osim dodatne sigurnosti, donosi i bolje performanse samog protokola.

ALT-SVC je funkcionalnost koja serveru omogućava da definiše putanju za pretraživač preko koje će ga uputiti na alternativni server gde mu može isporučiti isti sadržaj/resurse preko drugog protokola. Drugim rečima, server koji radi na HTTP/2 protokolu može u hederu zahteva poslati sadržaj pretraživaču i dati mu informaciju da isti sadržaj/resursi postoje i na HTTP/3 i uputiti ga na određeni port za tu namenu.

Podrška za HTTP/3 je trenutno ugrađena u Chrome i Firefox, pa iako nemaju zvaničnu podršku, ona može biti omogućena u oba pretraživača.

Prednosti i nedostaci HTTP/3

Možemo slobodno reći da HTTP/3 donosi dosta prednosti u odnosu na HTTP/2, ali i dosta izazova koje u ovom trenutku možemo smatrati kao njegove privremene nedostatke. Verujemo da će ti nedostaci vremenom biti prevaziđeni, jer u svojoj osnovi HTTP/3 ima više potencijala da i u praksi nadogradi i postepeno i zameni HTTP/2. Slika 4 prikazuje neke osnovne prednosi i nedostatke. Nećemo ih detaljno razmatrati, ali ćemo pomenuti i pojasniti neke od njih.

HTTP3 pros cons

Slika 4

Zbog načina na koji funkcioniše HTTP/3 realno može postići 0-RTT (zero round trip time resumption). Radi se zapravo o novini koja nam dolazi sa TLS 1.3 i podrazumeva da klijent može započeti prenos podataka (HTTP zahtev) i bez da je prethodno uspostavljen handshake. Na taj način se smanjuje latencija prilikom uspostavljanja nove konekcije. Slika 5.

HTTPS preko QUIC

Slika 5

Na taj način se vreme može smanjiti na čak 100 ms u slučaju prvog uspostavljanja konekcije sa serverom, odnosni 0 ms u slučaju da je ta konekcija prethodno već bila uspostavljena. U poređenju sa vremenom koje je potrebno TLS-u preko TCP protokola, to predstavlja značajnu uštedu u uspostavljanju konekcije.

Nećemo detaljnije pričati na temu TLS 1.3 s obzirom da se radi o protokolu koji zahteva jedan poseban tekst. Ukoliko vas zanima više detalja na ovu temu možete ih pronaći ovde.

Takođe, više informacija na temu QPACK kompresije možete pronaći ovde. Poseban tekst na temu Header-line Block-a (HOL) mođete pronaći u već pomenutom tekstu ovde. Ukoliko više preferirate video, toplo preporučujemo da pogledate snimak prezentacije našeg kolege Dragutina Ćirkovića sa prošlogodišnje Developer’s mDay konferencije.

Ono što je svakako zanimljivo pomenuti je da HTTP/3 za tranpost paketa korisiti primarno Connection ID, koji predstavlja identifikator određene konekcije. To znači da je Connection ID najvažniji prilikom prihvatanja zahteva od strane servera. Više nije bitno sa koje IP adrese ili preko kog rutera dolazi zahtev, već je najvažnije da on dolazi sa određenim Connection ID-em.

U praksi to znači da ukoliko preuzimate sadržaj prenosom podataka neke stranice sa svog mobilnog telefona i tokom prenosa podataka dođe do prebacivanja konekcije sa prenosa podataka na Wi-Fi, server će nastaviti da šalje podatke klijentu koji ima taj jedinstven Connection ID. U konkretnom slučaju to znači da bi vaš telefon nastavio sa preuzimanjem sadržaja, jer bi mu ih server zbog tog Connection ID-a nesmetano isporučio i nakon prekida konekcije i prebacivanja na drugi tip konekcije/ruter.

HTTP/3 server push je sličan onome što je već opisano u HTTP/2, ali koristi drugačije mehanizme.

U neku ruku možemo ga smatrati odgovorom servera na zahtev koji klijent nikada nije poslao. Važno je napomenuti da je ova funkcionalnost dozvoljena samo ako se klijent prethodno saglasio sa tim. HTTP/3 čak propisuje i maksimalni broj server push odgovora koje server može poslati klijentu. Ukoliko sever prekorači taj broj, to će izazvati grešku u konekciji.

Iako ova funkcionalnost može u nekim slučajevima može biti veroma korisna, sa druge strane se smatra i potencijalno problematičnom. Glavni razlog tome je što i pored uštede na nivou zahtev-odgovor ipak nosi određeni minus na strani povećanja protoka. Na stranu činjenica da je gotovo nemoguće za server da uvek zna koji će resurs/sadržaj konkretno biti zatražen od strane klijenta, što može da prouzrokuje nepotrebno slanje sadržaja i gubljenje mrežnih resursa.

Sa druge strane, neki od glavnih izazova i nedostataka HTTP/3 su svakako na strani mrežne HW i SW infrastrukture. S obzirom da jedna konekcija može biti uspostavljena preko velikog broja rutera,  firewall-ova, veb-servera i proxy-a i teško je pretpostaviti da u ovom trenutku svi oni mogu biti kompatibilni sa HTTP/3 protokolom.

Šta više, veliki broj ovih uređaja radi na različitim platformama koje su u najvećoj meri optimizovane za HTTP/1.1 i HTTP/2, što bi u slučaju prelaska na HTTP/3 pre svega zahtevalo njihovu prekonfiguraciju ili u većini slučajeva čak i zamenu. Ovo nikako ne ide u prilog brzoj implementaciji HTTP/3 i vrlo je verovatno da će upravo to biti najveći izazov sa kojim će HTTP/3 morati da se suoči.

Pored toga tu je i nestandardizovan pristup mnogih ISP-a kada je u pitanju UDP protokol. S obzirom da on nema baš dobru reputaciju po pitanju sigurnosti, neke kompanije ga jednostavno blokiraju kako bi izbegle sigurnosne probleme na mreži. To sa druge strane otvara i pitanje dodatne standardizacije UDP-a i uređaja koji bi radili na ovom protokolu.

Sve ovo navodi na zaključak da i pored očiglednih prednosti, HTTP/3 ima i značajne nedostatke pre svega na strani implementacije protokola na postojeću infrastrukturu. To će sigurno usporiti njegov ulazak na web, ali će sigurno i podstaći pronalaženje rešenja koja bi omogućila da u budućnosti postane opšteprihvaćeni veb standard.

Bez komentara

Оставите одговор

Ваша адреса е-поште неће бити објављена. Неопходна поља су означена *

mCloud mailing lista
Da li želiš da se prijaviš na mCloud mailing listu i svake nedelje dobijaš informacije o našim tekstovima na blogu i novostima iz mCloud-a?
Nemoj više prikazivati