{"id":52181,"date":"2019-11-02T00:00:00","date_gmt":"2019-11-01T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/http-3-razrushenie-osnov-i-divnyj-novyj-mir"},"modified":"2020-02-18T13:59:51","modified_gmt":"2020-02-18T10:59:51","slug":"http-3-razrushenie-osnov-i-divnyj-novyj-mir","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","title":{"rendered":"HTTP\/3: alusm\u00fc\u00fcride purustamine ja imeline uus maailm","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Oleme juba \u00fcle 20 aasta vaadanud veebilehti HTTP-protokolli kaudu. Enamik kasutajatest ei m\u00f5tle sellele, mis see on ja kuidas see t\u00f6\u00f6tab. Teised teavad, et kuskil HTTP all on TLS, selle all TCP, all IP jne. Ja kolmandad \u2013 heretikud \u2013 arvavad, et TCP on minevik, nad tahavad midagi kiiremat, usaldusv\u00e4\u00e4rsemat ja turvalisemat. Kuid oma katsetes leiutada uut ideaalset protokolli on nad tagasi p\u00f6\u00f6rdunud 80ndate tehnoloogiate juurde ja p\u00fc\u00fcavad ehitada nendele oma imelist uut maailmaga.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: alusm\u00fc\u00fcride purustamine ja imeline uus maailm\" src=\"\/wp-content\/uploads\/2019\/11\/869bd86cc0b47c6c42f315cf20640018.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Veidi ajalugu: HTTP\/1.1<\/h2>\n<p>\nAastal 1997 sai tekstilise teabe edastamise protokoll HTTP versioon 1.1 oma RFC. Selleks ajaks oli protokolli juba mitu aastat kasutanud brauserid, ja uus standard p\u00fcsis veel viisteist aastat. Protokoll t\u00f6\u00f6tas ainult p\u00e4ringu-vastuse p\u00f5him\u00f5ttel ja oli peamiselt m\u00f5eldud tekstilise teabe edastamiseks.<\/p>\n<p>HTTP kavandati t\u00f6\u00f6tama TCP-protokolli peal, mis tagab paketide usaldusv\u00e4\u00e4rse kohaletoimetamise sihtkohta. TCP t\u00f6\u00f6p\u00f5him\u00f5te p\u00f5hineb usaldusv\u00e4\u00e4rse \u00fchenduse loomisel ja hoidmisel l\u00f5pp-punktide vahel ning andmete jagamisel segmentideks. Segmentidel on oma j\u00e4rjestusnumber ja kontrollsumma. Kui m\u00f5ni segment ei j\u00f5ua kohale v\u00f5i tuleb vale kontrollsumma korral, siis edastus peatub, kuni kadunud segment on taastatud.<\/p>\n<p>HTTP\/1.0 TCP-\u00fchendus suleti p\u00e4rast iga p\u00e4ringut. See oli \u00e4\u00e4rmiselt raiskav, kuna TCP-\u00fchenduse loomine (3-Way-Handshake) ei ole kiire protsess. HTTP\/1.1 tutvustas keep-alive mehhanismi, mis v\u00f5imaldab rakendada \u00fchte \u00fchendust mitme p\u00e4ringu jaoks. Kuid kuna see v\u00f5ib kergesti muutuda pudelikaelaks, siis erinevates HTTP\/1.1 rakendustes on lubatud avada mitu TCP-\u00fchendust \u00fche hostiga. N\u00e4iteks Chrome'is ja viimastes Firefoxi versioonides on lubatud kuni kuus \u00fchendust.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: alusm\u00fc\u00fcride purustamine ja imeline uus maailm\" src=\"\/wp-content\/uploads\/2019\/11\/b1c131da8e62ace741f3064f2fb96c60.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nKr\u00fcpteerimine pidi samuti olema usaldatud teistele protokollidele, ning selleks hakati TCP peal kasutama TLS-protokolli, mis kaitses andmeid piisavalt usaldusv\u00e4\u00e4rselt, kuid suurendas veelgi aega, mis oli vajalik \u00fchenduse loomiseks. Seega hakkas k\u00e4epigistuse protsess v\u00e4lja n\u00e4gema j\u00e4rgmiselt:<br \/>\n <img decoding=\"async\" alt=\"HTTP\/3: alusm\u00fc\u00fcride purustamine ja imeline uus maailm\" src=\"\/wp-content\/uploads\/2019\/11\/2fdccf56e0ed29444557836fdc65351b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Cloudflare'i joonis<\/i><\/p>\n<p>Seega oli HTTP\/1.1-l mitmeid probleeme:<\/p>\n<ul>\n<li>Aeglane \u00fchenduse loomine.<\/li>\n<li>Andmed edastatakse tekstivormingus, mis t\u00e4hendab, et piltide, video ja muu mitte-teksti info edastamine on ebaefektiivne.<\/li>\n<li>\u00dcks TCP-\u00fchendus kasutatakse \u00fche p\u00e4ringu jaoks, mis t\u00e4hendab, et \u00fclej\u00e4\u00e4nud p\u00e4ringud peavad leidma uue \u00fchenduse v\u00f5i ootama, kuni praegune p\u00e4ring vabastatakse.<\/li>\n<li>Toetatakse ainult pull-mudelit. Standardis ei ole midagi serveri-push kohta.<\/li>\n<li>Pealkirjad edastatakse tekstina.<\/li>\n<\/ul>\n<p>\nKui serveri-push on kuidagi realiseeritud WebSocketi protokolli abil, siis teiste probleemidega pidi tegelema radikaalsemalt.<\/p>\n<h2>Veidi t\u00e4nap\u00e4evasust: HTTP\/2<\/h2>\n<p>\n2012. aastal alustas Google'i meeskond SPDY protokolli arendamist (selgub h\u00e4\u00e4ldus \u00abspeedy\u00bb). Protokoll pidi lahendama HTTP\/1.1 peamised probleemid, s\u00e4ilitades samal ajal tagurpidise \u00fchilduvuse. 2015. aastal tutvustas IETF-i t\u00f6\u00f6r\u00fchm HTTP\/2 spetsifikatsiooni, mis p\u00f5hineb SPDY protokollil. Siin on, millised erinevused olid HTTP\/2-l:<\/p>\n<ul>\n<li>Binaarne serialiseerimine.<\/li>\n<li>Mitme HTTP-p\u00e4ringu multitegemine \u00fches TCP-\u00fchenduses.<\/li>\n<li>Server-push t\u00f6\u00f6tas out of the box (ilma WebSocketita).<\/li>\n<\/ul>\n<p>\nProtokoll oli suur samm edasi. See on oluliselt <noindex><a rel=\"nofollow\" href=\"https:\/\/http2.akamai.com\/demo\">kiirem kui esimesel versioonil<\/a><\/noindex> ja ei n\u00f5ua mitmete TCP-\u00fchenduste loomist: k\u00f5ik p\u00e4ringud \u00fchele hostile multitegevatakse \u00fches. See t\u00e4hendab, et \u00fches \u00fchenduses on mitu nii-\u00f6elda streamingut, millest iga\u00fchel on oma ID. Boonusena on olemas serveri-push.<\/p>\n<p>Kuid multitegemine toob kaasa teise nurgakivi probleemi. Kujutage ette, et t\u00e4idame as\u00fcnkroonselt 5 p\u00e4ringut \u00fchele serverile. HTTP\/2 kasutamisel t\u00e4idatakse k\u00f5ik need p\u00e4ringud \u00fche TCP-\u00fchenduse raames ja see t\u00e4hendab, et kui \u00fcks segmente m\u00f5nest p\u00e4ringust kaob v\u00f5i tuleb vale, siis peatatakse k\u00f5igi p\u00e4ringute ja vastuste edastamine, kuni kadunud segment taastatakse. On ilmne, et mida halvem on \u00fchenduse kvaliteet, seda aeglasem on HTTP\/2. <noindex><a rel=\"nofollow\" href=\"https:\/\/http3-explained.haxx.se\/en\/why-tcphol.html\">Daniel Steinbergi hinnangul<\/a><\/noindex>, kui kadunud paketid moodustavad 2% k\u00f5igist, toimib HTTP\/1.1 brauseris paremini kui HTTP\/2, avades 6 \u00fchendust, mitte \u00fchte.<\/p>\n<p>Seda probleemi nimetatakse \"head-of-line blocking\" ja kahjuks ei ole selle lahendamine TCP kasutamisel v\u00f5imalik.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: alusm\u00fc\u00fcride purustamine ja imeline uus maailm\" src=\"\/wp-content\/uploads\/2019\/11\/234a6dc218a9acf8d2212fbdf28f2188.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Illustratsioon Daniel Steinberg<\/i><\/p>\n<p>Kokkuv\u00f5ttes on HTTP\/2 standardi arendajad teinud tohutut t\u00f6\u00f6d ja saavutanud peaaegu k\u00f5ike, mida OSI mudeli rakenduslikul tasemel saavutada oli v\u00f5imalik. Aeg on liikuda transporditasemele ja leiutada uus transpordiprotokoll.<\/p>\n<h2>Meile on vajalik uus protokoll: UDP vs TCP<\/h2>\n<p>\nJ\u00f5udis \u00fcsna kiiresti selgusele, et t\u00e4iesti uue transpordiprotokolli rakendamine on t\u00e4nases olukorras peaaegu v\u00f5imatu \u00fclesanne. Asi on selles, et transporditasemest teavad seadmed v\u00f5i keskmised kastid (ruuteri, tulem\u00fc\u00fcrid, NAT-serverid...). Uute teadmiste \u00f5petamine neile on \u00e4\u00e4rmiselt keeruline \u00fclesanne. Lisaks on transpordiprotokollide tugi sisseehitatud operatsioonis\u00fcsteemide tuumadesse ning tuumad ei muutu just v\u00e4ga kergek\u00e4eliselt.<\/p>\n<p>Siinkohal v\u00f5iks k\u00e4ed alla lasta ja \u00f6elda: \"Loomulikult leiutame me uue HTTP\/3 koos preference\u2019ide ja kurtizanidega, kuid selle rakendamine v\u00f5tab aega 10-15 aastat (umbes nii kaua on vaja, et suurem osa riistvarast asendataks)\", kuid on veel \u00fcks mitte k\u00f5ige ilmsem variant: kasutada UDP protokolli. Jah, just seda protokolli, millega me viskasime faile omavahel 90-ndate l\u00f5pus ja 2000-ndate alguses. Peaaegu k\u00f5ik t\u00e4nap\u00e4eva seadmed oskavad selle protsessiga t\u00f6\u00f6tada.<\/p>\n<p>Millised on UDP eelised TCP ees? Esiteks on meil puudus transporditaseme sessioonist, millest riistvara teab. See v\u00f5imaldab meil ise m\u00e4\u00e4rata sessiooni l\u00f5pp-punktides ja seal ka tekkinud konfliktid lahendada. See t\u00e4hendab, et me ei ole piiratud \u00fche v\u00f5i mitme sessiooniga (nagu TCP-s), vaid v\u00f5ime luua neid nii palju, kui me vajame. Teiseks on andmete edastamine UDP kaudu kiirem kui TCP kaudu. Seega teoreetiliselt saame me rikkuda t\u00e4nap\u00e4eva kiirusrekordeid, mis saavutati HTTP\/2-s. <\/p>\n<p>Kuid UDP ei garanteeri andmete edastamise usaldusv\u00e4\u00e4rsust. Tegelikult saadame lihtsalt pakette, lootes, et teisel pool nad k\u00e4tte saadakse. Ei saanud k\u00e4tte? Noh, ei vedanud... Sellest piisab t\u00e4iskasvanutele m\u00f5eldud videote edastamiseks, kuid t\u00f5sisemate asjade jaoks on vajalik usaldusv\u00e4\u00e4rsus, seega tuleb UDP-le midagi veel peale panna.<\/p>\n<p>Nagu HTTP\/2 puhul, algas uue protokolli loomise t\u00f6\u00f6 Google'is 2012. aastal, mis t\u00e4hendab, et see toimus umbes samal ajal, kui hakati t\u00f6\u00f6tama SPDY kallal. 2013. aastal tutvustas Jim Roskind laiemale avalikkusele <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.google.com\/document\/d\/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34\/edit\">protokolli QUIC (Quick UDP Internet Connections)<\/a><\/noindex>, kuid juba 2015. aastal tehti IETF-is standardiseerimise eesm\u00e4rgil Internet Draft. Juba tol ajal erines Google'is Rosskindi poolt v\u00e4lja t\u00f6\u00f6tatud protokoll oluliselt standardiks tehtud variandist, mist\u00f5ttu hakati Google'i versiooni kutsuma gQUIC-iks.<\/p>\n<h4>Mis on QUIC<\/h4>\n<p>\nEsiteks, nagu juba mainitud, on see UDP \u00fcmberk\u00fclge. UDP peale t\u00f5useb QUIC-\u00fchendus, mille sees, nagu HTTP\/2 puhul, v\u00f5ivad olla mitmed vood. Need vood eksisteerivad ainult l\u00f5pp-punktides ja neid teenindatakse iseseisvalt. Kui \u00fche voo paketid kaovad, ei m\u00f5juta see teisi.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: alusm\u00fc\u00fcride purustamine ja imeline uus maailm\" src=\"\/wp-content\/uploads\/2019\/11\/0a64aa26d9b8216db56d389fa48578a5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Illustratsioon Daniel Steinberg<\/i><\/p>\n<p>Teiseks, kr\u00fcpteerimine on n\u00fc\u00fcd rakendatud mitte eraldi tasemena, vaid sisalduse osana protokollis. See v\u00f5imaldab luua \u00fchenduse ja vahetada avalikke v\u00f5tmeid \u00fche k\u00e4epigistusega, samuti kasutada nutikat mehhanismi 0-RTT k\u00e4epigistus, et v\u00e4ltida viivitusi k\u00e4epigistuse ajal. Lisaks on n\u00fc\u00fcd v\u00f5imalik kr\u00fcpteerida eraldi andmepakette. See v\u00f5imaldab mitte oodata voost andmete vastuv\u00f5tmise l\u00f5petamist, vaid dekr\u00fcpteerida saadud pakkumisi iseseisvalt. Selline t\u00f6\u00f6re\u017eiim oli TCP-s \u00fcldse v\u00f5imatu, kuna TLS ja TCP t\u00f6\u00f6tasid iseseisvalt ning TLS ei teadnud, milliseid osi TCP andmeid l\u00f5ikab. Seega ei saanud TLS ette valmistada oma segmente, et need sobituksid TCP segmentidega \u00fcks \u00fchele ja saaksid iseseisvalt dekr\u00fcpteeritud. K\u00f5ik need t\u00e4iustused v\u00f5imaldavad QUIC-il v\u00e4hendada latentsusaega v\u00f5rreldes TCP-ga.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: alusm\u00fc\u00fcride purustamine ja imeline uus maailm\" src=\"\/wp-content\/uploads\/2019\/11\/cb3c522636f7a052a0f5988fe7ea3a65.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nKolmandaks, kergete voogude kontseptsioon v\u00f5imaldab siduda \u00fchenduse kliendi IP-aadressist. See on oluline n\u00e4iteks siis, kui klient vahetab \u00fche Wi-Fi p\u00e4\u00e4supunkti teiseks, muutes oma IP-d. Sel juhul toimub TCP kasutamisel pikk protsess, mille k\u00e4igus olemasolevad TCP-\u00fchendused katkestatakse aja\u00fclevaatuse t\u00f5ttu ja luuakse uued \u00fchendused uue IP-ga. QUIC-i puhul saadab klient lihtsalt serverile pakette uue IP-ga vanast voo ID-st. Kuna voo ID on n\u00fc\u00fcd ainulaadne ja seda ei kasutata uuesti, m\u00f5istab server, et klient on IP-d vahetanud, saadab kadunud paketid tagasi ja j\u00e4tkab suhtlust uuel aadressil.<\/p>\n<p>Neljandaks, QUIC rakendatakse rakenduse tasandil, mitte operatsioonis\u00fcsteemi tasandil. \u00dchelt poolt v\u00f5imaldab see protokolli kiiremini muuta, kuna uuenduse saamiseks piisab lihtsalt teegi v\u00e4rskendamisest, mitte uue operatsioonis\u00fcsteemi versiooni ootamisest. Teiselt poolt viib see tugevalt protsessori tarbimise suurenemiseni.<\/p>\n<p>Ja viimasena, pealkirjad. Pealkirjade kokkusurumine on just see, mis erineb QUIC-is ja gQUIC-is. Ma ei n\u00e4e m\u00f5tet sellele palju aega p\u00fchendada, \u00fctleksin vaid, et standardiseerimisele esitatud versioonis tehti pealkirjade kokkusurumine maksimaalselt sarnaseks HTTP\/2 pealkirjade kokkusurumisele. Rohkem saab lugeda <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">siin<\/a><\/noindex>.<\/p>\n<h4>Kui palju see kiiremini on?<\/h4>\n<p>\nSee on keeruline k\u00fcsimus. Asi on selles, et hetkel pole meil standardit, seega pole ka eriti midagi m\u00f5\u00f5ta. T\u00f5en\u00e4oliselt on ainsad statistilised andmed, millega me disposineme, Google'i statistika, kes on kasutanud gQUIC-i alates 2013. aastast ning 2016. aastal <noindex><a rel=\"nofollow\" href=\"https:\/\/www.ietf.org\/proceedings\/96\/slides\/slides-96-quic-3.pdf\">raporteeris IETF-ile<\/a><\/noindex>, et umbes 90% nende serveritesse Chrome'i brauserist suunatavast liiklusest kasutab n\u00fc\u00fcd QUIC-it. Samas esituses teatavad nad, et gQUIC abil laaditakse lehti umbes 5% kiiremini ning voogesituse videos on katkestusi 30% v\u00e4hem v\u00f5rreldes TCP-ga. <\/p>\n<p>2017. aastal avaldas uurijate grupp, mille juhiks oli Arash Molavi Kakhki, <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">suure t\u00f6\u00f6<\/a><\/noindex> uurimuse gQUIC sooritusv\u00f5ime kohta v\u00f5rreldes TCP-ga. <br \/>\nUuring tuvastas mitmeid gQUIC-i n\u00f5rkusi, nagu v\u00f5rgupakettide segunemisele vastupidamatust, kanalite l\u00e4bilaskev\u00f5imele ebaeetilisust ja v\u00e4ikeste (kuni 10 kB) objektide aeglasemat edastamist. Viimast suudetakse siiski kompenseerida 0-RTT kasutamisega. K\u00f5ikidel teistel uuritud juhtudel n\u00e4itas gQUIC TCP-ga v\u00f5rreldes kiiruset\u00f5usu. Konkreetsetest numbritest siin r\u00e4\u00e4kida on keeruline. Parim on lugeda <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">uurimust ennast<\/a><\/noindex> v\u00f5i <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.apnic.net\/2018\/01\/29\/measuring-quic-vs-tcp-mobile-desktop\/\">l\u00fchikest postitust<\/a><\/noindex>.<\/p>\n<p>Siin on oluline m\u00e4rkida, et need andmed puudutavad just gQUIC-i ning ei ole asjakohased arendatava standardi jaoks. Mis QUIC-i puudutab: see j\u00e4\u00e4b veel saladuseks, kuid on lootust, et gQUIC-is tuvastatud n\u00f5rkused v\u00f5etakse arvesse ja parandatakse.<\/p>\n<h2>Veidi tulevikust: mis saab HTTP\/3-st?<\/h2>\n<p>\nSiin on k\u00f5ik kristalselt selge: API ei muutu kuidagi. K\u00f5ik j\u00e4\u00e4b t\u00e4pselt samaks nagu see oli HTTP\/2-s. Kui API j\u00e4\u00e4b samaks, peab HTTP\/3-le \u00fcleminek toimuma uusima raamatukogu versiooni kasutuselev\u00f5tu kaudu, mis toetab transporti QUIC-i kaudu. T\u00f5si, \u00fcsna kaua tuleb veel s\u00e4ilitada tagasip\u00f6\u00f6rdumise v\u00f5imalus vanadele HTTP versioonidele, kuna internet ei ole praegu valmis t\u00e4ielikuks \u00fcleminekuks UDP-le.<\/p>\n<h4>Kes juba toetab<\/h4>\n<p>\nSiin <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/quicwg\/base-drafts\/wiki\/Implementations\">nimekiri<\/a><\/noindex> olemasolevaid QUIC rakendusi. Vaatamata standardi puudumisele, on nimekiri \u00fcsna hea. <\/p>\n<p>Praegu ei toeta \u00fckski brauser QUIC-i tootmisversioonis. Ehkki hiljuti oli teavet, et Chrome on lisanud HTTP\/3 toe, on see siiski vaid Canary versioonis. <\/p>\n<p>HTTP\/3 toetab praegu ainult <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/caddyserver\/caddy\">Caddy<\/a><\/noindex> ja <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/http3-the-past-present-and-future\/\">Cloudflare<\/a><\/noindex>, kuid veel katsetamiseks. NGINX alustas HTTP\/3 toe arendamist 2019. aasta kevadel, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.nginx.com\/blog\/nginx-1-16-1-17-released\/\">et neil on alles ainult kaks plokki \/8.<\/a><\/noindex>, kuid ei ole veel l\u00f5petanud.<\/p>\n<h4>Millised on probleemid<\/h4>\n<p>\nMe elame reaalne elu, kus \u00fckski suur tehnoloogia ei saa massidesse murda, ilma et kohtaks vastuolu, ja QUIC ei ole siin erand.<\/p>\n<p>K\u00f5ige olulisem on kuidagi seletada brauserile, et \"https:\/\/\" ei pruugi n\u00fc\u00fcd t\u00e4hendada, et see l\u00e4heb 443. TCP porti. Seal ei pruugi \u00fcldse olla TCP-d. Selleks kasutatakse Alt-Svc p\u00e4ist. See v\u00f5imaldab brauserile \u00f6elda, et see veebisait on saadaval ka sellise protokolli kaudu sellises aadressis. Teoreetiliselt peaks see t\u00f6\u00f6tama nagu kell, kuid praktiliselt v\u00f5ime kokku puutuda sellega, et UDP v\u00f5ib olla n\u00e4iteks tulem\u00fc\u00fcris keelatud DDoS r\u00fcnnakute v\u00e4ltimiseks.<\/p>\n<p>Kuid isegi kui UDP-d ei ole keelatud, v\u00f5ib klient olla NAT-ruuteri taga, mis on seadistatud TCP sessiooni hoidmiseks IP-aadressi j\u00e4rgi, ja kuna me kasutame UDP-d, milles ei ole riistvaralist sessiooni, ei hoia NAT \u00fchendust ja QUIC sessioon <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">katkeb pidevalt.<\/a><\/noindex>. <\/p>\n<p>K\u00f5ik need probleemid on seotud sellega, et UDP-d ei ole varem kasutatud internetisisu edastamiseks ja riistvaratootjad ei osanud ette n\u00e4ha, et selline asi kunagi juhtub. Samuti ei m\u00f5ista administraatorid veel p\u00e4ris h\u00e4sti, kuidas \u00f5igesti seadistada oma v\u00f5rgud QUIC t\u00f6\u00f6tamiseks. See olukord hakkab aeglaselt muutuma ja igal juhul v\u00f5tavad sellised muudatused v\u00e4hem aega kui uue transporditasandi protokolli juurutamine. <\/p>\n<p>Lisaks suurendab QUIC oluliselt protsessori kasutust, nagu juba kirjeldatud. Daniel Stenberg <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=idViw4anA6E\">hindas<\/a><\/noindex> protsessori kasvu kolmekordseks.<\/p>\n<h4>Millal saabub HTTP\/3<\/h4>\n<p>\nStandard <noindex><a rel=\"nofollow\" href=\"https:\/\/datatracker.ietf.org\/wg\/quic\/about\/\">soovivad vastu v\u00f5tta.<\/a><\/noindex> 2020. aasta maiks, kuid arvestades, et hetkel on siiski valmis saamata dokumendid, mis on planeeritud 2019. aasta juuliks, v\u00f5ib \u00f6elda, et kuup\u00e4eva t\u00f5en\u00e4oliselt edasi l\u00fckatakse.<\/p>\n<p>Google on oma gQUIC rakendust kasutanud alates 2013. aastast. Kui vaadata HTTP-p\u00e4ringut, mis saadetakse Google'i otsingumootorisse, v\u00f5ib n\u00e4ha j\u00e4rgmist:<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: alusm\u00fc\u00fcride purustamine ja imeline uus maailm\" src=\"\/wp-content\/uploads\/2019\/11\/af422268eb85b488c7be1b70c6d33fad.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>J\u00e4reldused<\/h2>\n<p>\nQUIC n\u00e4ib olevat hetkel \u00fcsna toores, kuid v\u00e4ga perspektiivikas tehnoloogia. Arvestades, et viimased 20 aastat on k\u00f5ik transporditase protokollide optimeerimised p\u00f5hinenud peamiselt TCP-l, paistab QUIC, mis suurendab j\u00f5udlust, juba praegu v\u00e4ga h\u00e4sti. <\/p>\n<p>Kuid siiski j\u00e4\u00e4vad lahendamata probleemid, millega tuleb l\u00e4hiaastatel tegeleda. Protsess v\u00f5ib venida, kuna on seotud riistvara, mida keegi ei armasta uuendada, kuid siiski tunduvad k\u00f5ik probleemid t\u00e4iesti lahendatavad ja varem v\u00f5i hiljem on meil k\u00f5igil HTTP\/3. <\/p>\n<p>Tulevik on juba l\u00e4hedal!<br \/>\n<br \/>Allikas: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dodopizzaio\/blog\/473930\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u043e\u0442 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 20 \u043b\u0435\u0442 \u043c\u044b \u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0432\u0435\u0431-\u0441\u0442\u0440\u0430\u043d\u0438\u0447\u043a\u0438 \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 HTTP. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0435 \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u0438 \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442. \u0414\u0440\u0443\u0433\u0438\u0435 \u0437\u043d\u0430\u044e\u0442, \u0447\u0442\u043e \u0433\u0434\u0435-\u0442\u043e \u043f\u043e\u0434 HTTP \u0435\u0441\u0442\u044c TLS, \u0430 \u043f\u043e\u0434 \u043d\u0438\u043c TCP, \u043f\u043e\u0434 \u043a\u043e\u0442\u043e\u0440\u044b\u043c IP \u0438 \u0442\u0430\u043a \u0434\u0430\u043b\u0435\u0435. \u0410 \u0442\u0440\u0435\u0442\u044c\u0438 \u2013 \u0435\u0440\u0435\u0442\u0438\u043a\u0438 \u2013 \u0441\u0447\u0438\u0442\u0430\u044e\u0442, \u0447\u0442\u043e TCP \u2013 \u044d\u0442\u043e \u043f\u0440\u043e\u0448\u043b\u044b\u0439 \u0432\u0435\u043a, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-52181","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u043e\u0442 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 20 \u043b\u0435\u0442 \u043c\u044b \u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0432\u0435\u0431-\u0441\u0442\u0440\u0430\u043d\u0438\u0447\u043a\u0438 \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 HTTP. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0435 \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u0438 \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47HTTP\/3: \u0440\u0430\u0437\u0440\u0443\u0448\u0435\u043d\u0438\u0435 \u043e\u0441\u043d\u043e\u0432 \u0438 \u0434\u0438\u0432\u043d\u044b\u0439 \u043d\u043e\u0432\u044b\u0439 \u043c\u0438\u0440 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u043e\u0442 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 20 \u043b\u0435\u0442 \u043c\u044b \u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0432\u0435\u0431-\u0441\u0442\u0440\u0430\u043d\u0438\u0447\u043a\u0438 \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 HTTP. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0435 \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u0438 \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-11-01T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T10:59:51+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47HTTP\/3: alusm\u00fc\u00fcride purustamine ja imeline uus maailm | ProHoster","description":"Juba \u00fcle 20 aasta vaatame veebilehti HTTP protokolli kaudu. Enamik kasutajaid ei m\u00f5tle \u00fcldse sellele, mis see on ja kuidas see t\u00f6\u00f6tab.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47HTTP\/3: \u0440\u0430\u0437\u0440\u0443\u0448\u0435\u043d\u0438\u0435 \u043e\u0441\u043d\u043e\u0432 \u0438 \u0434\u0438\u0432\u043d\u044b\u0439 \u043d\u043e\u0432\u044b\u0439 \u043c\u0438\u0440 | ProHoster","og:description":"\u0412\u043e\u0442 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 20 \u043b\u0435\u0442 \u043c\u044b \u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0432\u0435\u0431-\u0441\u0442\u0440\u0430\u043d\u0438\u0447\u043a\u0438 \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 HTTP. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0435 \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u0438 \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442.","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-11-01T21:00:00+00:00","article:modified_time":"2020-02-18T10:59:51+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"52181","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 02:46:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:48:31","updated":"2026-01-24 02:46:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/52181","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=52181"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/52181\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=52181"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=52181"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=52181"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}