{"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: aluste h\u00e4ired ja ilus uus maailm","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Oleme juba rohkem kui 20 aastat sirvinud veebilehti HTTP protokolli kaudu. Enamik kasutajatest ei m\u00f5tle sellele, mis see on ja kuidas see t\u00f6\u00f6tab. Teised teavad, et HTTP all on TLS, selle all TCP, mille all on IP ja nii edasi. Ja kolmandad \u2013 erahoolikud \u2013 usuvad, et TCP on minevik, nad tahavad midagi kiiremat, usaldusv\u00e4\u00e4rsemat ja turvalisemat. Kuid oma katsetes leiutada uus ideaalne protokoll on nad naasnud 80-ndate tehnoloogiate juurde ja p\u00fc\u00fcavad nende p\u00f5hjal luua oma imelise uue maailma.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: aluste h\u00e4ired ja ilus 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 informatsiooni edastamise protokoll HTTP versioon 1.1 oma RFC. Sel hetkel oli protokoll olnud juba mitu aastat brauserites kasutusel ja uus standard p\u00fcsis veel viisteist aastat. Protokoll toimis ainult p\u00e4ringu-vastuse p\u00f5him\u00f5ttel ning oli peamiselt m\u00f5eldud tekstilise informatsiooni edastamiseks.<\/p>\n<p>HTTP projekteeriti t\u00f6\u00f6tama TCP protokolli kohal, mis tagab pakettide usaldusv\u00e4\u00e4rse edastamise sihtkohta. TCP t\u00f6\u00f6 p\u00f5hineb usaldusv\u00e4\u00e4rse \u00fchenduse loomisel ja s\u00e4ilitamisel l\u00f5pp-punktide vahel ning liikluse jagamisel segmentideks. Segmentidel on oma j\u00e4rjestusnumber ja kontrollsumma. Kui m\u00f5ni segment ei j\u00f5ua kohale v\u00f5i j\u00f5uab vale kontrollsummaga, siis edastus peatub, kuni kadunud segment on taastatud.<\/p>\n<p>HTTP\/1.0 puhul suleti TCP-\u00fchendus p\u00e4rast iga p\u00e4ringut. See oli \u00e4\u00e4rmiselt raiskav, kuna TCP-\u00fchenduse loomine (3-Way-Handshake) on aeglane protsess. HTTP\/1.1-s tutvustati keep-alive mehhanismi, mis v\u00f5imaldab kasutada sama \u00fchendust mitme p\u00e4ringu jaoks. Kuid kuna see v\u00f5ib kergesti muutuda pudelikaelaks, lubatakse erinevates implementatsioonides HTTP\/1.1 avada mitu TCP-\u00fchendust \u00fche hostiga. N\u00e4iteks Chrome'is ja viimastes Firefox'i versioonides on lubatud kuni kuus \u00fchendust.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: aluste h\u00e4ired ja ilus 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, ja selle jaoks hakati TCP kohal kasutama TLS protokolli, mis kaitses andmeid usaldusv\u00e4\u00e4rselt, kuid suurendas oluliselt aega, mis oli vajalik \u00fchenduse loomisele. Tulemuseks sai k\u00e4epigistuse protsess v\u00e4lja n\u00e4ha selline:<br \/>\n <img decoding=\"async\" alt=\"HTTP\/3: aluste h\u00e4ired ja ilus uus maailm\" src=\"\/wp-content\/uploads\/2019\/11\/2fdccf56e0ed29444557836fdc65351b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Illustratsioon Cloudflare<\/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, mist\u00f5ttu piltide, videote ja muu mitte-tekstilise informatsiooni edastamine on ebaefektiivne.<\/li>\n<li>\u00dcks TCP-\u00fchendus kasutatakse \u00fche p\u00e4ringu jaoks, mis t\u00e4hendab, et \u00fclej\u00e4\u00e4nud p\u00e4ringud peavad kas leidma endale muu \u00fchenduse v\u00f5i ootama, kuni praegune p\u00e4ring j\u00e4tab selle vabaks.<\/li>\n<li>Toetatakse ainult pull-mudelit. Standardis pole midagi serveri-push kohta.<\/li>\n<li>Pealkirjad edastatakse tekstina.<\/li>\n<\/ul>\n<p>\nKui serveri-push'i suudetakse mingil m\u00e4\u00e4ral rakendada WebSocketi protokolli abil, siis teiste probleemidega pidi tegelema radikaalselt.<\/p>\n<h2>Veidi t\u00e4nap\u00e4evast: HTTP\/2<\/h2>\n<p>\n2012. aastal hakkas Google'is t\u00f6\u00f6tama protokolli SPDY kallal (h\u00e4\u00e4ldatakse kui 'spidi'). Protokoll pidi lahendama HTTP\/1.1 peamised probleemid, s\u00e4ilitades samal ajal tagurpidi \u00fchilduvuse. Aastal 2015 esitas IETF t\u00f6\u00f6grupp HTTP\/2 spetsifikatsiooni, mis p\u00f5hines SPDY-l. Siin on, millised olid HTTP\/2 erinevused:<\/p>\n<ul>\n<li>Binaarne serialiseerimine.<\/li>\n<li>Mitme HTTP-p\u00e4ringu multiploiseerimine \u00fchte TCP-\u00fchendusse.<\/li>\n<li>Serveri-push karbist v\u00e4ljas (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\">kiire, kui v\u00f5rrelda esimest versiooni<\/a><\/noindex> ja ei n\u00f5ua mitme TCP-\u00fchenduse loomist: k\u00f5ik p\u00e4ringud \u00fchele hostile multiploiseeritakse \u00fchte. See t\u00e4hendab, et \u00fches \u00fchenduses on mitu nn voogu, iga\u00fchel on oma ID. Boonusena tuleb karbist v\u00e4ljas serveri-push.<\/p>\n<p>Siiski toob multiploiseerimine esile teise p\u00f5hiprobleemi. Kujutage ette, et teeme as\u00fcnkroonselt 5 p\u00e4ringut \u00fchele serverile. HTTP\/2 puhul t\u00e4idetakse k\u00f5ik need p\u00e4ringud \u00fche TCP-\u00fchenduse raames, seega kui m\u00f5ni segment mis tahes p\u00e4ringust kaob v\u00f5i j\u00f5uab vale, peatub k\u00f5ikide p\u00e4ringute ja vastuste edastamine, kuni kadunud segment on taastatud. Ilmselgelt, mida halvem on \u00fchenduse kvaliteet, seda aeglasemalt t\u00f6\u00f6tab HTTP\/2. <noindex><a rel=\"nofollow\" href=\"https:\/\/http3-explained.haxx.se\/en\/why-tcphol.html\">Daniel Steinbergi hinnangul<\/a><\/noindex>, kui kaotatud paketid moodustavad 2% k\u00f5igist, siis HTTP\/1.1 k\u00e4itub brauseris paremini kui HTTP\/2, kuna see avab 6 \u00fchendust, mitte \u00fchte.<\/p>\n<p>Seda probleemi nimetatakse 'head-of-line blocking' ja kahjuks pole selle lahendamine TCP kasutamisel v\u00f5imalik.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: aluste h\u00e4ired ja ilus 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 suure t\u00f6\u00f6 ning saavutanud praktiliselt k\u00f5ik, mis on v\u00f5imalik OSI mudeli rakendustasandil. On aeg liikuda transporttase ja leiutada uus transportprotokoll.<\/p>\n<h2>Me vajame uut protokolli: UDP vs TCP<\/h2>\n<p>\nTuli \u00fcsna kiiresti selgeks, et t\u00e4iesti uue transpordiprotokolli rakendamine on t\u00e4naste olude juures peaaegu v\u00f5imatu \u00fclesanne. Asi on selles, et transporditasemest teavad seadmed v\u00f5i vahekatked (ruuterid, tulem\u00fc\u00fcrid, NAT-serverid\u2026), ja nende uute teadmiste omandamine on \u00e4\u00e4rmiselt keeruline. Lisaks on transpordiprotokollide tugi sisse koe-operatsioonis\u00fcsteemide tuumadesse, ja tuumad ei muutu just meelsasti.<\/p>\n<p>Siin v\u00f5iks k\u00e4ed alla anda ja \u00f6elda: \"Me leiutame kindlasti uue HTTP\/3 koos lugupeetud ja kaunitaridega, kuid selle rakendamine v\u00f5tab 10-15 aastat (umbes nii kaua v\u00f5tab aega enamus riistvara asendamine)\". K\u00fcll aga on veel \u00fcks mitte k\u00f5ige ilmsem variant: kasutada UDP protokolli. Jah, see sama protokoll, millega me saatsime faile kohalikus v\u00f5rgus 90ndate l\u00f5pus ja 2000ndate alguses. Peaaegu k\u00f5ik t\u00e4nap\u00e4eva seadmed oskavad sellega t\u00f6\u00f6tada.<\/p>\n<p>Mis on UDP eelised v\u00f5rreldes TCP-ga? Esiteks, meil ei ole transporttase sessiooni, millest riistvara teab. See v\u00f5imaldab meil ise m\u00e4\u00e4rata sessiooni l\u00f5pp-punktides ja seal lahendada tekkivaid konflikte. See t\u00e4hendab, et me ei ole piiratud \u00fche v\u00f5i mitme sessiooniga (nagu TCP), vaid saame luua neid nii palju, kui soovime. Teiseks, andmete edastamine UDP kaudu toimub kiiremini kui TCP kaudu. Nii et teoorias suudame me \u00fcletada t\u00e4nase HTTP\/2 kiiruspiiri. <\/p>\n<p>Kuid UDP ei garanteeri andmeedastuse usaldusv\u00e4\u00e4rsust. Tegelikult saadame me lihtsalt pakette, lootes, et teisel pool need k\u00e4tte saadakse. Kui ei saadud? Tundub, et ei vedanud... Selleks, et edastada t\u00e4iskasvanute video, oli seda piisavalt, kuid t\u00f5sisemate asjade jaoks on vajalik usaldusv\u00e4\u00e4rsus, seega tuleb midagi veel UDP peale lisada.<\/p>\n<p>Nagu HTTP\/2 puhul, algas uue protokolli loomine Google'is 2012. aastal, umbes samal ajal kui SPDY arendamine. 2013. aastal esitles Jim Roskind seda laiemale avalikkusele. <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.google.com\/document\/d\/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34\/edit\">protokoll QUIC (Quick UDP Internet Connections)<\/a><\/noindex>, ning juba 2015. aastal tehti Interneti kavand standardimiseks IETF-is. Juba tol ajal erines Google'is loodud protokoll Roskindi poolt oluliselt standardisse viidud versioonist, mist\u00f5ttu hakati Google'i versiooni nimetama gQUIC-iks.<\/p>\n<h4>Mis on QUIC?<\/h4>\n<p>\nEsiteks, nagu juba \u00f6eldud, on see UDP \u00fcmberpakendamine. UDP kohal tekib QUIC-\u00fchendus, milles v\u00f5ivad eksisteerida mitu voogu, nagu HTTP\/2 puhul. Need vood eksisteerivad ainult l\u00f5pp-punktides ja teenindatakse iseseisvalt. Kui paketi kaotus tekib \u00fches voos, ei m\u00f5juta see teisi.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: aluste h\u00e4ired ja ilus 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 integreeritud protokolli, mitte eraldi tasemena. See v\u00f5imaldab luua \u00fchenduse ja vahetada avalike v\u00f5tmeid \u00fches k\u00e4epigistuses, samuti v\u00f5imaldab see kasutada nutikat mehhanismi 0-RTT k\u00e4epigistus, v\u00e4ltides viivitusi k\u00e4epigistuste ajal. Lisaks on n\u00fc\u00fcd v\u00f5imalik kr\u00fcpteerida \u00fcksikuid andmepakette. See t\u00e4hendab, et ei pea ootama voost andmete vastuv\u00f5tmise l\u00f5petamist, vaid valmisk\u00e4rbed saadud paketid iseseisvalt. Selline t\u00f6\u00f6re\u017eiim oli TCP-s t\u00e4iesti v\u00f5imatu, kuna TLS ja TCP t\u00f6\u00f6tasid iseseisvalt ning TLS ei teadnud, millisteks t\u00fckkideks TCP andmeid jagab. Seega ei saanud TLS oma segmente ette valmistada nii, et need mahuksid TCP segmente \u00fchte ja saaksid iseseisvalt dekodeerida. K\u00f5ik need t\u00e4iustused v\u00f5imaldavad QUIC-il v\u00e4hendada latentsust v\u00f5rreldes TCP-ga.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: aluste h\u00e4ired ja ilus 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 lahti. See on oluline n\u00e4iteks siis, kui klient vahetab \u00fche Wi-Fi juurdep\u00e4\u00e4supunkti teise, muutes oma IP-d. Sellisel juhul, kui kasutatakse TCP-d, toimub pikk protsess, mille k\u00e4igus olemasolevad TCP-\u00fchendused l\u00e4hevad ajavahemiku t\u00f5ttu puruks ja uued \u00fchendused luuakse uue IP-ga. QUIC puhul saadab klient lihtsalt pakette serverile uue IP-ga vana voo ID-ga. Kuna voo ID on n\u00fc\u00fcd ainulaadne ja seda ei taaskasutata, m\u00f5istab server, et klient on IP-d vahetanud, saadab kaotatud paketid teele ja j\u00e4tkab suhtlust uuel aadressil.<\/p>\n<p>Neljandaks, QUIC rakendatakse rakenduslootel, mitte operatsioonis\u00fcsteemis. See v\u00f5imaldab protokolli kiiremini muuta, kuna v\u00e4rskenduse saamiseks piisab lihtsalt teegi uuendamisest, mitte uue OS-i versiooni ootamisest. Teiselt poolt p\u00f5hjustab see protsessori kasutamise m\u00e4rkimisv\u00e4\u00e4rset suurenemist.<\/p>\n<p>Ja viimaseks, pealkirjad. Pealkirjade kompressioon seondub just nendele erinevustele QUIC-is ja gQUIC-is. Ei n\u00e4e m\u00f5tet sellele palju aega p\u00fchendada, \u00fctlen vaid, et standardiseerimiseks esitatud versioonis tehti pealkirjade kompressioon v\u00f5imalikult sarnaseks HTTP\/2-s kasutatavale kompressioonile. Rohkem saab lugeda <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">siit<\/a><\/noindex>.<\/p>\n<h4>Kui palju kiiremini see on?<\/h4>\n<p>\nSee on keeruline k\u00fcsimus. Asi on selles, et hetkel meil ei ole standardit, midagi pole m\u00f5\u00f5ta. T\u00f5en\u00e4oliselt on ainsad statistilised andmed, millega me ei saa arvestada, Google'i statistika, kes on gQUIC-i kasutanud alates 2013. aastast ja 2016 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.ietf.org\/proceedings\/96\/slides\/slides-96-quic-3.pdf\">raportit IETF-ile<\/a><\/noindex>, et umbes 90% Chrome'i brauserist nende serveritesse suunduvalt liiklusest kasutab n\u00fc\u00fcd QUIC-i. Samas esitlusel teatatakse, et gQUIC-is laaditakse lehed umbes 5% kiiremini ja voogedastuse videos on 30% v\u00e4hem viivitusi v\u00f5rreldes TCP-iga. <\/p>\n<p>2017. aastal avaldas Arash Molavi Kakhki juhtimisel uurijate r\u00fchm <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">suure t\u00f6\u00f6<\/a><\/noindex> uuringu gQUIC-i ja TCP vahelise j\u00f5udluse v\u00f5rdlemiseks. <br \/>\nUuring t\u00f5i esile mitmeid gQUIC-i n\u00f5rkusi, nagu v\u00f5imetus v\u00f5rgu pakette segada, kanalite l\u00e4bilaskev\u00f5ime ebaausus ja v\u00e4ikeste (kuni 10 kb) objektide aeglasem edastamine. Viimast saame siiski kompenseerida 0-RTT kasutamisega. K\u00f5igis teistes uuritud juhtumites n\u00e4itas gQUIC kiiruselist t\u00f5usu v\u00f5rreldes TCP-ga. Konkreetsetes numbrites on siin raske r\u00e4\u00e4kida. Parim on lugeda <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">uurimist\u00f6\u00f6d<\/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>Siinkohal tuleb \u00f6elda, et need andmed puudutavad just gQUIC-i ja need ei ole aktuaalsed v\u00e4ljat\u00f6\u00f6tatava standardi jaoks. Mis juhtub QUIC-iga: see on praegu seitsme pitseri taga saladus, kuid on lootust, et gQUIC-is avastatud n\u00f5rkused v\u00f5etakse arvesse ja parandatakse.<\/p>\n<h2>Veidi tulevikku: mis saab HTTP\/3-st?<\/h2>\n<p>\nSiin on k\u00f5ik kristalselt selge: API ei muutu. K\u00f5ik j\u00e4\u00e4b t\u00e4pselt samaks nagu HTTP\/2-s. Kui API j\u00e4\u00e4b samaks, peab \u00fcleminek HTTP\/3-le toimuma v\u00e4rskete teekide versioonide kasutuselev\u00f5tuga, mis toetavad QUIC-i transporti. Kuid \u00fcsna kaua tuleb endiselt hoida tagasip\u00f6\u00f6rdeid vanadele HTTP-versioonidele, kuna internet ei ole praegu valmis t\u00e4ielikuks \u00fcleminekuks UDP-le.<\/p>\n<h4>Kes juba toetab<\/h4>\n<p>\nSiin on <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/quicwg\/base-drafts\/wiki\/Implementations\">nimekiri<\/a><\/noindex> olemasolevaid QUIC-i rakendusi. Malasi puudumise t\u00f5ttu on loetelu siiski tubli. <\/p>\n<p>Praegu ei toeta \u00fckski brauser QUIC-i avalikus versioonis. Hiljuti tuli teade, et Chrome'is on lisatud HTTP\/3 tugi, kuid praegu ainult Canary versioonis. <\/p>\n<p>Tagapool toetab HTTP\/3 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 praegu eksperimentaalselt. NGINX teatas 2019. aasta kevadel, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.nginx.com\/blog\/nginx-1-16-1-17-released\/\">teatasid<\/a><\/noindex>et nad on alustanud HTTP\/3 toe arendamist, kuid pole veel l\u00f5petanud.<\/p>\n<h4>Millised probleemid on<\/h4>\n<p>\nElame t\u00f5eliselt maailmas, kus \u00fckski suur tehnoloogia ei saa massidesse minna, ilma et see kohtuks vastupanuga, ja QUIC ei ole erand.<\/p>\n<p>K\u00f5ige olulisem on kuidagi brauserile selgitada, et \"https:\/\/\" ei t\u00e4henda enam tingimata 443. TCP-porti. Seal ei pruugi TCP-d \u00fcldse olla. Selleks kasutatakse Alt-Svc pealkirja. See v\u00f5imaldab teavitada brauserit, et see veebileht on saadaval ka mingil protokollil teatud aadressil. Teoorias peaks see t\u00f6\u00f6tama nagu kellav\u00e4rk, kuid praktikas v\u00f5ime kokku puutuda olukordadega, kus UDP on 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 s\u00e4ilitama TCP-seanssi IP-aadressi kaudu, ja kuna me kasutame UDP-d, kus ei ole riistvaralist seanssi, ei hoia NAT \u00fchendust ja QUIC-seanss <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">katkestub pidevalt.<\/a><\/noindex>. <\/p>\n<p>Need probleemid on seotud sellega, et UDP-d pole enne interneti sisu edastamiseks kasutatud ja riistvara tootjad ei suutnud ette n\u00e4ha, et see kunagi juhtub. Samuti ei m\u00f5ista administraatorid praegu eriti h\u00e4sti, kuidas oma v\u00f5rke \u00f5igesti seadistada, et QUIC toimiks. See olukord muutub j\u00e4rk-j\u00e4rgult, ja igal juhul v\u00f5tab sarnaste muudatuste tegemine v\u00e4hem aega kui uue transportprotokolli rakendamine. <\/p>\n<p>Lisaks, nagu juba mainitud, suurendab QUIC oluliselt protsessori kasutamist. Daniel Stenberg <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=idViw4anA6E\">hindas<\/a><\/noindex> protsessori kasvu kuni kolme korda.<\/p>\n<h4>Kui HTTP\/3 tuleb<\/h4>\n<p>\nStandart <noindex><a rel=\"nofollow\" href=\"https:\/\/datatracker.ietf.org\/wg\/quic\/about\/\">kavatsevad nad vastu v\u00f5tta<\/a><\/noindex> maiks 2020, kuid arvestades, et hetkel j\u00e4\u00e4vad juuli 2019 plaanitud dokumendid l\u00f5petamata, v\u00f5ib \u00f6elda, et kuup\u00e4eva t\u00f5en\u00e4oliselt edasi l\u00fckatakse.<\/p>\n<p>Aga Google kasutab oma gQUIC rakendust alates 2013. aastast. Kui vaadata HTTP-p\u00e4ringut, mis saadetakse Google'i otsingumootorile, v\u00f5ib n\u00e4ha j\u00e4rgmist:<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: aluste h\u00e4ired ja ilus 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\u00e4eb praegu v\u00e4lja kui suhteliselt toores, kuid v\u00e4ga paljut\u00f5otav tehnoloogia. Arvestades, et viimased 20 aastat on k\u00f5ik transpordikihtide protokollide optimeerimised peamiselt k\u00e4sitlenud TCP-d, tundub QUIC, mis enamasti pakub paremat j\u00f5udlust, juba praegu suurep\u00e4rasena. <\/p>\n<p>Siiski j\u00e4\u00e4vad veel lahendamata probleemid, millega tuleb l\u00e4hiaastatel tegeleda. Protsess v\u00f5ib viibida, kuna tegeletakse riistvaraga, mille uuendamine ei ole kellegi seas populaarne, ent k\u00f5ik probleemid n\u00e4ivad siiski olevat lahendatavad, ja varem v\u00f5i hiljem on HTTP\/3 k\u00f5igile meie seas. <\/p>\n<p>Tulevik on 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.0.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.0.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: aluste l\u00f5hkumine ja imeline uus maailm | ProHoster","description":"Juba \u00fcle 20 aasta sirvime veebilehti HTTP protokolli kaudu. Enamik kasutajatest 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}]}}