{"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\/hr\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","title":{"rendered":"HTTP\/3: ru\u0161enje temelja i \u010dudesni novi svijet","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Ve\u0107 vi\u0161e od 20 godina pregledavamo web stranice putem HTTP protokola. Ve\u0107ina korisnika uop\u0107e ne razmi\u0161lja o tome \u0161to to zapravo jest i kako to funkcionira. Drugi znaju da se negdje ispod HTTP-a nalaze TLS, a ispod njega TCP, a ispod TCP-a IP i tako dalje. A tre\u0107i \u2013 heretici \u2013 smatraju da je TCP pro\u0161lost, \u017eele ne\u0161to br\u017ee, pouzdanije i sigurnije. No, u svojim poku\u0161ajima da izume novi idealan protokol, vratili su se tehnologijama iz 80-ih godina i poku\u0161avaju na njima izgraditi svoj divni novi svijet.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: ru\u0161enje temelja i \u010dudesni novi svijet\" 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>Malo povijesti: HTTP\/1.1<\/h2>\n<p>\nGodine 1997. godine protokol za razmjenu tekstualnih informacija HTTP verzije 1.1 dobio je svoj RFC. U to vrijeme protokol su koristili preglednici ve\u0107 nekoliko godina, a novi standard trajao je jo\u0161 petnaest. Protokol je radio isklju\u010divo prema principu zahtjev-odgovor i bio je namijenjen, prije svega, za prijenos tekstualnih informacija.<\/p>\n<p>HTTP je projektiran za rad preko TCP protokola, koji jam\u010di pouzdanu isporuku paketa do odredi\u0161ta. Rad TCP-a temelji se na uspostavljanju i odr\u017eavanju pouzdane veze izme\u0111u krajnjih to\u010daka i dijeljenju prometa na segmente. Segmenti imaju svoj redni broj i kontrolnu sumu. Ako iznenada neki od segmenata ne do\u0111e ili do\u0111e s neto\u010dnom kontrolnom sumom, prijenos \u0107e se zaustaviti dok se ne obnovi izgubljeni segment.<\/p>\n<p>U HTTP\/1.0 TCP veza se zatvarala nakon svake zahtjeva. To je bilo izuzetno rasipno, jer uspostava TCP veze (3-Way-Handshake) nije brz proces. U HTTP\/1.1 uveden je mehanizam keep-alive, koji omogu\u0107ava ponovno kori\u0161tenje jedne veze za vi\u0161e zahtjeva. Me\u0111utim, s obzirom na to da to mo\u017ee lako postati usko grlo, u razli\u010ditim implementacijama HTTP\/1.1 dopu\u0161teno je otvaranje vi\u0161e TCP veza prema jednom hostu. Na primjer, u Chromeu i najnovijim verzijama Firefoxa dopu\u0161teno je do \u0161est veza.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: ru\u0161enje temelja i \u010dudesni novi svijet\" src=\"\/wp-content\/uploads\/2019\/11\/b1c131da8e62ace741f3064f2fb96c60.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n\u0160ifriranje se tako\u0111er predlo\u017eilo prepustiti drugim protokolima, i za to je preko TCP-a po\u010deo koristiti protokol TLS, koji je dovoljno pouzdano \u0161titio podatke, ali je dodatno pove\u0107avao vrijeme potrebno za uspostavu veze. Na kraju, proces rukovanja postao je ovakav:<br \/>\n <img decoding=\"async\" alt=\"HTTP\/3: ru\u0161enje temelja i \u010dudesni novi svijet\" src=\"\/wp-content\/uploads\/2019\/11\/2fdccf56e0ed29444557836fdc65351b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Ilustracija Cloudflare<\/i><\/p>\n<p>Tako je HTTP\/1.1 imao niz problema:<\/p>\n<ul>\n<li>Sporo uspostavljanje veze.<\/li>\n<li>Podaci se prenose u tekstualnom formatu, \u0161to zna\u010di da prenos slika, videa i druge netextualne informacije nije efikasan.<\/li>\n<li>Jedna TCP veza se koristi za jedan zahtev, \u0161to zna\u010di da ostali zahtevi moraju ili prona\u0107i drugu vezu ili \u010dekati dok trenutni zahtev ne zavr\u0161i.<\/li>\n<li>Podr\u017eava se samo pull model. U standardu nema ni\u0161ta o server-push.<\/li>\n<li>Zaglavlja se prenose kao tekst.<\/li>\n<\/ul>\n<p>\nAko se server-push nekako implementira putem WebSocket protokola, ostale probleme trebalo je re\u0161avati radikalnije.<\/p>\n<h2>Malo savremenosti: HTTP\/2<\/h2>\n<p>\n2012. godine je unutar Googlea zapo\u010det rad na SPDY protokolu (izgovara se \u201espidi\u201c). Protokol je trebao re\u0161iti glavne probleme HTTP\/1.1 i istovremeno zadr\u017eati unazadne kompatibilnosti. Godine 2015. radna grupa IETF je predstavila specifikaciju HTTP\/2, baziranu na SPDY protokolu. Evo koje su razlike bile u HTTP\/2:<\/p>\n<ul>\n<li>Binarna serijalizacija.<\/li>\n<li>M multiplexiranje vi\u0161e HTTP zahteva u jednu TCP vezu.<\/li>\n<li>Server-push iz kutije (bez WebSocket).<\/li>\n<\/ul>\n<p>\nProtokol je postao veliki korak napred. Znatno <noindex><a rel=\"nofollow\" href=\"https:\/\/http2.akamai.com\/demo\">je br\u017ei od prve verzije<\/a><\/noindex> i ne zahteva stvaranje vi\u0161e TCP veza: svi zahtevi prema jednom hostu se multiplexiraju u jednu. To zna\u010di da u jednoj vezi postoji nekoliko takozvanih strimova, svaki sa svojim ID-om. Bonus dolazi u obliku kutijastog server-push.<\/p>\n<p>Me\u0111utim, multiplexiranje dovodi do drugog temeljnog problema. Zamislite da asinhrono izvr\u0161avamo 5 zahteva prema jednom serveru. Pri kori\u0161\u0107enju HTTP\/2, svi ovi zahtevi \u0107e se izvr\u0161avati u okviru jedne TCP veze, \u0161to zna\u010di da, ako jedan od segmenata bilo kojeg zahteva izgubi ili stigne neispravno, prenos svih zahteva i odgovora \u0107e se zaustaviti dok se izgubljeni segment ne obnovi. O\u010digledno je da \u0161to je kvalitet veze lo\u0161iji, HTTP\/2 radi sporije. <noindex><a rel=\"nofollow\" href=\"https:\/\/http3-explained.haxx.se\/en\/why-tcphol.html\">Prema proceni Danijela Stenberga<\/a><\/noindex>, u uslovima kada izgubljeni paketi \u010dine 2% ukupnog, HTTP\/1.1 u pregledniku pokazuje bolje rezultate od HTTP\/2 jer otvara 6 veza, a ne jednu.<\/p>\n<p>Ovaj problem se naziva \u201ehead-of-line blocking\u201c i, na\u017ealost, nije mogu\u0107e re\u0161iti ga kori\u0161\u0107enjem TCP-a.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: ru\u0161enje temelja i \u010dudesni novi svijet\" src=\"\/wp-content\/uploads\/2019\/11\/234a6dc218a9acf8d2212fbdf28f2188.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Ilustracija Daniel Steinberg<\/i><\/p>\n<p>Kao rezultat, developeri HTTP\/2 standarda su odradili ogroman posao i u\u010dinili gotovo sve \u0161to se moglo posti\u0107i na aplikacijskom nivou OSI modela. Do\u0161lo je vreme da se spustimo na transportni nivo i izumimo novi transportni protokol.<\/p>\n<h2>Potrebna nam je nova protokol: UDP vs TCP<\/h2>\n<p>\nBrzo je postalo jasno da je implementacija potpuno novog transportnog protokola \u2013 zadatak koji je u dana\u0161njim okolnostima neizvediv. Naime, hardver ili srednji ure\u0111aji (usmjeriva\u010di, vatrozidi, NAT poslu\u017eitelji\u2026) poznaju transportni sloj, a podu\u010davanje njih ne\u010demu novom iznimno je slo\u017een zadatak. Osim toga, podr\u0161ka za transportne protokole ugra\u0111ena je u jezgru operativnih sustava, a jezgre se tako\u0111er ne mijenjaju lako.<\/p>\n<p>I ovde bismo mogli da odustanemo i ka\u017eemo: \u201eNaravno, izumet \u0107emo novi HTTP\/3 sa favoritima i kurtizanama, ali implementirati \u0107e biti potrebno 10-15 godina (otprilike toliko vremena \u0107e pro\u0107i pre nego \u0161to se ve\u0107ina hardvera zameni)\u201d, ali postoji jo\u0161 jedna, ne tako o\u010digledna opcija: koristiti UDP protokol. Da, da, taj isti protokol kojim smo razmenjivali fajlove po lokalnoj mre\u017ei krajem devedesetih i po\u010detkom dvehiljaditih. Gotovo svi dana\u0161nji hardveri znaju kako da rade s tim.<\/p>\n<p>Koje su prednosti UDP-a u odnosu na TCP? Prvo, nemamo sesiju transportnog nivoa o kojoj hardver zna. To nam omogu\u0107ava da sami defini\u0161emo sesiju na krajnjim ta\u010dkama i tamo re\u0161avamo eventualne konflikte. Dakle, nismo ograni\u010deni na jednu ili nekoliko sesija (kao kod TCP-a), ve\u0107 mo\u017eemo kreirati koliko god sesija nam je potrebno. Drugo, prenos podataka putem UDP-a je br\u017ei nego putem TCP-a. Tako da, u teoriji, mo\u017eemo probiti dana\u0161nji brzinski plafon postignut u HTTP\/2. <\/p>\n<p>Me\u0111utim, UDP ne garantuje pouzdanost prenosa podataka. U su\u0161tini, jednostavno \u0161aljemo pakete, nadaju\u0107i se da \u0107e ih na drugom kraju primiti. Nisu ih primili? Pa, nije nam i\u0161lo. Ovoga je bilo dovoljno za prenos videa za odrasle, ali za ozbiljnije stvari potrebna je pouzdanost, \u0161to zna\u010di da \u0107emo morati dodati ne\u0161to dodatno preko UDP-a.<\/p>\n<p>Kao i u slu\u010daju HTTP\/2, rad na stvaranju novog protokola zapo\u010deo je u Googleu 2012. godine, otprilike u vreme kada je zapo\u010det rad na SPDY-u. Godine 2013. Jim Roskind je predstavio javnosti <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.google.com\/document\/d\/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34\/edit\">protokol QUIC (Quick UDP Internet Connections)<\/a><\/noindex>, a ve\u0107 2015. godine je podnesen Internet Draft za standardizaciju u IETF-u. Ve\u0107 u to vrijeme, protokol koji je razvio Roskind u Googleu zna\u010dajno se razlikovao od onoga koji je ponu\u0111en za standardizaciju, pa se googleova verzija po\u010dela zvati gQUIC.<\/p>\n<h4>\u0160to je QUIC<\/h4>\n<p>\nPrvo, kao \u0161to je ve\u0107 spomenuto, to je omota\u010d nad UDP-om. Iznad UDP-a se uspostavlja QUIC-connection, u kojem, sli\u010dno HTTP\/2, mogu postojati vi\u0161e streamova. Ovi streamovi postoje samo na krajnjim to\u010dkama i obra\u0111uju se neovisno. Ako do\u0111e do gubitka paketa u jednom streamu, ostali to ne\u0107e ni na koji na\u010din utjecati.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: ru\u0161enje temelja i \u010dudesni novi svijet\" src=\"\/wp-content\/uploads\/2019\/11\/0a64aa26d9b8216db56d389fa48578a5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Ilustracija Daniel Steinberg<\/i><\/p>\n<p>Drugo, enkripcija je sada implementirana ne kao odvojeni sloj, ve\u0107 uklju\u010dena u protokol. To omogu\u0107uje uspostavljanje veze i razmjenu javnih klju\u010deva u jednom rukovanju, kao i kori\u0161tenje pametnog mehanizma 0-RTT handshake, \u0161to uop\u0107e omogu\u0107uje izbjegavanje ka\u0161njenja tijekom rukovanja. Osim toga, sada je mogu\u0107e enkriptirati pojedina\u010dne pakete podataka. To omogu\u0107uje da se ne \u010deka zavr\u0161etak prijema podataka iz streama, ve\u0107 da se primljeni paketi de\u0161ifriraju neovisno. Ovakav na\u010din rada bio je potpuno nemogu\u0107 u TCP-u, jer su TLS i TCP radili neovisno jedno o drugome, a TLS nije mogao znati na koje dijelove \u0107e TCP razbijati podatke. Stoga nije mogao pripremiti svoje segmente kako bi se oni poklapali s TCP segmentima jedan na jedan i mogli biti de\u0161ifrirani neovisno. Sva ta pobolj\u0161anja omogu\u0107uju QUIC-u smanjenje latencije u usporedbi s TCP-om.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: ru\u0161enje temelja i \u010dudesni novi svijet\" src=\"\/wp-content\/uploads\/2019\/11\/cb3c522636f7a052a0f5988fe7ea3a65.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nTre\u0107e, koncept laganih streamova omogu\u0107uje odvajanje veze od IP adrese klijenta. To je va\u017eno, na primjer, kada se klijent prebacuje s jedne Wi-Fi to\u010dke na drugu, mijenjaju\u0107i svoj IP. U ovom slu\u010daju, prilikom kori\u0161tenja TCP-a, dolazi do dugog procesa, tijekom kojeg postoje\u0107e TCP veze propadaju zbog isteka vremena i stvaraju se nove veze s novim IP-om. U slu\u010daju QUIC-a, klijent jednostavno nastavlja slati pakete poslu\u017eitelju s novog IP-a sa starim ID-em streama. Budu\u0107i da je ID streama sada jedinstven i ne ponovo se koristi, poslu\u017eitelj shva\u0107a da je klijent promijenio IP, \u0161alje izgubljene pakete i nastavlja komunikaciju na novoj adresi.<\/p>\n<p>\u010cetvrto, QUIC se implementira na razini aplikacije, a ne operativnog sustava. S jedne strane, to omogu\u0107uje br\u017ee promjene protokola, jer je dovoljno a\u017eurirati biblioteku umjesto da se \u010deka nova verzija OS-a. S druge strane, to dovodi do zna\u010dajnog pove\u0107anja potro\u0161nje procesora.<\/p>\n<p>Za kraj, naslovi. Kompresija naslova je jedan od elemenata koji se razlikuju u QUIC-u i gQUIC-u. Ne vidim smisao posve\u0107ivati tome previ\u0161e vremena, re\u0107i \u0107u samo da je u verziji koja je podnesena za standardizaciju, kompresija naslova u\u010dinjena \u0161to sli\u010dnijom kompresiji naslova u HTTP\/2. Vi\u0161e se mo\u017ee pro\u010ditati <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">ovdje<\/a><\/noindex>.<\/p>\n<h4>Koliko je br\u017ei?<\/h4>\n<p>\nTo je slo\u017eeno pitanje. Naime, jo\u0161 nemamo standard, pa nema puno toga za mjerenje. Mo\u017eda su jedini statisti\u010dki podaci koji imamo \u2013 podaci Googlea, koji koristi gQUIC od 2013. godine i 2016. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.ietf.org\/proceedings\/96\/slides\/slides-96-quic-3.pdf\">izvijestio IETF-u<\/a><\/noindex>, da oko 90% prometa koji ide do njihovih servera iz preglednika Chrome sada koristi QUIC. U istoj prezentaciji navode da se putem gQUIC-a stranice u\u010ditavaju otprilike 5% br\u017ee, a kod streaminga video sadr\u017eaja na 30% manje zamrzavanja u usporedbi s TCP-om. <\/p>\n<p>U 2017. godini grupa istra\u017eiva\u010da predvo\u0111ena Arashom Molavi Kakhkijem objavila je <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">veliko istra\u017eivanje<\/a><\/noindex> o usporedbi performansi gQUIC-a i TCP-a. <br \/>\nIstra\u017eivanje je otkrilo nekoliko slabosti gQUIC-a, poput nestabilnosti na mije\u0161anju mre\u017enih paketa, nepo\u0161tenja u propusnosti kanala i sporiju prijenos malih (do 10 kB) objekata. Posljednje se, me\u0111utim, mo\u017ee nadoknaditi kori\u0161tenjem 0-RTT. U svim ostalim ispitivanim slu\u010dajevima gQUIC je pokazao porast brzine u usporedbi s TCP-om. O konkretnim brojkama ovdje je te\u0161ko govoriti. Bolje je pro\u010ditati <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">samo istra\u017eivanje<\/a><\/noindex> ili <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.apnic.net\/2018\/01\/29\/measuring-quic-vs-tcp-mobile-desktop\/\">kratki post<\/a><\/noindex>.<\/p>\n<p>Ovdje treba napomenuti da su to podaci isklju\u010divo o gQUIC-u, i oni nisu aktualni za razvijeni standard. \u0160to \u0107e biti za QUIC: jo\u0161 uvijek je tajna, ali postoji nada da \u0107e slabosti uo\u010dene kod gQUIC-a biti uzete u obzir i ispravljene.<\/p>\n<h2>Malo o budu\u0107nosti: \u0161to je s HTTP\/3?<\/h2>\n<p>\nEvo ovdje je sve kristalno jasno: API se nikako ne\u0107e promijeniti. Sve \u0107e ostati onako kako je bilo u HTTP\/2. Ako API ostaje isti, prijelaz na HTTP\/3 trebat \u0107e se rje\u0161avati kori\u0161tenjem nove verzije biblioteke na backendu koja podr\u017eava transport preko QUIC-a. Me\u0111utim, jo\u0161 \u0107e dugo trebati zadr\u017eati fallback na stare verzije HTTP-a, jer internet trenutno nije spreman za puni prijelaz na UDP.<\/p>\n<h4>Tko ve\u0107 podr\u017eava<\/h4>\n<p>\nEvo <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/quicwg\/base-drafts\/wiki\/Implementations\">popis<\/a><\/noindex> postoje\u0107e implementacije QUIC-a. Unato\u010d nedostatku standarda, popis je solidan. <\/p>\n<p>Nitko od preglednika trenutno ne podr\u017eava QUIC u produkcijskoj verziji. Nedavno je bilo informacija da je Chrome uklju\u010dio podr\u0161ku za HTTP\/3, ali trenutno samo u Canary verziji. <\/p>\n<p>Od backendova, HTTP\/3 podr\u017eava samo <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/caddyserver\/caddy\">Caddy<\/a><\/noindex> i <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/http3-the-past-present-and-future\/\">Cloudflare<\/a><\/noindex>, ali jo\u0161 uvijek eksperimentalno. NGINX je krajem prolje\u0107a 2019. godine <noindex><a rel=\"nofollow\" href=\"https:\/\/www.nginx.com\/blog\/nginx-1-16-1-17-released\/\">objavili su<\/a><\/noindex>, da su po\u010deli raditi na podr\u0161ci za HTTP\/3, ali jo\u0161 nisu zavr\u0161ili.<\/p>\n<h4>Koji su problemi<\/h4>\n<p>\n\u017divimo u stvarnom svijetu, gdje nijedna velika tehnologija ne mo\u017ee pro\u0107i u mase bez susretanja otpora, a QUIC nije iznimka.<\/p>\n<p>Najva\u017enije je objasniti pregledniku da \"https:\/\/\" sada ne zna\u010di nu\u017eno da vodi na 443. TCP port. Tamo mo\u017eda uop\u0107e nema TCP-a. Za to se koristi Alt-Svc zaglavlje. Ono omogu\u0107ava obavijestiti preglednik da je ova web stranica tako\u0111er dostupna na odre\u0111enom protokolu na odre\u0111enoj adresi. U teoriji, to bi trebalo funkcionirati besprijekorno, ali u praksi \u0107emo se susresti s time da UDP mo\u017ee biti, na primjer, zabranjen na vatrozidu kako bi se sprije\u010dili DDoS napadi.<\/p>\n<p>Ali \u010dak i ako UDP nije zabranjen, klijent mo\u017ee biti iza NAT usmjeriva\u010da koji je konfiguriran za odr\u017eavanje TCP sesije po IP adresi, a budu\u0107i da koristimo UDP, koji nema hardversku sesiju, NAT ne\u0107e odr\u017eavati vezu, i QUIC sesija <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">\u0107e se neprekidno prekidati<\/a><\/noindex>. <\/p>\n<p>Svi ovi problemi vezani su uz \u010dinjenicu da UDP prije nije kori\u0161ten za prijenos internet sadr\u017eaja, i proizvo\u0111a\u010di hardvera nisu mogli predvidjeti da \u0107e se ne\u0161to takvo ikada dogoditi. Sli\u010dno tome, administratori jo\u0161 uvijek ne razumiju najbolje kako ispravno konfigurirati svoje mre\u017ee za rad s QUIC-om. Ova situacija \u0107e se polako mijenjati, i u svakom slu\u010daju, sli\u010dne promjene trajat \u0107e manje vremena nego implementacija novog transportnog protokola. <\/p>\n<p>Osim toga, kao \u0161to je ve\u0107 opisano, QUIC zna\u010dajno pove\u0107ava kori\u0161tenje procesora. Daniel Stenberg <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=idViw4anA6E\">procijenio je<\/a><\/noindex> rast kori\u0161tenja procesora do tri puta.<\/p>\n<h4>Kada \u0107e do\u0107i HTTP\/3<\/h4>\n<p>\nStandard <noindex><a rel=\"nofollow\" href=\"https:\/\/datatracker.ietf.org\/wg\/quic\/about\/\">\u017eele prihvatiti<\/a><\/noindex> do svibnja 2020. godine, no s obzirom na to da su trenutno nedovr\u0161eni dokumenti planirani za srpanj 2019., mo\u017ee se re\u0107i da \u0107e datum vjerojatno biti odgo\u0111en.<\/p>\n<p>Google svoju implementaciju gQUIC koristi jo\u0161 od 2013. godine. Ako pogledamo HTTP zahtjev koji se \u0161alje Google pretra\u017eiva\u010du, mo\u017eemo vidjeti ovo:<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: ru\u0161enje temelja i \u010dudesni novi svijet\" src=\"\/wp-content\/uploads\/2019\/11\/af422268eb85b488c7be1b70c6d33fad.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Zaklju\u010dci<\/h2>\n<p>\nQUIC trenutno izgleda kao prili\u010dno sirova, ali vrlo perspektivna tehnologija. S obzirom na to da se posljednjih 20 godina sve optimizacije transportnih protokola uglavnom ti\u010du TCP-a, QUIC, koji u ve\u0107ini slu\u010dajeva pobje\u0111uje po performansama, ve\u0107 sada izgleda prili\u010dno dobro. <\/p>\n<p>Me\u0111utim, jo\u0161 uvijek postoje nerije\u0161eni problemi s kojima \u0107emo se morati suo\u010diti u sljede\u0107ih nekoliko godina. Proces bi se mogao odu\u017eiti zbog opreme koja se ne voli a\u017eurirati, no sve probleme izgledaju rje\u0161ivo, i prije ili kasnije svi \u0107emo imati HTTP\/3. <\/p>\n<p>Budu\u0107nost nije daleko!<br \/>\n<br \/>Izvor: <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.4 - 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\/hr\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"hr_HR\" \/>\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\/hr\/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: ru\u0161enje temelja i prekrasni novi svijet | ProHoster","description":"Ve\u0107 vi\u0161e od 20 godina gledamo web stranice preko HTTP protokola. Ve\u0107ina korisnika uop\u0107e ne razmi\u0161lja o tome \u0161to to zapravo jest i kako funkcionira.","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/52181","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=52181"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/52181\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=52181"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=52181"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=52181"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}