{"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\/hu\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","title":{"rendered":"HTTP\/3: Alapok rombol\u00e1sa \u00e9s csod\u00e1latos \u00faj vil\u00e1g","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>M\u00e1r t\u00f6bb mint 20 \u00e9ve b\u00f6ng\u00e9sz\u00fcnk weboldalakat HTTP protokollon kereszt\u00fcl. A legt\u00f6bb felhaszn\u00e1l\u00f3 egy\u00e1ltal\u00e1n nem gondol arra, hogy mi ez \u00e9s hogyan m\u0171k\u00f6dik. M\u00e1sok tudj\u00e1k, hogy a HTTP alatt van a TLS, alatta pedig a TCP, azt\u00e1n j\u00f6n az IP, \u00e9s \u00edgy tov\u00e1bb. \u00c9s vannak harmadik, eretnek gondolkod\u00e1s\u00faak, akik azt hiszik, hogy a TCP a m\u00falt\u00e9, \u00e9s valami gyorsabbra, megb\u00edzhat\u00f3bbra \u00e9s biztons\u00e1gosabbra v\u00e1gynak. De k\u00eds\u00e9rleteikben, hogy \u00faj, t\u00f6k\u00e9letes protokollt alkossanak, visszat\u00e9rtek a nyolcvanas \u00e9vek technol\u00f3gi\u00e1ihoz, \u00e9s azon pr\u00f3b\u00e1lnak meg fel\u00e9p\u00edteni egy csod\u00e1latos \u00faj vil\u00e1got.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: Alapok rombol\u00e1sa \u00e9s csod\u00e1latos \u00faj vil\u00e1g\" 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>Egy kis t\u00f6rt\u00e9nelem: HTTP\/1.1<\/h2>\n<p>\n1997-ben az HTTP 1.1 verzi\u00f3ja megkapta a saj\u00e1t RFC-j\u00e9t. Abban az id\u0151ben a protokollt m\u00e1r \u00e9vek \u00f3ta haszn\u00e1lt\u00e1k a b\u00f6ng\u00e9sz\u0151k, \u00e9s az \u00faj standard tov\u00e1bbi tizen\u00f6t \u00e9vig \u00e9rv\u00e9nyes maradt. A protokoll csak k\u00e9r\u00e9s-v\u00e1lasz elven m\u0171k\u00f6d\u00f6tt, \u00e9s f\u0151k\u00e9nt sz\u00f6veges inform\u00e1ci\u00f3k \u00e1tvitel\u00e9re k\u00e9sz\u00fclt.<\/p>\n<p>Az HTTP-t a TCP protokoll f\u00f6l\u00f6tt tervezt\u00e9k, amely garant\u00e1lja a csomagok megb\u00edzhat\u00f3 k\u00e9zbes\u00edt\u00e9s\u00e9t a c\u00edmzettnek. A TCP m\u0171k\u00f6d\u00e9se a v\u00e9gpontok k\u00f6z\u00f6tti megb\u00edzhat\u00f3 kapcsolat l\u00e9trehoz\u00e1s\u00e1n \u00e9s fenntart\u00e1s\u00e1n alapul, valamint a forgalom szegmensekre bont\u00e1s\u00e1n. A szegmenseknek van sorozatsz\u00e1muk \u00e9s ellen\u0151rz\u0151 \u00f6sszeg\u00fck. Ha esetleg valamelyik szegmens nem \u00e9rkezik meg vagy hib\u00e1s ellen\u0151rz\u0151 \u00f6sszeggel \u00e9rkezik, akkor a k\u00fcld\u00e9s le\u00e1ll, am\u00edg a hi\u00e1nyz\u00f3 szegmens vissza nem t\u00e9r.<\/p>\n<p>A HTTP\/1.0 eset\u00e9ben a TCP-kapcsolat minden k\u00e9rd\u00e9s ut\u00e1n lez\u00e1rult. Ez rendk\u00edv\u00fcl pazarl\u00f3 volt, mivel a TCP-kapcsolat l\u00e9trehoz\u00e1sa (3-Way-Handshake) nem egy gyors folyamat. A HTTP\/1.1 bevezette a keep-alive mechanizmust, amely lehet\u0151v\u00e9 teszi egy kapcsolat \u00fajrahaszn\u00e1lat\u00e1t t\u00f6bb k\u00e9rd\u00e9shez. Azonban mivel ez k\u00f6nnyen sz\u0171k keresztmetszett\u00e9 v\u00e1lhat, a HTTP\/1.1 k\u00fcl\u00f6nb\u00f6z\u0151 megval\u00f3s\u00edt\u00e1saiban megengedett, hogy t\u00f6bb TCP-kapcsolat is nyitva maradjon egy hosthoz. P\u00e9ld\u00e1ul a Chrome \u00e9s a leg\u00fajabb Firefox verzi\u00f3k lehet\u0151v\u00e9 teszik ak\u00e1r hat kapcsolat l\u00e9trehoz\u00e1s\u00e1t.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: Alapok rombol\u00e1sa \u00e9s csod\u00e1latos \u00faj vil\u00e1g\" src=\"\/wp-content\/uploads\/2019\/11\/b1c131da8e62ace741f3064f2fb96c60.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nA titkos\u00edt\u00e1st szint\u00e9n m\u00e1s protokollokra akart\u00e1k b\u00edzni, \u00e9s ez\u00e9rt a TCP f\u00f6l\u00f6tt a TLS protokollt kezdt\u00e9k alkalmazni, amely meglehet\u0151sen megb\u00edzhat\u00f3an v\u00e9dte az adatokat, de m\u00e9g ink\u00e1bb megn\u00f6velte a kapcsolat l\u00e9trehoz\u00e1s\u00e1hoz sz\u00fcks\u00e9ges id\u0151t. Ennek eredm\u00e9nyek\u00e9nt a k\u00e9zfog\u00e1si folyamat \u00edgy n\u00e9zett ki:<br \/>\n <img decoding=\"async\" alt=\"HTTP\/3: Alapok rombol\u00e1sa \u00e9s csod\u00e1latos \u00faj vil\u00e1g\" src=\"\/wp-content\/uploads\/2019\/11\/2fdccf56e0ed29444557836fdc65351b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Cloudflare \u00e1bra<\/i><\/p>\n<p>\u00cdgy a HTTP\/1.1 sz\u00e1mos probl\u00e9m\u00e1val k\u00fczd\u00f6tt:<\/p>\n<ul>\n<li>Lass\u00fa kapcsolat l\u00e9trehoz\u00e1s.<\/li>\n<li>Az adatok sz\u00f6veges form\u00e1ban ker\u00fclnek tov\u00e1bb\u00edt\u00e1sra, \u00edgy a k\u00e9pek, vide\u00f3k \u00e9s egy\u00e9b nem sz\u00f6veges inform\u00e1ci\u00f3k \u00e1tad\u00e1sa nem hat\u00e9kony.<\/li>\n<li>Egy TCP-kapcsolatot egy k\u00e9r\u00e9shez haszn\u00e1lnak, \u00edgy a t\u00f6bbi k\u00e9r\u00e9snek vagy egy m\u00e1sik kapcsolatot kell keresnie, vagy v\u00e1rnia kell, am\u00edg a jelenlegi k\u00e9r\u00e9s megszabadul.<\/li>\n<li>Csak pull-modell t\u00e1mogatott. A szabv\u00e1nyban nincs semmi a server-push-r\u00f3l.<\/li>\n<li>A fejl\u00e9cek sz\u00f6vegesen ker\u00fclnek tov\u00e1bb\u00edt\u00e1sra.<\/li>\n<\/ul>\n<p>\nHa a server-push csak valamelyest megval\u00f3s\u00edthat\u00f3 a WebSocket protokoll seg\u00edts\u00e9g\u00e9vel, akkor a t\u00f6bbi probl\u00e9m\u00e1t radik\u00e1lisabban kellett kezelni.<\/p>\n<h2>Egy kis frissess\u00e9g: HTTP\/2<\/h2>\n<p>\n2012-ben a Google m\u00e9ly\u00e9n elkezd\u0151d\u00f6tt a SPDY protokoll fejleszt\u00e9se (ejtsd: 'spidi'). A protokoll c\u00e9lja az HTTP\/1.1 f\u0151 probl\u00e9m\u00e1inak megold\u00e1sa volt, mik\u00f6zben meg kellett tartania a visszafel\u00e9 kompatibilit\u00e1st. 2015-ben az IETF munkacsoport bemutatta a HTTP\/2 specifik\u00e1ci\u00f3t, amely a SPDY protokollon alapult. \u00cdme a HTTP\/2 f\u0151bb k\u00fcl\u00f6nbs\u00e9gei:<\/p>\n<ul>\n<li>Binaries serializ\u00e1l\u00e1sa.<\/li>\n<li>T\u00f6bb HTTP-k\u00e9r\u00e9s multiplexel\u00e9se egy TCP-kapcsolatba.<\/li>\n<li>Server-push dobozb\u00f3l (WebSocket n\u00e9lk\u00fcl).<\/li>\n<\/ul>\n<p>\nA protokoll nagy el\u0151rel\u00e9p\u00e9st jelentett. Nagyon <noindex><a rel=\"nofollow\" href=\"https:\/\/http2.akamai.com\/demo\">gyorsabb az els\u0151 verzi\u00f3hoz k\u00e9pest<\/a><\/noindex> \u00e9s nem ig\u00e9nyel t\u00f6bb TCP-kapcsolat l\u00e9trehoz\u00e1s\u00e1t: az \u00f6sszes k\u00e9r\u00e9s egy hosthoz egybe van multiplexelve. Teh\u00e1t egy kapcsolaton bel\u00fcl t\u00f6bb \u00fagynevezett stream tal\u00e1lhat\u00f3, mindegyik saj\u00e1t azonos\u00edt\u00f3j\u00e1val. B\u00f3nuszk\u00e9nt j\u00f6n a dobozos server-push.<\/p>\n<p>A multiplexel\u00e9s azonban egy m\u00e1sik sarokk\u00f6v\u00e9v\u00e9 v\u00e1lik a probl\u00e9m\u00e1nak. K\u00e9pzelje el, hogy aszinkron m\u00f3don hajtunk v\u00e9gre 5 k\u00e9r\u00e9st egy szerverhez. A HTTP\/2 haszn\u00e1latakor mindez a k\u00e9r\u00e9sek egy TCP-kapcsolaton bel\u00fcl t\u00f6rt\u00e9nik, teh\u00e1t ha b\u00e1rmelyik k\u00e9r\u00e9s szegmense elveszik vagy hib\u00e1san \u00e9rkezik meg, az \u00f6sszes k\u00e9r\u00e9s \u00e9s v\u00e1lasz tov\u00e1bb\u00edt\u00e1sa le\u00e1ll, am\u00edg az elveszett szegmens helyre nem \u00e1ll. <noindex><a rel=\"nofollow\" href=\"https:\/\/http3-explained.haxx.se\/en\/why-tcphol.html\">Daniel Stenberg becsl\u00e9se szerint,<\/a><\/noindex>, ha a vesztes csomagok az \u00f6sszes csomag 2%-\u00e1t teszik ki, akkor a HTTP\/1.1 a b\u00f6ng\u00e9sz\u0151ben jobban teljes\u00edt, mint a HTTP\/2, mivel 6 kapcsolatot nyit, nem pedig egyet.<\/p>\n<p>Ezt a probl\u00e9m\u00e1t \u201ehead-of-line blocking\u201d-nak nevezik, \u00e9s sajnos a TCP haszn\u00e1latakor nem megoldhat\u00f3.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: Alapok rombol\u00e1sa \u00e9s csod\u00e1latos \u00faj vil\u00e1g\" src=\"\/wp-content\/uploads\/2019\/11\/234a6dc218a9acf8d2212fbdf28f2188.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Illusztr\u00e1ci\u00f3 Daniel Steinberg<\/i><\/p>\n<p>\u00d6sszess\u00e9g\u00e9ben a HTTP\/2 szabv\u00e1ny fejleszt\u0151i \u00f3ri\u00e1si munk\u00e1t v\u00e9geztek, \u00e9s szinte mindent megtettek, amit csak lehetett az OSI modell alkalmaz\u00e1si szintj\u00e9n. Itt az id\u0151, hogy leereszkedj\u00fcnk a sz\u00e1ll\u00edt\u00e1si szintre, \u00e9s felfedezz\u00fcnk egy \u00faj sz\u00e1ll\u00edt\u00e1si protokollt.<\/p>\n<h2>Sz\u00fcks\u00e9g\u00fcnk van egy \u00faj protokollra: UDP vs TCP<\/h2>\n<p>\nR\u00e1 \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u0431\u044b\u0441\u0442\u0440\u043e kider\u00fclt, hogy egy teljesen \u00faj sz\u00e1ll\u00edt\u00e1si protokoll bevezet\u00e9se \u2013 a mai k\u00f6r\u00fclm\u00e9nyek k\u00f6z\u00f6tt megval\u00f3s\u00edthatatlan feladat. Az a helyzet, hogy a sz\u00e1ll\u00edt\u00e1si szintr\u0151l az eszk\u00f6z\u00f6k vagy k\u00f6ztes eszk\u00f6z\u00f6k (routerek, t\u0171zfalak, NAT-szerverek...) tudnak, \u00e9s nagyon neh\u00e9z \u0151ket valami \u00fajra megtan\u00edtani. Ezen k\u00edv\u00fcl a sz\u00e1ll\u00edt\u00e1si protokollok t\u00e1mogat\u00e1sa be van \u00e9p\u00edtve az oper\u00e1ci\u00f3s rendszerek kernel\u00e9be, \u00e9s a kernelt sem cser\u00e9lik \u00e9ppen t\u00fal sz\u00edvesen.<\/p>\n<p>Itt le lehetne mondani, \u00e9s mondani, hogy \u201eTerm\u00e9szetesen kital\u00e1ljuk az \u00faj HTTP\/3-at, sok minden m\u00e1s mellett, de a bevezet\u00e9se m\u00e9g 10-15 \u00e9vbe telik (k\u00f6r\u00fclbel\u00fcl ennyi id\u0151be telik, mire a legt\u00f6bb hardver cser\u00e9l\u0151dik)\u201d, de van egy m\u00e1sik, nem annyira nyilv\u00e1nval\u00f3 lehet\u0151s\u00e9g: haszn\u00e1lni az UDP protokollt. Igen, igen, arra a protokollra, amivel a f\u00e1jlokat k\u00fcldt\u00fck a helyi h\u00e1l\u00f3zaton az ezredfordul\u00f3 k\u00f6rny\u00e9k\u00e9n. Gyakorlatilag minden mai hardver tudja, hogyan kell kezelni.<\/p>\n<p>Mik az UDP el\u0151nyei a TCP-vel szemben? Els\u0151sorban az, hogy nincs sz\u00e1ll\u00edt\u00e1si szint\u0171 kapcsolat, amir\u0151l a hardver tud. Ez lehet\u0151v\u00e9 teszi sz\u00e1munkra, hogy saj\u00e1t magunk hat\u00e1rozzuk meg a kapcsolatokat a v\u00e9gpontokon, \u00e9s ott kezelj\u00fck a felmer\u00fcl\u0151 konfliktusokat. Teh\u00e1t nem vagyunk korl\u00e1tozva egy vagy t\u00f6bb kapcsolatra (mint a TCP eset\u00e9n), hanem annyit hozhatunk l\u00e9tre, amennyire sz\u00fcks\u00e9g\u00fcnk van. M\u00e1sodszor, az adatok \u00e1tad\u00e1sa UDP-n sokkal gyorsabb, mint TCP-n. Teh\u00e1t elm\u00e9letileg \u00e1tt\u00f6rhetj\u00fck a mai sebess\u00e9gr\u00f6gz\u00edt\u00e9st, amit a HTTP\/2-ben el\u00e9rt\u00fcnk. <\/p>\n<p>Azonban az UDP nem garant\u00e1lja az adat\u00e1tvitel megb\u00edzhat\u00f3s\u00e1g\u00e1t. Val\u00f3j\u00e1ban csak csomagokat k\u00fcld\u00fcnk, b\u00edzva benne, hogy a m\u00e1sik v\u00e9g\u00e9n megkapj\u00e1k \u0151ket. Nem kapt\u00e1k meg? H\u00e1t, pech\u2026 Ez el\u00e9g volt feln\u0151tt vide\u00f3k \u00e1tad\u00e1s\u00e1hoz, de komolyabb dolgokhoz megb\u00edzhat\u00f3s\u00e1gra van sz\u00fcks\u00e9g, amihez \u00e1ltal\u00e1ban valamit m\u00e9g r\u00e1 kellene \u00e9p\u00edten\u00fcnk az UDP-re.<\/p>\n<p>A HTTP\/2-h\u00f6z hasonl\u00f3an az \u00faj protokoll l\u00e9trehoz\u00e1si munk\u00e1latai a Google-n\u00e1l 2012-ben kezd\u0151dtek, teh\u00e1t nagyj\u00e1b\u00f3l egy id\u0151ben a SPDY fejleszt\u00e9s\u00e9nek megkezd\u00e9s\u00e9vel. 2013-ban Jim Roskind bemutatta a nagyk\u00f6z\u00f6ns\u00e9gnek. <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.google.com\/document\/d\/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34\/edit\">a QUIC (Quick UDP Internet Connections) protokollt<\/a><\/noindex>, \u00e9s 2015-ben Internet Draft ker\u00fclt beny\u00fajt\u00e1sra a IETF szabv\u00e1nyos\u00edt\u00e1sa \u00e9rdek\u00e9ben. M\u00e1r akkor a Google \u00e1ltal kifejlesztett protokoll jelent\u0151sen elt\u00e9rt a javasolt szabv\u00e1nyt\u00f3l, ez\u00e9rt a Google verzi\u00f3j\u00e1t gQUIC-nak nevezt\u00e9k el.<\/p>\n<h4>Mi az a QUIC?<\/h4>\n<p>\nEl\u0151sz\u00f6r is, ahogy m\u00e1r eml\u00edtettem, ez egy burkolat az UDP felett. Az UDP-re \u00e9p\u00fcl a QUIC kapcsolat, amelyben a HTTP\/2-h\u00f6z hasonl\u00f3an t\u00f6bb stream is l\u00e9trej\u00f6het. Ezek a streamek csak a v\u00e9gpontokon l\u00e9teznek, \u00e9s f\u00fcggetlen\u00fcl m\u0171k\u00f6dnek. Ha egy streamben csomagveszt\u00e9s t\u00f6rt\u00e9nik, az m\u00e1s streamekre nem gyakorol hat\u00e1st.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: Alapok rombol\u00e1sa \u00e9s csod\u00e1latos \u00faj vil\u00e1g\" src=\"\/wp-content\/uploads\/2019\/11\/0a64aa26d9b8216db56d389fa48578a5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Illusztr\u00e1ci\u00f3 Daniel Steinberg<\/i><\/p>\n<p>M\u00e1sodszor, a titkos\u00edt\u00e1s most m\u00e1r nem k\u00fcl\u00f6n szinten val\u00f3sul meg, hanem be van \u00e9p\u00edtve a protokollba. Ez lehet\u0151v\u00e9 teszi a kapcsolat l\u00e9tes\u00edt\u00e9s\u00e9t \u00e9s a nyilv\u00e1nos kulcsok cser\u00e9j\u00e9t egyetlen k\u00e9zfog\u00e1s sor\u00e1n, valamint egy \u00fcgyes 0-RTT k\u00e9zfog\u00e1s mechanizmus haszn\u00e1lat\u00e1t, \u00edgy elker\u00fclve az k\u00e9sleked\u00e9seket a k\u00e9zfog\u00e1sn\u00e1l. Ezen k\u00edv\u00fcl, lehet\u0151s\u00e9g van egyes adatcsomagok titkos\u00edt\u00e1s\u00e1ra is. Ez lehet\u0151v\u00e9 teszi, hogy ne v\u00e1rjunk az adatstream befejez\u00e9s\u00e9re, hanem f\u00fcggetlen\u00fcl dek\u00f3dolhassuk a megkapott csomagokat. Ez a m\u0171k\u00f6d\u00e9si m\u00f3d teljesen lehetetlen volt TCP-n\u00e9l, mivel a TLS \u00e9s a TCP f\u00fcggetlen\u00fcl m\u0171k\u00f6dtek egym\u00e1st\u00f3l, \u00e9s a TLS nem tudta, hogy a TCP milyen darabokra bontja az adatokat. Ez\u00e9rt nem tudta \u00fagy el\u0151k\u00e9sz\u00edteni a saj\u00e1t szegmenseit, hogy azok egy az egyben megfeleljenek a TCP szegmenseinek, \u00edgy f\u00fcggetlen\u00fcl nem tudtak dek\u00f3dolva lenni. Mindezek a fejleszt\u00e9sek lehet\u0151v\u00e9 teszik a QUIC sz\u00e1m\u00e1ra, hogy a TCP-hez k\u00e9pest cs\u00f6kkentse a k\u00e9sleltet\u00e9st.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: Alapok rombol\u00e1sa \u00e9s csod\u00e1latos \u00faj vil\u00e1g\" src=\"\/wp-content\/uploads\/2019\/11\/cb3c522636f7a052a0f5988fe7ea3a65.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nHarmadszor, a k\u00f6nny\u0171 streamek koncepci\u00f3ja lehet\u0151v\u00e9 teszi a kapcsolat f\u00fcggetlen\u00edt\u00e9s\u00e9t az \u00fcgyf\u00e9l IP-c\u00edm\u00e9t\u0151l. Ez fontos p\u00e9ld\u00e1ul, amikor az \u00fcgyf\u00e9l \u00e1tv\u00e1lt egy m\u00e1sik Wi-Fi hozz\u00e1f\u00e9r\u00e9si pontra, megv\u00e1ltoztatva ezzel az IP-c\u00edm\u00e9t. Ilyen esetben a TCP haszn\u00e1latakor egy hossz\u00fa folyamat zajlik, amely sor\u00e1n a megl\u00e9v\u0151 TCP kapcsolatok id\u0151t\u00fall\u00e9p\u00e9s miatt megszakadnak, \u00e9s \u00faj kapcsolatok j\u00f6nnek l\u00e9tre az \u00faj IP-c\u00edmr\u0151l. QUIC eset\u00e9ben az \u00fcgyf\u00e9l egyszer\u0171en folytatja a csomagok k\u00fcld\u00e9s\u00e9t a szervernek az \u00faj IP-c\u00edmr\u0151l, a r\u00e9gi stream ID-vel. Mivel a stream ID most m\u00e1r egyedi \u00e9s nem \u00fajrahaszn\u00e1lhat\u00f3, a szerver meg\u00e9rti, hogy az \u00fcgyf\u00e9l megv\u00e1ltoztatta az IP-c\u00edm\u00e9t, \u00fajrak\u00fcldi az elveszett csomagokat, \u00e9s folytatja a kommunik\u00e1ci\u00f3t az \u00faj c\u00edmen.<\/p>\n<p>Negyedik, a QUIC az alkalmaz\u00e1si szinten val\u00f3sul meg, nem az oper\u00e1ci\u00f3s rendszeren. Ez egyr\u00e9szt lehet\u0151v\u00e9 teszi a protokoll gyorsabb m\u00f3dos\u00edt\u00e1s\u00e1t, mivel ahhoz, hogy friss\u00edt\u00e9st kapjunk, el\u00e9g egyszer\u0171en friss\u00edteni a k\u00f6nyvt\u00e1rat, nem kell v\u00e1rni az \u00faj oper\u00e1ci\u00f3s rendszer verzi\u00f3ra. M\u00e1sr\u00e9szt azonban ez a CPU-felhaszn\u00e1l\u00e1s jelent\u0151s n\u00f6veked\u00e9s\u00e9hez vezet.<\/p>\n<p>Nos, a v\u00e9g\u00e9re maradtak a fejl\u00e9cek. A fejl\u00e9c t\u00f6m\u00f6r\u00edt\u00e9s \u00e9ppen az a szempont, ami elt\u00e9r a QUIC \u00e9s gQUIC k\u00f6z\u00f6tt. Nincs \u00e9rtelme ezen sok id\u0151t t\u00f6lteni, csak annyit mondan\u00e9k, hogy a szabv\u00e1nyos\u00edt\u00e1sra beny\u00fajtott verzi\u00f3ban a fejl\u00e9c t\u00f6m\u00f6r\u00edt\u00e9s\u00e9t maxim\u00e1lisan hasonl\u00f3v\u00e1 tett\u00e9k a HTTP\/2 fejl\u00e9c t\u00f6m\u00f6r\u00edt\u00e9s\u00e9hez. R\u00e9szletesebben olvashat r\u00f3la <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">itt<\/a><\/noindex>.<\/p>\n<h4>Mennyivel gyorsabb?<\/h4>\n<p>\nEz egy bonyolult k\u00e9rd\u00e9s. A helyzet az, hogy mivel m\u00e9g nincs szabv\u00e1nyunk, igaz\u00e1b\u00f3l nincs mit m\u00e9rni. Tal\u00e1n az egyetlen statisztikai adat, amivel rendelkez\u00fcnk, a Google statisztik\u00e1ja, amely a gQUIC-et 2013 \u00f3ta haszn\u00e1lja, \u00e9s 2016-ban <noindex><a rel=\"nofollow\" href=\"https:\/\/www.ietf.org\/proceedings\/96\/slides\/slides-96-quic-3.pdf\">besz\u00e1molt az IETF-nek<\/a><\/noindex>, hogy a Chrome b\u00f6ng\u00e9sz\u0151j\u00e9b\u0151l \u00e9rkez\u0151 forgalom k\u00f6r\u00fclbel\u00fcl 90%-a most m\u00e1r a QUIC-ot haszn\u00e1lja. Ugyanebben a bemutat\u00f3ban azt is jelentik, hogy gQUIC-en kereszt\u00fcl az oldalak k\u00f6r\u00fclbel\u00fcl 5%-kal gyorsabban t\u00f6lt\u0151dnek be, m\u00edg a streaming vide\u00f3k eset\u00e9ben 30%-kal kevesebb akadoz\u00e1st tapasztalunk a TCP-hez k\u00e9pest. <\/p>\n<p>2017-ben egy Arash Molavi Kakhki vezette kutat\u00f3csoport k\u00f6zz\u00e9tette <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">nagy munk\u00e1j\u00e1t<\/a><\/noindex> a gQUIC teljes\u00edtm\u00e9ny\u00e9nek vizsg\u00e1lat\u00e1r\u00f3l a TCP-hez k\u00e9pest. <br \/>\nA kutat\u00e1s sz\u00e1mos gyenges\u00e9get t\u00e1rt fel a gQUIC-ben, mint p\u00e9ld\u00e1ul a h\u00e1l\u00f3zati csomagok kevered\u00e9s\u00e9vel szembeni \u00e9rz\u00e9kenys\u00e9g, a csatorna s\u00e1vsz\u00e9less\u00e9g\u00e9vel szembeni kapzsis\u00e1g (unfairness) \u00e9s a kis (10 kB-ig) objektumok lass\u00fa \u00e1tvitele. Az ut\u00f3bbi azonban 0-RTT haszn\u00e1lat\u00e1val kompenz\u00e1lhat\u00f3. Minden m\u00e1s vizsg\u00e1lt esetben a gQUIC sebess\u00e9gn\u00f6veked\u00e9st mutatott a TCP-hez k\u00e9pest. A konkr\u00e9t sz\u00e1mokr\u00f3l itt neh\u00e9z besz\u00e9lni. Jobb, ha elolvassa <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">maga a kutat\u00e1s<\/a><\/noindex> vagy <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.apnic.net\/2018\/01\/29\/measuring-quic-vs-tcp-mobile-desktop\/\">r\u00f6vid bejegyz\u00e9s<\/a><\/noindex>.<\/p>\n<p>Itt \u00e9rdemes megeml\u00edteni, hogy ezek az adatok kifejezetten a gQUIC-re vonatkoznak, \u00e9s nem relev\u00e1nsak a fejleszt\u00e9s alatt \u00e1ll\u00f3 szabv\u00e1nyhoz. Mi v\u00e1r a QUIC-re: ez m\u00e9g h\u00e9t pecs\u00e9tes titok, de rem\u00e9lj\u00fck, hogy a gQUIC-ben felt\u00e1rt gyenges\u00e9gek figyelembev\u00e9telre \u00e9s kijav\u00edt\u00e1sra ker\u00fclnek.<\/p>\n<h2>Egy kis j\u00f6v\u0151bel\u00e1t\u00e1s: mi a helyzet a HTTP\/3-mal?<\/h2>\n<p>\nItt minden krist\u00e1lytiszta: az API semmik\u00e9ppen sem v\u00e1ltozik. Minden \u00fagy marad, ahogy volt az HTTP\/2-ben. Ha az API v\u00e1ltozatlan marad, akkor a HTTP\/3-ra val\u00f3 \u00e1tt\u00e9r\u00e9shez egy friss verzi\u00f3j\u00fa k\u00f6nyvt\u00e1r haszn\u00e1lat\u00e1val kell foglalkozni, amely t\u00e1mogatja a QUIC protokollt a h\u00e1tt\u00e9rben. Igaz, m\u00e9g sok\u00e1ig sz\u00fcks\u00e9g lesz a r\u00e9gi HTTP verzi\u00f3kra val\u00f3 visszaes\u00e9sre, mivel az internet m\u00e9g nincs felk\u00e9sz\u00fclve a teljes v\u00e1lt\u00e1sra UDP-ra.<\/p>\n<h4>Ki m\u00e1r t\u00e1mogatja<\/h4>\n<p>\n\u00cdme <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/quicwg\/base-drafts\/wiki\/Implementations\">lista<\/a><\/noindex> l\u00e9tez\u0151 QUIC megval\u00f3s\u00edt\u00e1sokat. A szabv\u00e1ny hi\u00e1nya ellen\u00e9re a lista nem rossz. <\/p>\n<p>Jelenleg egyetlen b\u00f6ng\u00e9sz\u0151 sem t\u00e1mogatja a QUIC-et \u00e9les verzi\u00f3ban. Nemr\u00e9giben inform\u00e1ci\u00f3 \u00e9rkezett, hogy a Chrome aktiv\u00e1lta a HTTP\/3 t\u00e1mogat\u00e1s\u00e1t, de egyel\u0151re csak a Canary verzi\u00f3ban. <\/p>\n<p>A h\u00e1tt\u00e9rtechnol\u00f3gi\u00e1k k\u00f6z\u00fcl a HTTP\/3-at csak <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/caddyserver\/caddy\">Caddy<\/a><\/noindex> \u00e9s <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/http3-the-past-present-and-future\/\">Cloudflare<\/a><\/noindex>, de egyel\u0151re k\u00eds\u00e9rleti m\u00f3dban. Az NGINX 2019 tavasz\u00e1n <noindex><a rel=\"nofollow\" href=\"https:\/\/www.nginx.com\/blog\/nginx-1-16-1-17-released\/\">bejelentett\u00e9k<\/a><\/noindex>, bejelentette, hogy dolgoznak a HTTP\/3 t\u00e1mogat\u00e1s\u00e1n, de m\u00e9g nem fejezt\u00e9k be.<\/p>\n<h4>Milyen probl\u00e9m\u00e1k vannak<\/h4>\n<p>\nEgy olyan vil\u00e1gban \u00e9l\u00fcnk, ahol egyetlen nagy technol\u00f3gia sem juthat el a t\u00f6megekhez an\u00e9lk\u00fcl, hogy ellen\u00e1ll\u00e1sba ne \u00fctk\u00f6zne, \u00e9s a QUIC sem kiv\u00e9tel.<\/p>\n<p>A legfontosabb, hogy valahogy meg kell magyar\u00e1zni a b\u00f6ng\u00e9sz\u0151nek, hogy a \"https:\/\/\" most m\u00e1r nem biztos, hogy a 443-as TCP portra vezet. Ott ak\u00e1r TCP sincs. Ehhez az Alt-Svc fejl\u00e9cet haszn\u00e1ljuk. Ez lehet\u0151v\u00e9 teszi, hogy t\u00e1j\u00e9koztassuk a b\u00f6ng\u00e9sz\u0151t arr\u00f3l, hogy ez a weboldal egy m\u00e1sik protokollal el\u00e9rhet\u0151 egy adott c\u00edmen. Elm\u00e9letben ennek \u00fagy kellene m\u0171k\u00f6dnie, mint az \u00f3ram\u0171, de a gyakorlatban arra fogunk tal\u00e1lkozni, hogy a UDP esetleg tiltva van a t\u0171zfalon DDoS t\u00e1mad\u00e1sok elker\u00fcl\u00e9se \u00e9rdek\u00e9ben.<\/p>\n<p>De m\u00e9g ha a UDP nincs is letiltva, az \u00fcgyf\u00e9l NAT-router m\u00f6g\u00f6tt lehet, amely a TCP kapcsolat fenntart\u00e1s\u00e1ra van be\u00e1ll\u00edtva az IP c\u00edmen, \u00e9s mivel UDP-t haszn\u00e1lunk, amelynek nincs hardveres kapcsolata, a NAT nem fogja fenntartani a kapcsolatot, \u00edgy a QUIC kapcsolat <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">folyamatosan megszakad<\/a><\/noindex>. <\/p>\n<p>Mindezek a probl\u00e9m\u00e1k abb\u00f3l ad\u00f3dnak, hogy a UDP kor\u00e1bban nem lett haszn\u00e1lva internetes tartalom tov\u00e1bb\u00edt\u00e1s\u00e1ra, \u00e9s a hardvergy\u00e1rt\u00f3k nem tudt\u00e1k el\u0151re, hogy ez valaha megt\u00f6rt\u00e9nik. Hasonl\u00f3k\u00e9ppen, az adminisztr\u00e1torok m\u00e9g nem igaz\u00e1n \u00e9rtik, hogyan \u00e1ll\u00edts\u00e1k be helyesen a h\u00e1l\u00f3zatokat a QUIC m\u0171k\u00f6d\u00e9s\u00e9re. Ez a helyzet fokozatosan v\u00e1ltozni fog, \u00e9s mindenesetre az ilyen v\u00e1ltoz\u00e1sok kevesebb id\u0151t vesznek ig\u00e9nybe, mint egy \u00faj sz\u00e1ll\u00edt\u00e1si protokoll bevezet\u00e9se. <\/p>\n<p>Ezenk\u00edv\u00fcl, ahogy kor\u00e1bban m\u00e1r eml\u00edtett\u00fck, a QUIC jelent\u0151sen megn\u00f6veli a processzor haszn\u00e1lat\u00e1t. Daniel Stenberg <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=idViw4anA6E\">\u00e9rt\u00e9kelte<\/a><\/noindex> a processzor n\u00f6veked\u00e9s\u00e9t ak\u00e1r h\u00e1romszoros\u00e1ra.<\/p>\n<h4>Mikor \u00e9rkezik el a HTTP\/3<\/h4>\n<p>\nA szabv\u00e1nyt <noindex><a rel=\"nofollow\" href=\"https:\/\/datatracker.ietf.org\/wg\/quic\/about\/\">szeretn\u00e9k elfogadni<\/a><\/noindex> 2020 m\u00e1jus\u00e1ig, de figyelembe v\u00e9ve, hogy jelenleg az 2019 j\u00falius\u00e1ra tervezett dokumentumok nincsenek befejezve, val\u00f3sz\u00edn\u0171leg a d\u00e1tumot el fogj\u00e1k tolni.<\/p>\n<p>A Google pedig 2013 \u00f3ta haszn\u00e1lja a saj\u00e1t gQUIC megval\u00f3s\u00edt\u00e1s\u00e1t. Ha megn\u00e9zz\u00fck a HTTP-k\u00e9r\u00e9st, amelyet a Google keres\u0151motorhoz k\u00fcldenek, l\u00e1thatjuk ezt:<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: Alapok rombol\u00e1sa \u00e9s csod\u00e1latos \u00faj vil\u00e1g\" src=\"\/wp-content\/uploads\/2019\/11\/af422268eb85b488c7be1b70c6d33fad.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>K\u00f6vetkeztet\u00e9sek<\/h2>\n<p>\nA QUIC most egy meglehet\u0151sen nyers, de \u00edg\u00e9retes technol\u00f3gia. Figyelembe v\u00e9ve, hogy az utols\u00f3 20 \u00e9vben a sz\u00e1ll\u00edt\u00e1si protokollok optimaliz\u00e1ci\u00f3ja t\u00falnyom\u00f3r\u00e9szt a TCP-re vonatkozott, a QUIC, amely a teljes\u00edtm\u00e9nyben a legt\u00f6bb esetben el\u0151ny\u00f6s, m\u00e1r most is rendk\u00edv\u00fcl \u00edg\u00e9retesnek t\u0171nik. <\/p>\n<p>Mindazon\u00e1ltal m\u00e9g mindig megoldatlan probl\u00e9m\u00e1k \u00e1llnak el\u0151tt\u00fcnk, amelyekkel a k\u00f6vetkez\u0151 n\u00e9h\u00e1ny \u00e9vben meg kell birk\u00f3zni. A folyamat elh\u00faz\u00f3dhat, mivel a k\u00e9rd\u00e9ses hardver friss\u00edt\u00e9se senkinek sem tetszik, de mindenesetre minden probl\u00e9ma teljesen megoldhat\u00f3, \u00e9s el\u0151bb-ut\u00f3bb mindannyiunknak lesz HTTP\/3. <\/p>\n<p>A j\u00f6v\u0151 nem v\u00e1rathat mag\u00e1ra!<br \/>\n<br \/>Forr\u00e1s: <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.3 - 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\/hu\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"hu_HU\" \/>\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\/hu\/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: az alapok lerombol\u00e1sa \u00e9s egy csod\u00e1s \u00faj vil\u00e1g | ProHoster","description":"M\u00e1r t\u00f6bb mint 20 \u00e9ve webb\u00f6ng\u00e9sz\u00fcnk HTTP protokollon. A felhaszn\u00e1l\u00f3k t\u00f6bbs\u00e9ge pedig nem is gondolkodik azon, hogy mi ez \u00e9s hogyan m\u0171k\u00f6dik.","canonical_url":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hu_HU","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\/hu\/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\/hu\/wp-json\/wp\/v2\/posts\/52181","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/comments?post=52181"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts\/52181\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/media?parent=52181"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/categories?post=52181"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/tags?post=52181"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}