Že več kot 20 let si ogledujemo spletne strani po protokolu HTTP. Večina uporabnikov sploh ne pomisli, kaj je to in kako deluje. Drugi vedo, da je nekje pod HTTP TLS, pod tem pa TCP, pod tem pa IP itd. Spet drugi - krivoverci - verjamejo, da je TCP preteklost; hočejo nekaj hitrejšega, zanesljivejšega in varnejšega. Toda v svojih poskusih, da bi iznašli nov idealen protokol, so se vrnili k tehnologiji iz 80. let in poskušajo na njej zgraditi svoj pogumni novi svet.
Malo zgodovine: HTTP/1.1
Leta 1997 je protokol za izmenjavo besedilnih informacij HTTP različice 1.1 pridobil svoj RFC. Takrat so brskalniki protokol uporabljali že nekaj let, novi standard pa je zdržal še petnajst. Protokol je deloval samo po principu zahteva-odgovor in je bil namenjen predvsem prenosu besedilnih informacij.
HTTP je bil zasnovan za delovanje na vrhu protokola TCP, kar zagotavlja, da so paketi zanesljivo dostavljeni na cilj. TCP deluje tako, da vzpostavi in vzdržuje zanesljivo povezavo med končnimi točkami in razdeli promet na segmente. Segmenti imajo svojo serijsko številko in kontrolno vsoto. Če nenadoma eden od segmentov ne prispe ali prispe z napačno kontrolno vsoto, se bo prenos ustavil, dokler se izgubljeni segment ne obnovi.
V HTTP/1.0 je bila povezava TCP zaprta po vsaki zahtevi. To je bilo izjemno potratno, ker ... vzpostavljanje povezave TCP (3-Way-Handshake) je počasen proces. HTTP/1.1 je uvedel mehanizem Keep-alive, ki omogoča ponovno uporabo ene povezave za več zahtev. Ker pa lahko zlahka postane ozko grlo, različne izvedbe HTTP/1.1 omogočajo odpiranje več povezav TCP z istim gostiteljem. Na primer, Chrome in novejše različice Firefoxa omogočajo do šest povezav.
Šifriranje naj bi bilo prepuščeno tudi drugim protokolom, za to pa je bil uporabljen protokol TLS preko TCP, ki je podatke zanesljivo zaščitil, a še dodatno podaljšal čas vzpostavitve povezave. Posledično je postopek rokovanja začel izgledati takole:
Ilustracija Cloudflare
Tako je imel HTTP/1.1 številne težave:
- Počasna nastavitev povezave.
- Podatki se prenašajo v besedilni obliki, kar pomeni, da je prenos slik, video posnetkov in drugih nebesedilnih informacij neučinkovit.
- Ena povezava TCP se uporablja za eno zahtevo, kar pomeni, da morajo druge zahteve najti drugo povezavo ali počakati, da jo trenutna zahteva sprosti.
- Podprt je samo model pull. V standardu ni ničesar o strežniku.
- Naslovi se prenašajo v besedilu.
Če je strežnik-push vsaj implementiran s protokolom WebSocket, je bilo treba preostale težave reševati bolj radikalno.
Malo modernosti: HTTP/2
Leta 2012 je Google začel delati na protokolu SPDY (izgovorjeno »speedy«). Protokol je bil zasnovan za reševanje glavnih težav HTTP/1.1 in naj bi hkrati ohranil združljivost za nazaj. Leta 2015 je delovna skupina IETF predstavila specifikacijo HTTP/2, ki temelji na protokolu SPDY. Tukaj so razlike v HTTP/2:
- Binarna serializacija.
- Multipleksiranje več zahtev HTTP v eno povezavo TCP.
- Potiskanje strežnika iz škatle (brez WebSocket).
Protokol je bil velik korak naprej. On močno in ne zahteva ustvarjanja več povezav TCP: vse zahteve enemu gostitelju so multipleksirane v enega. To pomeni, da je v eni povezavi več tako imenovanih tokov, od katerih ima vsak svoj ID. Bonus je potisni strežnik v škatli.
Vendar pa multipleksiranje vodi do druge ključne težave. Predstavljajte si, da asinhrono izvajamo 5 zahtev enemu strežniku. Pri uporabi HTTP/2 bodo vse te zahteve izvedene znotraj iste povezave TCP, kar pomeni, da če se eden od segmentov katere koli zahteve izgubi ali prejme nepravilno, se prenos vseh zahtev in odgovorov ustavi, dokler izgubljeni segment ni obnovljeno. Očitno je, da slabša kot je kakovost povezave, počasneje deluje HTTP/2. , v pogojih, kjer izgubljeni paketi predstavljajo 2 % vseh paketov, HTTP/1.1 v brskalniku deluje bolje kot HTTP/2 zaradi dejstva, da odpre 6 povezav namesto ene.
Ta težava se imenuje "blokiranje glave vrstice" in je na žalost ni mogoče rešiti z uporabo TCP.
Ilustracije Daniel Steinberg
Posledično so razvijalci standarda HTTP/2 opravili odlično delo in naredili skoraj vse, kar je bilo mogoče narediti na aplikacijskem sloju modela OSI. Čas je, da se spustimo na transportno plast in izumimo nov transportni protokol.
Potrebujemo nov protokol: UDP proti TCP
Kmalu je postalo jasno, da je implementacija popolnoma novega protokola transportnega sloja v današnji realnosti nemogoča naloga. Dejstvo je, da strojna oprema oziroma srednji sistemi (usmerjevalniki, požarni zidovi, NAT strežniki ...) poznajo transportni sloj in jih je naučiti česa novega izjemno težka naloga. Poleg tega je podpora za transportne protokole vgrajena v jedro operacijskih sistemov, jedra pa se prav tako ne želijo spreminjati.
In tukaj bi lahko dvignili roke in rekli: »Seveda bomo izumili nov HTTP/3 s preferencami in kurtizani, vendar bo trajalo 10–15 let, da bo implementiran (približno po tem času bo večina strojne opreme zamenjan),« vendar obstaja še ena, ki ni tako. Očitna možnost je uporaba protokola UDP. Da, da, isti protokol, ki smo ga uporabljali za pošiljanje datotek prek LAN v poznih devetdesetih in zgodnjih XNUMX-ih. Z njim lahko deluje skoraj vsa današnja strojna oprema.
Kakšne so prednosti UDP pred TCP? Prvič, nimamo seje transportne plasti, ki bi jo strojna oprema poznala. To nam omogoča, da sami določimo sejo na končnih točkah in tam razrešimo konflikte. To pomeni, da nismo omejeni na eno ali več sej (kot pri TCP), ampak jih lahko ustvarimo toliko, kot jih potrebujemo. Drugič, prenos podatkov prek UDP je hitrejši kot prek TCP. Tako lahko teoretično prebijemo trenutno zgornjo mejo hitrosti, doseženo v HTTP/2.
Vendar UDP ne zagotavlja zanesljivega prenosa podatkov. Pravzaprav preprosto pošiljamo pakete v upanju, da jih bo drugi konec prejel. Niste prejeli? No, brez sreče ... To je bilo dovolj za prenos videa za odrasle, za resnejše stvari pa rabiš zanesljivost, kar pomeni, da moraš na UDP naviti še kaj drugega.
Tako kot pri HTTP/2 se je delo na ustvarjanju novega protokola v Googlu začelo leta 2012, torej približno ob istem času, kot se je začelo delo na SPDY. Leta 2013 je Jim Roskind predstavil širši javnosti , že leta 2015 pa je bil za standardizacijo v IETF predstavljen Internet Draft. Že takrat se je protokol, ki ga je pri Googlu razvil Roskind, zelo razlikoval od standarda, zato se je Googlova različica začela imenovati gQUIC.
Kaj je QUIC
Prvič, kot že omenjeno, je to ovoj nad UDP. Povezava QUIC se dvigne nad UDP, v kateri lahko po analogiji s HTTP/2 obstaja več tokov. Ti tokovi obstajajo samo na končnih točkah in se strežejo neodvisno. Če pride do izgube paketa v enem toku, to ne bo vplivalo na druge.
Ilustracije Daniel Steinberg
Drugič, šifriranje se ne izvaja več na ločeni ravni, ampak je vključeno v protokol. To vam omogoča, da vzpostavite povezavo in izmenjate javne ključe v enem samem rokovanju, prav tako pa vam omogoča uporabo pametnega mehanizma rokovanja 0-RTT in se popolnoma izognete zakasnitvam rokovanja. Poleg tega je zdaj mogoče šifrirati posamezne podatkovne pakete. To vam omogoča, da ne čakate na zaključek prejemanja podatkov iz toka, ampak samostojno dešifrirate prejete pakete. Ta način delovanja je bil na splošno nemogoč v TCP, ker TLS in TCP sta delovala neodvisno drug od drugega in TLS ni mogel vedeti, na katere dele bodo razrezani podatki TCP. In zato svojih segmentov ni mogel pripraviti tako, da bi se prilegali segmentom TCP ena proti ena in bi jih bilo mogoče neodvisno dešifrirati. Vse te izboljšave omogočajo QUIC-u, da zmanjša zakasnitev v primerjavi s TCP.
Tretjič, koncept lahkega pretakanja vam omogoča, da ločite povezavo od odjemalčevega naslova IP. To je pomembno, na primer, ko odjemalec preklopi z ene dostopne točke Wi-Fi na drugo in spremeni svoj IP. V tem primeru pri uporabi TCP pride do dolgotrajnega procesa, med katerim potečejo obstoječe povezave TCP in se ustvarijo nove povezave iz novega IP-ja. V primeru QUIC odjemalec preprosto nadaljuje s pošiljanjem paketov strežniku z novega IP-ja s starim ID-jem toka. Ker ID toka je zdaj edinstven in se ne uporablja ponovno; strežnik razume, da je odjemalec spremenil IP, ponovno pošlje izgubljene pakete in nadaljuje komunikacijo na novem naslovu.
Četrtič, QUIC je implementiran na ravni aplikacije in ne na ravni operacijskega sistema. To vam po eni strani omogoča hitro spreminjanje protokola, saj Če želite pridobiti posodobitev, morate samo posodobiti knjižnico, namesto da čakate na novo različico OS. Po drugi strani pa to vodi v močno povečanje porabe procesorja.
In končno, naslovi. Stiskanje glave je ena od stvari, ki se razlikujeta med QUIC in gQUIC. Ne vidim smisla, da bi temu posvetil veliko časa, rekel bom le, da je bilo v različici, ki je bila predložena v standardizacijo, stiskanje glav čim bolj podobno stiskanju glav v HTTP/2. Lahko preberete več .
Koliko hitrejši je?
To je težko vprašanje. Dejstvo je, da dokler nimamo standarda, ni kaj posebnega za meriti. Morda je edina statistika, ki jo imamo, statistika Googla, ki gQUIC uporablja od leta 2013 in leta 2016 da približno 90 % prometa, ki gre na njihove strežnike iz brskalnika Chrome, zdaj uporablja QUIC. V isti predstavitvi poročajo, da se strani nalagajo približno 5 % hitreje prek gQUIC in da je v primerjavi s TCP 30 % manj zatikanj pri pretakanju videa.
Leta 2017 je skupina raziskovalcev pod vodstvom Arasha Molavija Kakhkija objavila preučiti zmogljivost gQUIC v primerjavi s TCP.
Študija je razkrila več slabosti gQUIC, kot so nestabilnost pri mešanju omrežnih paketov, požrešnost (nepravičnost) do pasovne širine kanala in počasnejši prenos majhnih (do 10 kb) objektov. Slednje pa je mogoče nadomestiti z uporabo 0-RTT. V vseh drugih preučevanih primerih je gQUIC pokazal povečanje hitrosti v primerjavi s TCP. Tukaj je težko govoriti o konkretnih številkah. Bolje preberite ali .
Tu je treba povedati, da se ti podatki nanašajo posebej na gQUIC in niso pomembni za standard, ki se razvija. Kaj se bo zgodilo s QUIC: še vedno je skrivnost, vendar obstaja upanje, da bodo pomanjkljivosti, ugotovljene v gQUIC, upoštevane in popravljene.
Malo prihodnosti: kaj pa HTTP/3?
Toda tukaj je vse kristalno jasno: API se ne bo spremenil na noben način. Vse bo ostalo popolnoma enako, kot je bilo v HTTP/2. No, če API ostane enak, bo treba prehod na HTTP/3 rešiti z uporabo sveže različice knjižnice na ozadju, ki podpira QUIC transport. Res je, da boste morali kar nekaj časa ohraniti nadomestno različico HTTP, ker Internet trenutno ni pripravljen za popoln prehod na UDP.
Kdo že podpira
Tu obstoječe izvedbe QUIC. Kljub pomanjkanju standarda seznam ni slab.
Noben brskalnik trenutno ne podpira QUIC v produkcijski izdaji. Pred kratkim so se pojavile informacije, da je podpora za HTTP/3 vključena v Chrome, vendar zaenkrat samo v Canary.
Od ozadij podpira samo HTTP/3 и , vendar še vedno eksperimentalno. NGINX konec pomladi 2019 , da so začeli delati na podpori HTTP/3, a je še niso dokončali.
Kakšne so težave?
Ti in jaz živiva v resničnem svetu, kjer nobena velika tehnologija ne more doseči množic, ne da bi naletela na odpor, in QUIC ni izjema.
Najpomembnejša stvar je, da morate nekako razložiti brskalniku, da "https://" ni več dejstvo, da vodi do TCP vrat 443. TCP morda sploh ne obstaja. Za to se uporablja glava Alt-Svc. Omogoča vam, da brskalniku sporočite, da je ta spletna stran na voljo tudi po takšnem in takem protokolu na takem in takem naslovu. V teoriji bi to moralo delovati kot čar, v praksi pa bomo naleteli na dejstvo, da je mogoče UDP na primer prepovedati na požarnem zidu, da se izognemo napadom DDoS.
Toda tudi če UDP ni prepovedan, je lahko odjemalec za usmerjevalnikom NAT, ki je konfiguriran za zadrževanje seje TCP po naslovu IP, in ker uporabljamo UDP, ki nima seje strojne opreme, NAT ne bo zadržal povezave in sejo QUIC .
Vse te težave so posledica dejstva, da UDP prej ni bil uporabljen za prenos internetnih vsebin in proizvajalci strojne opreme niso mogli predvideti, da se bo to kdaj zgodilo. Na enak način skrbniki še ne razumejo, kako pravilno konfigurirati svoja omrežja za delovanje QUIC. To stanje se bo postopoma spremenilo, v vsakem primeru pa bodo takšne spremembe trajale manj časa kot uvedba novega protokola transportnega sloja.
Poleg tega, kot je bilo že opisano, QUIC močno poveča porabo procesorja. Daniel Stenberg povečanje procesorja do trikrat.
Kdaj bo prišel HTTP/3?
Standardni do maja 2020, a glede na to, da dokumenti, predvideni za julij 2019, trenutno ostajajo nedokončani, lahko rečemo, da bo datum najverjetneje prestavljen.
No, Google svojo implementacijo gQUIC uporablja od leta 2013. Če pogledate zahtevo HTTP, ki je poslana Googlovemu iskalniku, boste videli tole:
Ugotovitve
QUIC je zdaj videti kot precej surova, a zelo obetavna tehnologija. Glede na to, da so se v zadnjih 20 letih vse optimizacije protokolov transportnega sloja nanašale predvsem na TCP, je QUIC, ki ima v večini primerov najboljše zmogljivosti, že videti izjemno dobro.
Še vedno pa ostajajo nerešeni problemi, ki jih bo treba rešiti v naslednjih letih. Postopek se lahko zavleče zaradi dejstva, da je vpletena strojna oprema, ki je nihče ne mara posodabljati, a kljub temu so vse težave videti precej rešljive in prej ali slej bomo vsi imeli HTTP/3.
Prihodnost je tik za vogalom!
Vir: www.habr.com