Yli 20 vuoden ajan olemme katselleet web-sivuja HTTP-protokollalla. Useimmat käyttäjät eivät edes ajattele, mikä se on ja miten se toimii. Toiset tietävät, että jossain HTTP:n alla on TLS ja sen alla TCP, jonka alla on IP ja niin edelleen. Ja vielä toiset - harhaoppiset - uskovat, että TCP on menneisyyttä; he haluavat jotain nopeampaa, luotettavampaa ja turvallisempaa. Mutta yrittäessään keksiä uutta ihanneprotokollaa he ovat palanneet 80-luvun tekniikkaan ja yrittävät rakentaa sille uutta rohkeaa maailmaansa.
Hieman historiaa: HTTP/1.1
Vuonna 1997 tekstitiedonvaihtoprotokolla HTTP-versio 1.1 sai oman RFC:n. Protokolla oli tuolloin ollut selaimissa käytössä useita vuosia, ja uusi standardi kesti vielä viisitoista. Protokolla toimi vain pyyntö-vastaus -periaatteella ja oli tarkoitettu pääasiassa tekstitiedon välittämiseen.
HTTP on suunniteltu toimimaan TCP-protokollan päällä varmistaen, että paketit toimitetaan luotettavasti määränpäähänsä. TCP toimii luomalla ja ylläpitämällä luotettavaa yhteyttä päätepisteiden välille ja jakamalla liikenteen segmentteihin. Segmenteillä on oma sarjanumero ja tarkistussumma. Jos yhtäkkiä jokin segmenteistä ei saapu tai saapuu väärällä tarkistussummalla, lähetys pysähtyy, kunnes kadonnut segmentti palautetaan.
HTTP/1.0:ssa TCP-yhteys suljettiin jokaisen pyynnön jälkeen. Tämä oli erittäin turhaa, koska... TCP-yhteyden muodostaminen (3-Way-Handshake) on hidas prosessi. HTTP/1.1 esitteli säilytysmekanismin, jonka avulla voit käyttää yhtä yhteyttä uudelleen useisiin pyyntöihin. Kuitenkin, koska siitä voi helposti muodostua pullonkaula, HTTP/1.1:n erilaiset toteutukset mahdollistavat useiden TCP-yhteyksien avaamisen samalle isännälle. Esimerkiksi Chrome ja Firefoxin uusimmat versiot sallivat jopa kuusi yhteyttä.
Myös salaus piti jättää muille protokollille, ja tähän käytettiin TCP:n yli TLS-protokollaa, joka suojasi tiedot luotettavasti, mutta lisäsi yhteyden muodostamiseen kuluvaa aikaa entisestään. Tämän seurauksena kättelyprosessi alkoi näyttää tältä:
Cloudflare kuva
Siten HTTP/1.1:ssä oli useita ongelmia:
- Hidas yhteyden muodostus.
- Tiedot välitetään tekstimuodossa, mikä tarkoittaa, että kuvien, videoiden ja muun ei-tekstitiedon välittäminen on tehotonta.
- Yhdelle pyynnölle käytetään yhtä TCP-yhteyttä, mikä tarkoittaa, että muiden pyyntöjen on joko löydettävä toinen yhteys tai odotettava, kunnes nykyinen pyyntö vapauttaa sen.
- Vain vetomallia tuetaan. Standardissa ei ole mitään palvelinpushista.
- Otsikot välitetään tekstinä.
Jos server-push on ainakin toteutettu WebSocket-protokollalla, niin jäljelle jääneitä ongelmia jouduttiin käsittelemään radikaalimmin.
Hieman modernia: HTTP/2
Vuonna 2012 Google aloitti SPDY-protokollan (lausutaan "speedy") parissa. Protokolla on suunniteltu ratkaisemaan HTTP/1.1:n pääongelmat ja samalla sen piti säilyttää taaksepäin yhteensopivuus. IETF-työryhmä esitteli vuonna 2015 SPDY-protokollaan perustuvan HTTP/2-määrityksen. Tässä ovat HTTP/2:n erot:
- Binäärinen serialisointi.
- Useiden HTTP-pyyntöjen multipleksointi yhdeksi TCP-yhteydeksi.
- Server-push ulos laatikosta (ilman WebSocket).
Protokolla oli iso askel eteenpäin. Hän vahvasti eikä vaadi useiden TCP-yhteyksien luomista: kaikki pyynnöt yhdelle isännälle multipleksoidaan yhdeksi. Eli yhdessä yhteydessä on useita ns. streameja, joilla jokaisella on oma ID. Bonus on boxed server-push.
Multipleksointi johtaa kuitenkin toiseen keskeiseen ongelmaan. Kuvittele, että suoritamme asynkronisesti 5 pyyntöä yhdelle palvelimelle. HTTP/2:ta käytettäessä kaikki nämä pyynnöt suoritetaan saman TCP-yhteyden sisällä, mikä tarkoittaa, että jos jokin pyynnön segmenteistä katoaa tai vastaanotetaan väärin, kaikkien pyyntöjen ja vastausten lähetys pysähtyy, kunnes kadonnut segmentti on kadonnut. palautettu. Ilmeisesti mitä huonompi yhteyden laatu on, sitä hitaammin HTTP/2 toimii. , olosuhteissa, joissa kadonneiden pakettien osuus on 2 % kaikista paketeista, selaimen HTTP/1.1 toimii paremmin kuin HTTP/2, koska se avaa 6 yhteyttä yhden sijaan.
Tätä ongelmaa kutsutaan "head-of-line blocking"ksi, ja valitettavasti sitä ei ole mahdollista ratkaista TCP:tä käytettäessä.
Kuvitus Daniel Steinberg
Tuloksena HTTP/2-standardin kehittäjät tekivät hienoa työtä ja tekivät melkein kaiken, mitä OSI-mallin sovellustasolla voitiin tehdä. On aika mennä alas kuljetuskerrokseen ja keksiä uusi kuljetusprotokolla.
Tarvitsemme uuden protokollan: UDP vs TCP
Melko nopeasti kävi selväksi, että täysin uuden kuljetuskerroksen protokollan käyttöönotto on tämän päivän todellisuudessa mahdoton tehtävä. Tosiasia on, että laitteistot tai keskilaatikot (reitittimet, palomuurit, NAT-palvelimet...) tietävät kuljetuskerroksesta, ja heille uuden opettaminen on erittäin vaikea tehtävä. Lisäksi siirtoprotokollien tuki on sisäänrakennettu käyttöjärjestelmien ytimeen, eivätkä ytimet myöskään ole kovin halukkaita muuttumaan.
Ja tässä voisi nostaa kätensä ja sanoa: "Tietenkin keksimme uuden HTTP/3:n etusijalla ja kurtisaaneilla, mutta sen käyttöönotto kestää 10-15 vuotta (noin tämän ajan jälkeen suurin osa laitteistosta korvattu), mutta on vielä yksi ei niin Ilmeinen vaihtoehto on käyttää UDP-protokollaa. Kyllä, kyllä, sama protokolla, jota käytimme tiedostojen lähettämiseen lähiverkon kautta XNUMX-luvun lopulla ja XNUMX-luvun alussa. Lähes kaikki nykyiset laitteet voivat toimia sen kanssa.
Mitkä ovat UDP:n edut TCP:hen verrattuna? Ensinnäkin meillä ei ole kuljetuskerroksen istuntoa, josta laitteisto tietää. Tämän avulla voimme itse määrittää istunnon päätepisteissä ja ratkaista ristiriidat siellä. Toisin sanoen emme rajoitu yhteen tai useampaan istuntoon (kuten TCP:ssä), vaan voimme luoda niitä niin monta kuin tarvitsemme. Toiseksi tiedonsiirto UDP:n kautta on nopeampaa kuin TCP:n kautta. Siten teoriassa voimme rikkoa HTTP/2:ssa saavutetun nykyisen nopeuskaton.
UDP ei kuitenkaan takaa luotettavaa tiedonsiirtoa. Itse asiassa lähetämme vain paketteja toivoen, että toinen pää vastaanottaa ne. Etkö ole saanut? No ei onnea... Tämä riitti aikuisten videoiden lähettämiseen, mutta vakavampiin asioihin tarvitaan luotettavuutta, eli UDP:n päälle on käärittävä jotain muuta.
Kuten HTTP/2:n kohdalla, uuden protokollan luominen aloitettiin Googlessa vuonna 2012 eli suunnilleen samaan aikaan kuin SPDY:n työ aloitettiin. Vuonna 2013 Jim Roskind esitteli suurelle yleisölle , ja jo vuonna 2015 Internet-luonnos otettiin käyttöön standardointia varten IETF:ssä. Jo tuolloin Roskindin Googlessa kehittämä protokolla poikkesi suuresti standardista, joten Google-versiota alettiin kutsua gQUIC:ksi.
Mikä on QUIC
Ensinnäkin, kuten jo mainittiin, tämä on UDP:n kääre. UDP:n päälle nousee QUIC-yhteys, jossa analogisesti HTTP/2:n kanssa voi olla useita virtoja. Nämä virrat ovat olemassa vain päätepisteissä ja niitä palvellaan itsenäisesti. Jos pakettihäviö tapahtuu yhdessä virrassa, se ei vaikuta muihin.
Kuvitus Daniel Steinberg
Toiseksi salausta ei enää toteuteta erillisellä tasolla, vaan se sisältyy protokollaan. Tämän avulla voit muodostaa yhteyden ja vaihtaa julkisia avaimia yhdessä kättelyssä, ja voit myös käyttää älykästä 0-RTT-kättelymekanismia ja välttää kättelyn viiveet kokonaan. Lisäksi on nyt mahdollista salata yksittäisiä datapaketteja. Näin et odota tietojen vastaanottamisen valmistumista virrasta, vaan voit purkaa vastaanotettujen pakettien salauksen itsenäisesti. Tämä toimintatapa oli yleensä mahdotonta TCP:ssä, koska TLS ja TCP toimivat toisistaan riippumatta, eikä TLS voinut tietää, mihin osiin TCP-data pilkkoutuisi. Ja siksi hän ei voinut valmistella segmenttejään niin, että ne mahtuisivat TCP-segmentteihin yksi yhteen ja voitaisiin purkaa itsenäisesti. Kaikki nämä parannukset antavat QUIC:lle mahdollisuuden vähentää latenssia TCP:hen verrattuna.
Kolmanneksi valon suoratoiston konsepti mahdollistaa yhteyden irrottamisen asiakkaan IP-osoitteesta. Tämä on tärkeää esimerkiksi silloin, kun asiakas vaihtaa Wi-Fi-tukiasemasta toiseen ja vaihtaa IP-osoitettaan. Tässä tapauksessa TCP:tä käytettäessä tapahtuu pitkä prosessi, jonka aikana olemassa olevat TCP-yhteydet aikakatkaistaan ja uusia yhteyksiä luodaan uudesta IP-osoitteesta. QUIC:n tapauksessa asiakas yksinkertaisesti jatkaa pakettien lähettämistä palvelimelle uudesta IP-osoitteesta vanhalla stream ID:llä. Koska Virtatunnus on nyt ainutlaatuinen eikä sitä käytetä uudelleen; palvelin ymmärtää asiakkaan vaihtaneen IP-osoitteen, lähettää kadonneet paketit uudelleen ja jatkaa viestintää uudessa osoitteessa.
Neljänneksi QUIC toteutetaan sovellustasolla, ei käyttöjärjestelmätasolla. Tämä toisaalta antaa sinun tehdä nopeasti muutoksia protokollaan, koska Päivityksen saamiseksi sinun on vain päivitettävä kirjasto sen sijaan, että odotat uutta käyttöjärjestelmäversiota. Toisaalta tämä johtaa voimakkaaseen prosessorin kulutuksen kasvuun.
Ja lopuksi otsikot. Otsikon pakkaus on yksi niistä asioista, jotka eroavat QUIC:n ja gQUIC:n välillä. En näe järkeä uhrata tähän paljon aikaa, sanon vain, että standardointiin lähetetyssä versiossa otsikkopakkaus tehtiin mahdollisimman samankaltaiseksi kuin HTTP/2:n otsikkopakkaus. Voit lukea lisää .
Kuinka paljon nopeampi se on?
Se on vaikea kysymys. Tosiasia on, että ennen kuin meillä on standardi, ei ole mitään erityistä mitattavaa. Ehkä ainoat tilastot, joita meillä on, ovat Googlen tilastot, joka on käyttänyt gQUICia vuodesta 2013 ja vuonna 2016 että noin 90 % liikenteestä, joka menee heidän palvelimilleen Chrome-selaimesta, käyttää nyt QUIC:ia. Samassa esityksessä he raportoivat, että sivut latautuvat noin 5 % nopeammin gQUIC:n kautta ja videon suoratoistossa on 30 % vähemmän änkytystä TCP:hen verrattuna.
Vuonna 2017 Arash Molavi Kakhkin johtama tutkijaryhmä julkaisi tutkia gQUIC:n suorituskykyä TCP:hen verrattuna.
Tutkimus paljasti useita gQUIC:n heikkouksia, kuten epävakautta verkkopakettien sekoittamisessa, ahneutta (epäreilua) kanavan kaistanleveyteen ja pienten (enintään 10 kb) objektien hitaampaa siirtoa. Jälkimmäistä voidaan kuitenkin kompensoida käyttämällä 0-RTT:tä. Kaikissa muissa tutkituissa tapauksissa gQUIC osoitti nopeuden lisääntymistä TCP:hen verrattuna. Tässä on vaikea puhua yksittäisistä numeroista. Parempi lukea tai .
Tässä on sanottava, että nämä tiedot koskevat nimenomaan gQUICia, eikä niillä ole merkitystä kehitettävän standardin kannalta. Mitä tapahtuu QUIC:lle: se on edelleen salaisuus, mutta on toivoa, että gQUIC:ssa havaitut heikkoudet otetaan huomioon ja korjataan.
Hieman tulevaisuutta: entä HTTP/3?
Mutta tässä kaikki on kristallinkirkasta: API ei muutu millään tavalla. Kaikki pysyy täsmälleen samoina kuin se oli HTTP/2:ssa. No, jos API pysyy samana, siirtyminen HTTP/3:een on ratkaistava käyttämällä QUIC-siirtoa tukevan taustajärjestelmän tuoretta versiota kirjastosta. On totta, että joudut säilyttämään varaosan vanhoissa HTTP-versioissa jonkin aikaa, koska Internet ei ole tällä hetkellä valmis täydelliseen siirtymiseen UDP:hen.
Kuka jo tukee
Täällä olemassa olevia QUIC-toteutuksia. Standardin puutteesta huolimatta luettelo ei ole huono.
Mikään selain ei tällä hetkellä tue QUIC:tä tuotantojulkaisussa. Äskettäin oli tietoa, että HTTP/3-tuki sisällytettiin Chromeen, mutta toistaiseksi vain Canaryssa.
Taustaohjelmista vain HTTP/3 tukee и , mutta vielä kokeellinen. NGINX kevään 2019 lopussa , että he alkoivat työstää HTTP/3-tukea, mutta eivät ole vielä saaneet sitä valmiiksi.
Mitkä ovat ongelmat?
Sinä ja minä elämme todellisessa maailmassa, jossa mikään suuri teknologia ei voi saavuttaa massoja kohtaamatta vastustusta, eikä QUIC ole poikkeus.
Tärkeintä on, että sinun täytyy jotenkin selittää selaimelle, että "https://" ei ole enää tosiasia, että se johtaa TCP-porttiin 443. TCP:tä ei ehkä ole ollenkaan. Alt-Svc-otsikkoa käytetään tähän. Sen avulla voit kertoa selaimelle, että tämä verkkosivusto on myös saatavilla sellaisella ja sellaisella protokollalla sellaisessa ja sellaisessa osoitteessa. Teoriassa tämän pitäisi toimia kuin hurmaa, mutta käytännössä törmäämme siihen tosiasiaan, että UDP voidaan esimerkiksi estää palomuurissa DDoS-hyökkäysten välttämiseksi.
Mutta vaikka UDP ei ole kiellettyä, asiakas voi olla NAT-reitittimen takana, joka on määritetty pitämään TCP-istunto IP-osoitteen perusteella, ja koska käytämme UDP:tä, jolla ei ole laitteistoistuntoa, NAT ei pidä yhteyttä ja QUIC-istuntoa .
Kaikki nämä ongelmat johtuvat siitä, että UDP:tä ei ollut aiemmin käytetty Internet-sisällön välittämiseen, eivätkä laitevalmistajat voineet ennakoida tämän tapahtuvan koskaan. Samalla tavalla järjestelmänvalvojat eivät vielä oikein ymmärrä, kuinka verkkonsa määritetään oikein, jotta QUIC toimisi. Tämä tilanne muuttuu vähitellen, ja joka tapauksessa tällaiset muutokset vievät vähemmän aikaa kuin uuden kuljetuskerroksen protokollan käyttöönotto.
Lisäksi, kuten jo kuvattiin, QUIC lisää huomattavasti suorittimen käyttöä. Daniel Stenberg prosessorin kasvu jopa kolme kertaa.
Milloin HTTP/3 saapuu?
Standardi toukokuuhun 2020 mennessä, mutta kun otetaan huomioon, että heinäkuulle 2019 suunnitellut asiakirjat ovat tällä hetkellä keskeneräisiä, voidaan todeta, että päivämäärää todennäköisesti siirretään.
No, Google on käyttänyt gQUIC-toteutustaan vuodesta 2013 lähtien. Jos katsot Googlen hakukoneelle lähetettyä HTTP-pyyntöä, näet tämän:
Tulokset
QUIC näyttää nyt melko karkealta, mutta erittäin lupaavalta tekniikalta. Ottaen huomioon, että viimeisten 20 vuoden aikana kaikki kuljetuskerroksen protokollien optimoinnit ovat koskeneet pääasiassa TCP:tä, QUIC, joka on useimmissa tapauksissa paras suorituskyky, näyttää jo erittäin hyvältä.
On kuitenkin edelleen ratkaisemattomia ongelmia, jotka on ratkaistava lähivuosina. Prosessi saattaa viivästyä johtuen siitä, että mukana on laitteistoa, jota kukaan ei tykkää päivittää, mutta siitä huolimatta kaikki ongelmat näyttävät varsin ratkaistavissa ja ennemmin tai myöhemmin meillä kaikilla on HTTP/3.
Tulevaisuus on aivan nurkan takana!
Lähde: will.com