Više od 20 godina pregledavamo web stranice koristeći HTTP protokol. Većina korisnika uopće ne razmišlja o tome šta je to i kako funkcionira. Drugi znaju da negdje ispod HTTP-a postoji TLS, a ispod toga TCP, pod kojim je IP itd. A drugi - heretici - vjeruju da je TCP stvar prošlosti, oni žele nešto brže, pouzdanije i sigurnije. Ali u svojim pokušajima da izmisle novi idealni protokol, vratili su se tehnologiji 80-ih i na njoj pokušavaju da izgrade svoj hrabri novi svijet.
Malo istorije: HTTP/1.1
1997. protokol za razmjenu tekstualnih informacija HTTP verzija 1.1 dobio je vlastiti RFC. U to vrijeme, protokol su koristili pretraživači nekoliko godina, a novi standard je trajao još petnaest. Protokol je radio samo na principu zahtjev-odgovor i bio je namijenjen uglavnom za prijenos tekstualnih informacija.
HTTP je dizajniran da radi na vrhu TCP protokola, osiguravajući da se paketi pouzdano isporučuju na odredište. TCP radi tako što uspostavlja i održava pouzdanu vezu između krajnjih tačaka i razbija saobraćaj u segmente. Segmenti imaju svoj serijski broj i kontrolni zbroj. Ako iznenada jedan od segmenata ne stigne ili stigne s pogrešnim kontrolnim sumom, prijenos će se zaustaviti dok se izgubljeni segment ne vrati.
U HTTP/1.0, TCP veza je zatvorena nakon svakog zahtjeva. Ovo je bilo izuzetno rasipno, jer... uspostavljanje TCP veze (3-Way-Handshake) je spor proces. HTTP/1.1 je uveo mehanizam održavanja koji vam omogućava da ponovo koristite jednu vezu za više zahteva. Međutim, budući da lako može postati usko grlo, različite implementacije HTTP/1.1 dozvoljavaju otvaranje više TCP veza na isti host. Na primjer, Chrome i najnovije verzije Firefoxa dozvoljavaju do šest veza.
Enkripcija je također trebala biti prepuštena drugim protokolima, a za to je korišten TLS protokol preko TCP-a, koji je pouzdano štitio podatke, ali je dodatno povećao vrijeme potrebno za uspostavljanje veze. Kao rezultat toga, proces rukovanja počeo je izgledati ovako:
Ilustracija Cloudflare
Stoga je HTTP/1.1 imao niz problema:
- Sporo postavljanje veze.
- Podaci se prenose u tekstualnom obliku, što znači da je prijenos slika, video zapisa i drugih netekstualnih informacija neučinkovit.
- Jedna TCP veza se koristi za jedan zahtjev, što znači da drugi zahtjevi moraju ili pronaći drugu vezu ili čekati dok je trenutni zahtjev ne oslobodi.
- Podržan je samo model povlačenja. Ne postoji ništa u standardu o server-push-u.
- Naslovi se prenose u tekstu.
Ako se server-push barem implementira korištenjem WebSocket protokola, onda su ostali problemi morali biti riješeni radikalnije.
Malo modernosti: HTTP/2
Google je 2012. godine počeo raditi na protokolu SPDY (izgovara se "brzi"). Protokol je dizajniran da riješi glavne probleme HTTP/1.1 i istovremeno je trebao održavati kompatibilnost unatrag. 2015. godine radna grupa IETF-a uvela je HTTP/2 specifikaciju zasnovanu na SPDY protokolu. Evo razlika u HTTP/2:
- Binarna serijalizacija.
- Multipleksiranje više HTTP zahtjeva u jednu TCP vezu.
- Server-push iz kutije (bez WebSocket-a).
Protokol je bio veliki korak naprijed. On snažno i ne zahtijeva stvaranje više TCP veza: svi zahtjevi prema jednom hostu su multipleksirani u jedan. Odnosno, u jednoj vezi postoji nekoliko takozvanih tokova, od kojih svaki ima svoj ID. Bonus je upakovan server-push.
Međutim, multipleksiranje dovodi do još jednog ključnog problema. Zamislite da asinhrono izvršavamo 5 zahtjeva na jedan server. Kada koristite HTTP/2, svi ovi zahtjevi će se izvršavati unutar iste TCP veze, što znači da ako se jedan od segmenata bilo kojeg zahtjeva izgubi ili neispravno primi, prijenos svih zahtjeva i odgovora će se zaustaviti dok se izgubljeni segment ne završi restauriran. Očigledno, što je lošiji kvalitet veze, HTTP/2 radi sporije. , u uslovima kada izgubljeni paketi čine 2% svih paketa, HTTP/1.1 u pretraživaču radi bolje od HTTP/2 zbog činjenice da otvara 6 veza umesto jedne.
Ovaj problem se zove “head-of-line blocking” i, nažalost, nije moguće riješiti ga korištenjem TCP-a.
Ilustracija Daniel Steinberg
Kao rezultat toga, programeri HTTP/2 standarda su odradili odličan posao i uradili skoro sve što je moglo da se uradi na sloju aplikacije OSI modela. Vrijeme je da se spustimo na transportni sloj i izmislimo novi transportni protokol.
Potreban nam je novi protokol: UDP vs TCP
Vrlo brzo je postalo jasno da je implementacija potpuno novog protokola transportnog sloja nemoguć zadatak u današnjoj stvarnosti. Činjenica je da hardver ili srednja kutija (ruteri, firewall, NAT serveri...) znaju za transportni sloj, a naučiti ih nečemu novom je izuzetno težak zadatak. Pored toga, podrška za transportne protokole ugrađena je u jezgro operativnih sistema, a kerneli takođe nisu baš voljni da se menjaju.
I ovdje bi se moglo podići ruke i reći „Mi ćemo, naravno, izmisliti novi HTTP/3 sa preferencijama i kurtizanama, ali će trebati 10-15 godina da se implementira (nakon ovog vremena većina hardvera će biti zamijenjeno),” ali postoji još jedan ne tako Očigledna opcija je korištenje UDP protokola. Da, da, isti protokol koji smo koristili za prebacivanje datoteka preko LAN-a kasnih devedesetih i ranih XNUMX-ih. Gotovo sav današnji hardver može raditi s njim.
Koje su prednosti UDP-a u odnosu na TCP? Prije svega, nemamo sesiju transportnog sloja za koju hardver zna. To nam omogućava da sami odredimo sesiju na krajnjim tačkama i tamo riješimo konflikte. To jest, nismo ograničeni na jednu ili više sesija (kao u TCP-u), već možemo kreirati onoliko koliko nam je potrebno. Drugo, prijenos podataka putem UDP-a je brži nego preko TCP-a. Tako, u teoriji, možemo probiti trenutnu gornju granicu brzine postignutu u HTTP/2.
Međutim, UDP ne garantuje pouzdan prenos podataka. U stvari, mi jednostavno šaljemo pakete, nadajući se da će ih drugi kraj primiti. Niste primili? Pa, nema sreće... Ovo je bilo dovoljno za prijenos videa za odrasle, ali za ozbiljnije stvari vam je potrebna pouzdanost, što znači da morate umotati još nešto na UDP.
Kao i kod HTTP/2, rad na kreiranju novog protokola počeo je u Google-u 2012. godine, odnosno otprilike u isto vrijeme kada je počeo rad na SPDY. 2013. Jim Roskind se predstavio široj javnosti , a već 2015. godine uveden je Internet nacrt za standardizaciju u IETF. Čak iu to vrijeme, protokol koji je Roskind razvio u Guglu bio je veoma različit od standardnog, pa je Google verzija počela da se zove gQUIC.
Šta je QUIC
Prvo, kao što je već pomenuto, ovo je omotač preko UDP-a. QUIC veza se uzdiže iznad UDP-a, u kojem, po analogiji sa HTTP/2, može postojati nekoliko tokova. Ovi tokovi postoje samo na krajnjim tačkama i opslužuju se nezavisno. Ako dođe do gubitka paketa u jednom toku, to neće utjecati na druge.
Ilustracija Daniel Steinberg
Drugo, enkripcija se više ne implementira na zasebnom nivou, već je uključena u protokol. Ovo vam omogućava da uspostavite vezu i razmijenite javne ključeve u jednom rukovanju, a također vam omogućava da koristite pametni 0-RTT mehanizam rukovanja i općenito izbjegavate kašnjenja rukovanja. Osim toga, sada je moguće šifrirati pojedinačne pakete podataka. Ovo vam omogućava da ne čekate završetak prijema podataka iz toka, već da samostalno dešifrujete primljene pakete. Ovaj način rada općenito je bio nemoguć u TCP-u, jer TLS i TCP su radili nezavisno jedan od drugog, a TLS nije mogao znati na koje će dijelove TCP podaci biti isječeni. I stoga, nije mogao pripremiti svoje segmente tako da se uklapaju u TCP segmente jedan prema jedan i da se mogu samostalno dešifrirati. Sva ova poboljšanja omogućavaju QUIC-u da smanji kašnjenje u odnosu na TCP.
Treće, koncept svjetlosnog striminga omogućava vam da odvojite vezu od IP adrese klijenta. Ovo je važno, na primjer, kada se klijent prebaci s jedne Wi-Fi pristupne točke na drugu, mijenjajući svoju IP adresu. U ovom slučaju, kada se koristi TCP, dešava se dugotrajan proces tokom kojeg postojeće TCP veze isteknu i nove veze se kreiraju iz nove IP adrese. U slučaju QUIC-a, klijent jednostavno nastavlja da šalje pakete na server sa nove IP adrese sa starim ID-om toka. Jer ID toka je sada jedinstven i ne koristi se ponovo, server razumije da je klijent promijenio IP, ponovo šalje izgubljene pakete i nastavlja komunikaciju na novoj adresi.
Četvrto, QUIC se implementira na nivou aplikacije, a ne na nivou operativnog sistema. To vam, s jedne strane, omogućava da brzo izvršite izmjene u protokolu, jer Da biste dobili ažuriranje, samo trebate ažurirati biblioteku, umjesto da čekate novu verziju OS-a. S druge strane, to dovodi do snažnog povećanja potrošnje procesora.
I na kraju, naslovi. Kompresija zaglavlja jedna je od stvari koja se razlikuje između QUIC-a i gQUIC-a. Ne vidim smisao da se tome mnogo posvećuje, samo ću reći da je u verziji dostavljenoj za standardizaciju, kompresija zaglavlja napravljena što je moguće sličnija kompresiji zaglavlja u HTTP/2. Možete pročitati više .
Koliko je brži?
To je teško pitanje. Činjenica je da dok nemamo standard, nema šta posebno da se meri. Možda jedina statistika koju imamo je statistika iz Googlea, koji koristi gQUIC od 2013. i 2016. da oko 90% saobraćaja koji ide na njihove servere iz Chrome pretraživača sada koristi QUIC. U istoj prezentaciji navode da se stranice učitavaju oko 5% brže kroz gQUIC i da ima 30% manje mucanja u video streamingu u odnosu na TCP.
Grupa istraživača na čelu sa Arašom Molavijem Kakhkijem objavila je 2017 za proučavanje performansi gQUIC-a u poređenju sa TCP-om.
Studija je otkrila nekoliko slabosti gQUIC-a, kao što su nestabilnost miješanja mrežnih paketa, pohlepa (nepravednost) prema propusnosti kanala i sporiji prijenos malih (do 10 kb) objekata. Ovo posljednje se, međutim, može nadoknaditi korištenjem 0-RTT. U svim ostalim proučavanim slučajevima, gQUIC je pokazao povećanje brzine u odnosu na TCP. Ovdje je teško govoriti o konkretnim brojkama. Bolje čitaj ili .
Ovdje se mora reći da se ovi podaci posebno odnose na gQUIC i da nisu relevantni za standard koji se razvija. Šta će se dogoditi za QUIC: to je još uvijek tajna, ali postoji nada da će slabosti identificirane u gQUIC-u biti uzete u obzir i ispravljene.
Malo budućnosti: šta je sa HTTP/3?
Ali ovdje je sve kristalno jasno: API se neće promijeniti ni na koji način. Sve će ostati potpuno isto kao što je bilo u HTTP/2. Pa, ako API ostane isti, prijelaz na HTTP/3 će se morati riješiti korištenjem nove verzije biblioteke na pozadinskom dijelu koja podržava QUIC transport. Istina, morat ćete zadržati rezervnu verziju na starim verzijama HTTP-a neko vrijeme, jer Internet trenutno nije spreman za potpuni prelazak na UDP.
Ko već podržava
ovdje postojeće QUIC implementacije. Uprkos nedostatku standarda, lista nije loša.
Nijedan pretraživač trenutno ne podržava QUIC u produkcijskom izdanju. Nedavno su se pojavile informacije da je podrška za HTTP/3 uključena u Chrome, ali za sada samo u Canary.
Od backenda podržava samo HTTP/3 и , ali ipak eksperimentalno. NGINX krajem proljeća 2019 , da su počeli raditi na podršci za HTTP/3, ali je još nisu završili.
koji su problemi?
Vi i ja živimo u stvarnom svijetu, gdje nijedna velika tehnologija ne može doći do masa bez otpora, a QUIC nije izuzetak.
Najvažnije je da morate nekako objasniti pretraživaču da "https://" više nije činjenica da vodi do TCP porta 443. TCP možda uopće ne postoji. Za ovo se koristi zaglavlje Alt-Svc. Omogućava vam da kažete pretraživaču da je i ova web stranica dostupna na tom i tom protokolu na toj i takvoj adresi. U teoriji, ovo bi trebalo da funkcioniše kao šarm, ali u praksi ćemo naići na činjenicu da se UDP može, na primer, zabraniti na firewall-u kako bi se izbegli DDoS napadi.
Ali čak i ako UDP nije zabranjen, klijent može biti iza NAT rutera koji je konfiguriran da održava TCP sesiju putem IP adrese, a pošto koristimo UDP, koji nema hardversku sesiju, NAT neće zadržati vezu i QUIC sesiju .
Svi ovi problemi nastaju zbog činjenice da se UDP ranije nije koristio za prijenos Internet sadržaja, a proizvođači hardvera nisu mogli predvidjeti da će se to ikada dogoditi. Na isti način, administratori još uvijek ne razumiju kako pravilno konfigurirati svoje mreže da QUIC radi. Ova situacija će se postepeno mijenjati i, u svakom slučaju, takve promjene će trajati manje vremena od implementacije novog protokola transportnog sloja.
Osim toga, kao što je već opisano, QUIC uvelike povećava korištenje CPU-a. Daniel Stenberg rast procesora do tri puta.
Kada će HTTP/3 stići?
Standard do maja 2020. godine, ali s obzirom na to da dokumenti predviđeni za jul 2019. ostaju nedovršeni u ovom trenutku, možemo reći da će datum najvjerovatnije biti pomjeren.
Pa, Google koristi svoju gQUIC implementaciju od 2013. godine. Ako pogledate HTTP zahtjev koji je poslan Google tražilici, vidjet ćete ovo:
nalazi
QUIC sada izgleda kao prilično gruba, ali vrlo obećavajuća tehnologija. S obzirom da su se u proteklih 20 godina sve optimizacije protokola transportnog sloja ticale uglavnom TCP-a, QUIC, koji u većini slučajeva ima najbolje performanse, već izgleda izuzetno dobro.
Međutim, još uvijek postoje neriješeni problemi koji će se morati rješavati u narednih nekoliko godina. Proces može biti odložen zbog činjenice da je u pitanju hardver koji niko ne voli da ažurira, ali ipak svi problemi izgledaju sasvim rješivi i prije ili kasnije svi ćemo imati HTTP/3.
Budućnost je iza ugla!
izvor: www.habr.com
