Dum pli ol 20 jaroj ni rigardas retpaĝojn per la HTTP-protokolo. Plej multaj uzantoj eĉ ne pensas pri kio ĝi estas kaj kiel ĝi funkcias. Aliaj scias, ke ie sub HTTP estas TLS, kaj sub tio estas TCP, sub kiu estas IP, ktp. Kaj ankoraŭ aliaj - herezuloj - kredas, ke TCP estas afero de la pasinteco; ili volas ion pli rapidan, pli fidindan kaj sekuran. Sed en siaj provoj inventi novan idealan protokolon, ili revenis al la teknologio de la 80-aj jaroj kaj provas konstrui sian kuraĝan novan mondon sur ĝi.
Iom da historio: HTTP/1.1
En 1997, la teksta informinterŝanĝa protokolo HTTP versio 1.1 akiris sian propran RFC. Tiutempe, la protokolo estis uzata de retumiloj dum pluraj jaroj, kaj la nova normo daŭris pliajn dek kvin. La protokolo funkciis nur laŭ la principo de peto-respondo kaj estis destinita ĉefe por transsendo de tekstaj informoj.
HTTP estis desegnita por funkcii al la supro de la TCP-protokolo, certigante ke pakoj estas fidinde liveritaj al sia celloko. TCP funkcias establante kaj konservante fidindan ligon inter finpunktoj kaj rompante trafikon en segmentojn. Segmentoj havas sian propran serian numeron kaj kontrolsumon. Se subite unu el la segmentoj ne alvenas aŭ alvenas kun malĝusta ĉeksumo, tiam la dissendo ĉesos ĝis la perdita segmento estas restarigita.
En HTTP/1.0, la TCP-konekto estis fermita post ĉiu peto. Ĉi tio estis ege malŝparema, ĉar... establi TCP-konekton (3-Way-Handshake) estas malrapida procezo. HTTP/1.1 enkondukis la teni-vivan mekanismon, kiu ebligas reuzi unu konekton por pluraj petoj. Tamen, ĉar ĝi povas facile fariĝi proplemkolo, diversaj efektivigoj de HTTP/1.1 permesas al multoblaj TCP-konektoj esti malfermitaj al la sama gastiganto. Ekzemple, Chrome kaj lastatempaj versioj de Fajrovulpo permesas ĝis ses konektojn.
Ĉifrado ankaŭ laŭsupoze estis lasita al aliaj protokoloj, kaj por tio, la TLS-protokolo estis uzita super TCP, kiu fidinde protektis la datenojn, sed plue pliigis la tempon postulatan por establi konekton. Kiel rezulto, la manprema procezo komencis aspekti jene:
Cloudflare ilustraĵo
Tiel HTTP/1.1 havis kelkajn problemojn:
- Malrapida konekto-agordo.
- Datumoj estas transdonitaj en tekstformo, kio signifas, ke la transdono de bildoj, filmetoj kaj aliaj netekstaj informoj estas neefika.
- Unu TCP-konekto estas uzata por unu peto, kio signifas, ke aliaj petoj devas aŭ trovi alian konekton aŭ atendi ĝis la nuna peto liberigas ĝin.
- Nur la tira modelo estas subtenata. Estas nenio en la normo pri servilo-puŝo.
- Titoloj estas transdonitaj en teksto.
Se servilo-puŝo estas almenaŭ efektivigita per la WebSocket-protokolo, tiam la ceteraj problemoj devis esti traktitaj pli radikale.
Iom da moderneco: HTTP/2
En 2012, Google komencis labori pri la SPDY (prononcita "rapida") protokolo. La protokolo estis desegnita por solvi la ĉefajn problemojn de HTTP/1.1 kaj samtempe devis konservi malantaŭan kongruon. En 2015, la laborgrupo de IETF lanĉis la HTTP/2-specifon bazitan sur la SPDY-protokolo. Jen la diferencoj en HTTP/2:
- Binara seriigo.
- Multipleksi multoblajn HTTP-petojn en ununuran TCP-konekton.
- Servilo-puŝu el la skatolo (sen WebSocket).
La protokolo estis granda paŝo antaŭen. Li forte kaj ne postulas la kreadon de multoblaj TCP-ligoj: ĉiuj petoj al unu gastiganto estas multipleksitaj en unu. Tio estas, en unu rilato estas pluraj tielnomitaj riveretoj, ĉiu el kiuj havas sian propran ID. La bonuso estas boksita servilo-puŝo.
Tamen, multipleksado kondukas al alia ŝlosila problemo. Imagu, ke ni nesinkrone plenumas 5 petojn al unu servilo. Kiam vi uzas HTTP/2, ĉiuj ĉi tiuj petoj estos efektivigitaj ene de la sama TCP-konekto, kio signifas, ke se unu el la segmentoj de iu peto estas perdita aŭ malĝuste ricevita, la dissendo de ĉiuj petoj kaj respondoj ĉesos ĝis la perdita segmento estos. restarigita. Evidente, ju pli malbona estas la kvalito de konekto, des pli malrapide funkcias HTTP/2. , en kondiĉoj kie perditaj pakoj okupas 2% de ĉiuj pakoj, HTTP/1.1 en la retumilo funkcias pli bone ol HTTP/2 pro la fakto ke ĝi malfermas 6 konektojn prefere ol unu.
Ĉi tiu problemo nomiĝas "ĉeflinia blokado" kaj bedaŭrinde ne eblas solvi ĝin kiam oni uzas TCP.
Ilustraĵo de Daniel Steinberg
Kiel rezulto, la programistoj de la HTTP/2 normo faris bonegan laboron kaj faris preskaŭ ĉion, kio povus esti farita ĉe la aplika tavolo de la OSI-modelo. Estas tempo malsupreniri al la transporta tavolo kaj inventi novan transportprotokolon.
Ni bezonas novan protokolon: UDP vs TCP
Sufiĉe rapide evidentiĝis, ke efektivigi tute novan transporttavolan protokolon estas neebla tasko en la hodiaŭaj realaĵoj. La fakto estas, ke aparataro aŭ mezaj skatoloj (enkursigiloj, fajroŝirmiloj, NAT-serviloj...) scias pri la transporttavolo, kaj instrui al ili ion novan estas ege malfacila tasko. Krome, subteno por transportprotokoloj estas konstruita en la kernon de operaciumoj, kaj kernoj ankaŭ ne tre volonte ŝanĝiĝas.
Kaj ĉi tie oni povus levi la manojn kaj diri “Ni, kompreneble, inventos novan HTTP/3 kun prefero kaj korteganoj, sed necesos 10-15 jaroj por esti efektivigita (post proksimume ĉi tiu tempo la plej granda parto de la aparataro estos anstataŭigita),” sed ekzistas unu pli ne tiel La evidenta opcio estas uzi la UDP-protokolon. Jes, jes, la sama protokolo, kiun ni uzis por ĵeti dosierojn tra LAN fine de la naŭdekaj kaj fruaj XNUMX-aj jaroj. Preskaŭ ĉiuj hodiaŭaj aparataro povas funkcii kun ĝi.
Kio estas la avantaĝoj de UDP super TCP? Antaŭ ĉio, ni ne havas transporttavolan sesion pri kiu la aparataro scias. Ĉi tio permesas al ni mem determini la sesion sur la finpunktoj kaj solvi konfliktojn tie. Tio estas, ni ne estas limigitaj al unu aŭ pluraj sesioj (kiel en TCP), sed povas krei tiom da el ili kiom ni bezonas. Due, transdono de datumoj per UDP estas pli rapida ol per TCP. Tiel, en teorio, ni povas trarompi la nunan rapidecplafonon atingitan en HTTP/2.
Tamen, UDP ne garantias fidindan transdonon de datumoj. Fakte, ni simple sendas paketojn, esperante ke la alia fino ricevos ilin. Ĉu ne ricevis? Nu, sen sukceso... Ĉi tio sufiĉis por transdoni filmetojn por plenkreskuloj, sed por pli seriozaj aferoj oni bezonas fidindecon, kio signifas, ke oni devas envolvi ion alian sur UDP.
Kiel ĉe HTTP/2, laboro pri kreado de nova protokolo komenciĝis ĉe Google en 2012, tio estas, ĉirkaŭ la sama tempo kiam komenciĝis laboro pri SPDY. En 2013, Jim Roskind prezentis al la popolo , kaj jam en 2015 la Interreta Malneto estis lanĉita por normigado en la IETF. Jam en tiu tempo, la protokolo evoluigita de Roskind ĉe Guglo estis tre malsama al la normo, do la Guglo-versio komencis nomi gQUIC.
Kio estas QUIC
Unue, kiel jam menciite, ĉi tio estas envolvaĵo super UDP. QUIC-konekto altiĝas super UDP, en kiu, analoge kun HTTP/2, povas ekzisti pluraj fluoj. Ĉi tiuj fluoj ekzistas nur sur la finpunktoj kaj estas servataj sendepende. Se paka perdo okazas en unu fluo, ĝi ne influos aliajn.
Ilustraĵo de Daniel Steinberg
Due, ĉifrado ne plu estas efektivigita sur aparta nivelo, sed estas inkluzivita en la protokolo. Ĉi tio ebligas al vi establi konekton kaj interŝanĝi publikajn ŝlosilojn per ununura manpremo, kaj ankaŭ permesas vin uzi la lertan 0-RTT-manpreman mekanismon kaj tute eviti manpremon prokrastojn. Krome, nun eblas ĉifri individuajn datumpakaĵojn. Ĉi tio ebligas al vi ne atendi la kompletigon de ricevado de datumoj de la rivereto, sed deĉifri la ricevitajn pakaĵojn sendepende. Ĉi tiu maniero de operacio estis ĝenerale malebla en TCP, ĉar TLS kaj TCP funkciis sendepende unu de la alia, kaj TLS ne povis scii en kiujn pecojn TCP-datumoj estus hakitaj. Kaj tial, li ne povis prepari siajn segmentojn tiel ke ili kongruas en TCP-segmentojn unu al unu kaj povus esti deĉifritaj sendepende. Ĉiuj ĉi tiuj plibonigoj permesas al QUIC redukti latencian kompare kun TCP.
Trie, la koncepto de malpeza streaming permesas vin malkunligi la konekton de la IP-adreso de la kliento. Ĉi tio gravas, ekzemple, kiam kliento ŝanĝas de unu WiFi-alirpunkto al alia, ŝanĝante sian IP. En ĉi tiu kazo, dum uzado de TCP, longa procezo okazas dum kiu ekzistantaj TCP-konektoj elĉerpas kaj novaj ligoj estas kreitaj de nova IP. En la kazo de QUIC, la kliento simple daŭre sendas pakaĵojn al la servilo de nova IP kun la malnova fluo ID. Ĉar La fluo ID nun estas unika kaj ne estas reuzata; la servilo komprenas, ke la kliento ŝanĝis IP, resendas perditajn pakaĵetojn kaj daŭrigas komunikadon ĉe la nova adreso.
Kvare, QUIC estas efektivigita ĉe la aplikaĵnivelo, ne la operaciuma nivelo. Ĉi tio, unuflanke, permesas vin rapide fari ŝanĝojn al la protokolo, ĉar Por ricevi ĝisdatigon, vi nur bezonas ĝisdatigi la bibliotekon, anstataŭ atendi novan OS-version. Aliflanke, ĉi tio kondukas al forta pliiĝo en la konsumo de procesoroj.
Kaj fine, la titoloj. Kapa kunpremo estas unu el la aferoj, kiuj diferencas inter QUIC kaj gQUIC. Mi ne vidas la signifon dediĉi multan tempon al ĉi tio, mi nur diros, ke en la versio prezentita por normigo, kap-kunpremado estis farita kiel eble plej simila al kap-kunpremo en HTTP/2. Vi povas legi pli .
Насколько оно быстрее?
Estas malfacila demando. La fakto estas, ke ĝis ni havas normon, estas nenio speciala por mezuri. Eble la solaj statistikoj, kiujn ni havas, estas statistikoj de Guglo, kiu uzas gQUIC ekde 2013 kaj en 2016. ke ĉirkaŭ 90% de la trafiko iranta al siaj serviloj de la Chrome-retumilo nun uzas QUIC. En la sama prezento, ili raportas, ke paĝoj ŝarĝas ĉirkaŭ 5% pli rapide per gQUIC kaj estas 30% malpli da balbutoj en videofluado kompare kun TCP.
En 2017, grupo de esploristoj gviditaj de Arash Molavi Kakhki publikigis studi la agadon de gQUIC kompare kun TCP.
La studo rivelis plurajn malfortojn de gQUIC, kiel ekzemple malstabileco al la miksado de retpakaĵetoj, avideco (maljusteco) enkanaligi bendolarĝon kaj pli malrapidan translokigon de malgrandaj (ĝis 10 kb) objektoj. Ĉi-lasta, tamen, povas esti kompensita per uzado de 0-RTT. En ĉiuj aliaj kazoj studitaj, gQUIC montris pliiĝon en rapideco kompare kun TCP. Estas malfacile paroli pri specifaj nombroj ĉi tie. Pli bone legi aŭ .
Ĉi tie oni devas diri, ke ĉi tiuj datumoj estas specife pri gQUIC, kaj ĝi ne gravas por la evoluiga normo. Kio okazos por QUIC: ĝi ankoraŭ estas sekreto, sed estas espero, ke la malfortoj identigitaj en gQUIC estos konsiderataj kaj korektitaj.
Iom de la estonteco: kio pri HTTP/3?
Sed ĉi tie ĉio estas kristale klara: la API neniel ŝanĝiĝos. Ĉio restos ekzakte sama kiel ĝi estis en HTTP/2. Nu, se la API restas la sama, la transiro al HTTP/3 devos esti solvita uzante freŝan version de la biblioteko sur la backend, kiu subtenas QUIC-transporton. Vere, vi devos konservi la restarigon de malnovaj versioj de HTTP dum sufiĉe da tempo, ĉar La Interreto nuntempe ne estas preta por kompleta transiro al UDP.
Kiu jam subtenas
tie ekzistantaj QUIC-efektivigoj. Malgraŭ la manko de normo, la listo ne estas malbona.
Neniu retumilo nuntempe subtenas QUIC en produkta eldono. Lastatempe estis informoj, ke subteno por HTTP/3 estis inkluzivita en Chrome, sed ĝis nun nur en Kanario.
El la backends, HTTP/3 nur subtenas и , sed ankoraŭ eksperimenta. NGINX fine de printempo 2019 , ke ili komencis labori pri HTTP/3-subteno, sed ankoraŭ ne finis ĝin.
Kio estas la problemoj?
Vi kaj mi vivas en la reala mondo, kie neniu granda teknologio povas atingi la amasojn sen renkonti reziston, kaj QUIC ne estas escepto.
La plej grava afero estas, ke vi devas iel klarigi al la retumilo, ke "https://" ne plu estas fakto, ke ĝi kondukas al TCP-haveno 443. Eble tute ne ekzistas TCP. La Alt-Svc-kapo estas uzata por tio. Ĝi permesas al vi diri al la retumilo, ke ĉi tiu retejo ankaŭ disponeblas en tia kaj tia protokolo ĉe tia kaj tia adreso. En teorio, ĉi tio devus funkcii kiel ĉarmo, sed praktike ni trovos la fakton, ke UDP povas, ekzemple, esti malpermesita sur fajroŝirmilo por eviti DDoS-atakojn.
Sed eĉ se UDP ne estas malpermesita, la kliento povas esti malantaŭ NAT-enkursigilo, kiu estas agordita por okazigi TCP-sesion per IP-adreso, kaj ĉar ni uzas UDP, kiu ne havas aparatan sesion, NAT ne tenos la konekton, kaj QUIC-sesion .
Ĉiuj ĉi tiuj problemoj ŝuldiĝas al la fakto, ke UDP antaŭe ne estis uzata por transdoni interretan enhavon, kaj aparataro-fabrikistoj ne povis antaŭvidi, ke tio iam okazos. Sammaniere, administrantoj ankoraŭ ne vere komprenas kiel ĝuste agordi siajn retojn por ke QUIC funkciu. Ĉi tiu situacio iom post iom ŝanĝiĝos, kaj, ĉiukaze, tiaj ŝanĝoj daŭros malpli da tempo ol la efektivigo de nova transporttavola protokolo.
Aldone, kiel jam priskribite, QUIC multe pliigas CPU-uzadon. Daniel Stenberg procesoro kresko ĝis tri fojojn.
Kiam HTTP/3 alvenos?
Norma ĝis majo 2020, sed pro tio, ke dokumentoj planitaj por julio 2019 nuntempe restas nefinitaj, ni povas diri, ke la dato plej verŝajne estos prokrastita.
Nu, Guglo uzas sian efektivigon de gQUIC ekde 2013. Se vi rigardas la HTTP-peton, kiu estas sendita al la Google-serĉilo, vi vidos ĉi tion:
trovoj
QUIC nun aspektas kiel sufiĉe kruda, sed tre promesplena teknologio. Konsiderante, ke dum la lastaj 20 jaroj, ĉiuj optimumigoj de transporttavolaj protokoloj koncernis ĉefe TCP, QUIC, kiu plejofte havas la plej bonan rendimenton, jam aspektas ege bone.
Tamen estas ankoraŭ nesolvitaj problemoj, kiujn oni devos trakti en la venontaj kelkaj jaroj. La procezo povas esti prokrastita pro la fakto, ke estas aparataro implikita, kiun neniu ŝatas ĝisdatigi, sed tamen ĉiuj problemoj aspektas sufiĉe solveblaj, kaj baldaŭ aŭ malfrue ni ĉiuj havos HTTP/3.
La estonteco estas tuj ĉirkaŭ la angulo!
fonto: www.habr.com