{"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\/ro\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","title":{"rendered":"HTTP\/3: distrugerea fundamentelor \u0219i o lume nou\u0103 minunat\u0103","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>De peste 20 de ani, vizion\u0103m pagini web prin intermediul protocolului HTTP. Majoritatea utilizatorilor nu se g\u00e2ndesc deloc la ce \u00eenseamn\u0103 \u0219i cum func\u021bioneaz\u0103. Al\u021bii \u0219tiu c\u0103 undeva sub HTTP se afl\u0103 TLS, iar sub acesta TCP, sub care se afl\u0103 IP \u0219i a\u0219a mai departe. Iar al\u021bii \u2013 eretici \u2013 consider\u0103 c\u0103 TCP este ceva din trecut, dorind ceva mai rapid, mai fiabil \u0219i mai sigur. Dar \u00een \u00eencerc\u0103rile lor de a inventa un protocol ideal nou, s-au \u00eentors la tehnologiile anilor '80 \u0219i \u00eencearc\u0103 s\u0103 construiasc\u0103 pe acestea lumea lor nou\u0103 minunat\u0103.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: distrugerea fundamentelor \u0219i o lume nou\u0103 minunat\u0103\" 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>Pu\u021bin\u0103 istorie: HTTP\/1.1<\/h2>\n<p>\n\u00cen 1997, protocolul de schimb de informa\u021bii textuale HTTP versiunea 1.1 a ob\u021binut propriul s\u0103u RFC. Pe atunci, protocolul era deja utilizat de browsere de c\u00e2\u021biva ani, iar noul standard a rezistat \u00eenc\u0103 cincisprezece. Protocolul func\u021biona doar pe principiul cerere-r\u0103spuns \u0219i era destinat \u00een principal pentru transferul de informa\u021bii textuale.<\/p>\n<p>HTTP a fost proiectat s\u0103 func\u021bioneze deasupra protocolului TCP, care garanteaz\u0103 livrarea fiabil\u0103 a pachetelor c\u0103tre destinatar. Func\u021bionarea TCP se bazeaz\u0103 pe stabilirea \u0219i men\u021binerea unei conexiuni fiabile \u00eentre punctele finale \u0219i pe fragmentarea traficului \u00een segmente. Segmentele au un num\u0103r de ordine \u0219i un cod de sumare de control. Dac\u0103, dintr-o dat\u0103, unul dintre segmente nu ajunge sau ajunge cu o sum\u0103 de control gre\u0219it\u0103, transferul se va opri p\u00e2n\u0103 c\u00e2nd segmentul pierdut este recuperat.<\/p>\n<p>\u00cen HTTP\/1.0, conexiunea TCP era \u00eenchis\u0103 dup\u0103 fiecare cerere. Acest lucru era extrem de risipitor, deoarece stabilirea unei conexiuni TCP (3-Way-Handshake) nu este un proces rapid. \u00cen HTTP\/1.1 a fost introdus mecanismul keep-alive, care permite reutilizarea unei conexiuni pentru mai multe cereri. Totu\u0219i, deoarece aceasta poate deveni u\u0219or un punct de bottleneck, \u00een diferitele implement\u0103ri HTTP\/1.1 este permis\u0103 deschiderea mai multor conexiuni TCP c\u0103tre acela\u0219i gazd\u0103. De exemplu, \u00een Chrome \u0219i \u00een versiunile recente de Firefox sunt permise p\u00e2n\u0103 la \u0219ase conexiuni.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: distrugerea fundamentelor \u0219i o lume nou\u0103 minunat\u0103\" src=\"\/wp-content\/uploads\/2019\/11\/b1c131da8e62ace741f3064f2fb96c60.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nCriptarea era de asemenea preconizat\u0103 s\u0103 fie l\u0103sat\u0103 \u00een seama altor protocoale, iar pentru aceasta, deasupra TCP a fost utilizat protocolul TLS, care proteja datele destul de fiabil, dar care ad\u0103uga \u0219i mai mult timp necesar pentru stabilirea conexiunii. \u00cen cele din urm\u0103, procesul de handshake a ajuns s\u0103 arate astfel:<br \/>\n <img decoding=\"async\" alt=\"HTTP\/3: distrugerea fundamentelor \u0219i o lume nou\u0103 minunat\u0103\" src=\"\/wp-content\/uploads\/2019\/11\/2fdccf56e0ed29444557836fdc65351b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Ilustrarea Cloudflare<\/i><\/p>\n<p>Astfel, HTTP\/1.1 avea o serie de probleme:<\/p>\n<ul>\n<li>Instalare lent\u0103 a conexiunii.<\/li>\n<li>Datele sunt transmise \u00een format text, ceea ce face ca transferul de imagini, videoclipuri \u0219i alte informa\u021bii non-text s\u0103 fie ineficient.<\/li>\n<li>O conexiune TCP este utilizat\u0103 pentru o singur\u0103 cerere, ceea ce \u00eenseamn\u0103 c\u0103 celelalte cereri trebuie fie s\u0103 \u00ee\u0219i g\u0103seasc\u0103 o alt\u0103 conexiune, fie s\u0103 a\u0219tepte p\u00e2n\u0103 c\u00e2nd cererea curent\u0103 o elibereaz\u0103.<\/li>\n<li>Este suportat doar modelul pull. Standardul nu con\u021bine nimic despre server-push.<\/li>\n<li>Anteturile sunt transmise \u00een text.<\/li>\n<\/ul>\n<p>\nDac\u0103 server-push este implementat cu ajutorul protocolului WebSocket, atunci restul problemelor trebuie abordate mai radical.<\/p>\n<h2>Pu\u021bin\u0103 modernitate: HTTP\/2<\/h2>\n<p>\n\u00cen 2012, \u00een cadrul Google a \u00eenceput lucrul la protocolul SPDY (se pronun\u021b\u0103 \u201espidi\u201d). Protocolul a fost creat pentru a rezolva problemele principale ale HTTP\/1.1 \u0219i, \u00een acela\u0219i timp, trebuia s\u0103 p\u0103streze compatibilitatea \u00eenapoi. \u00cen 2015, grupul de lucru IETF a prezentat specifica\u021bia HTTP\/2, bazat\u0103 pe protocolul SPDY. Iat\u0103 care au fost diferen\u021bele \u00een HTTP\/2:<\/p>\n<ul>\n<li>Serializare binar\u0103.<\/li>\n<li>Multiplexarea mai multor cereri HTTP \u00eentr-o singur\u0103 conexiune TCP.<\/li>\n<li>Server-push din cutie (f\u0103r\u0103 WebSocket).<\/li>\n<\/ul>\n<p>\nProtocolul a fost un pas mare \u00eenainte. El c\u00e2\u0219tig\u0103 semnificativ fa\u021b\u0103 de prima versiune \u00een vitez\u0103 <noindex><a rel=\"nofollow\" href=\"https:\/\/http2.akamai.com\/demo\">\u0219i nu necesit\u0103 crearea mai multor conexiuni TCP: toate cererile c\u0103tre un singur gazd\u0103 sunt multiplexate \u00eentr-una. Astfel, \u00eentr-o conexiune exist\u0103 mai multe a\u0219a-zise fluxuri, fiecare av\u00e2nd propriul ID. Bonusul include server-push din cutie.<\/a><\/noindex> Cu toate acestea, multiplexarea duce la o alt\u0103 problem\u0103 crucial\u0103. Imagina\u021bi-v\u0103 c\u0103 execut\u0103m \u00een mod asincron 5 cereri c\u0103tre un singur server. Utiliz\u00e2nd HTTP\/2, toate aceste cereri vor fi executate \u00een cadrul unei singure conexiuni TCP, ceea ce \u00eenseamn\u0103 c\u0103, dac\u0103 unul dintre segmentele oric\u0103rei cereri se pierde sau ajunge gre\u0219it, transferul tuturor cererilor \u0219i r\u0103spunsurilor se va opri p\u00e2n\u0103 c\u00e2nd segmentul pierdut este recuperat. Este evident c\u0103, cu c\u00e2t calitatea conexiunii este mai proast\u0103, cu at\u00e2t HTTP\/2 func\u021bioneaz\u0103 mai lent.<\/p>\n<p>Conform evalu\u0103rii lui Daniel Steinberg <noindex><a rel=\"nofollow\" href=\"https:\/\/http3-explained.haxx.se\/en\/why-tcphol.html\">, \u00een condi\u021biile \u00een care pachetele pierdute reprezint\u0103 2% din total, HTTP\/1.1 se dovede\u0219te a fi mai bun \u00een browser dec\u00e2t HTTP\/2, deoarece deschide 6 conexiuni, nu una.<\/a><\/noindex>Aceast\u0103 problem\u0103 se nume\u0219te \u201ehead-of-line blocking\u201d \u0219i, din p\u0103cate, rezolvarea ei utiliz\u00e2nd TCP pare imposibil\u0103.<\/p>\n<p>Ilustra\u021bie Daniel Steinberg<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: distrugerea fundamentelor \u0219i o lume nou\u0103 minunat\u0103\" src=\"\/wp-content\/uploads\/2019\/11\/234a6dc218a9acf8d2212fbdf28f2188.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Ilustra\u021bie Daniel Steinberg<\/i><\/p>\n<p>\u00cen concluzie, dezvoltatorii standardului HTTP\/2 au depus eforturi enorme \u0219i au realizat practic tot ce se putea face la nivelul aplica\u021biilor modelului OSI. A venit momentul s\u0103 cobor\u00e2m la nivelul de transport \u0219i s\u0103 invent\u0103m un nou protocol de transport.<\/p>\n<h2>Avem nevoie de un nou protocol: UDP vs TCP<\/h2>\n<p>\nA devenit destul de clar c\u0103 implementarea unui nou protocol de transport este o sarcin\u0103 imposibil\u0103 \u00een realit\u0103\u021bile de ast\u0103zi. Motivul este c\u0103 echipamentele sau middle-box-urile (routere, firewall-uri, servere NAT...) \u0219tiu doar despre nivelul de transport, iar \u00eenv\u0103\u021barea a ceva nou este o sarcin\u0103 extrem de dificil\u0103. \u00cen plus, suportul pentru protocoalele de transport este \u00eencorporat \u00een kernelul sistemelor de operare, iar nucleele nu schimb\u0103 at\u00e2t de u\u0219or.<\/p>\n<p>\u0218i aici s-ar putea s\u0103 ne pierdem speran\u021ba \u0219i s\u0103 spunem \u201eCu siguran\u021b\u0103, vom inventa noul HTTP\/3 cu preferin\u021be \u0219i curtezane, dar implementarea lui va dura 10-15 ani (aproximativ \u00een acea perioad\u0103 majoritatea dispozitivelor vor fi \u00eenlocuite)\u201d, dar exist\u0103 o alt\u0103 variant\u0103, nu at\u00e2t de evident\u0103: utilizarea protocolului UDP. Da, exact acel protocol cu care ne-am aruncat fi\u0219ierele prin re\u021bea la sf\u00e2r\u0219itul anilor \u201990 \u0219i \u00eenceputul anilor 2000. Practic toate dispozitivele de ast\u0103zi pot lucra cu el.<\/p>\n<p>Care sunt avantajele UDP \u00een compara\u021bie cu TCP? \u00cen primul r\u00e2nd, nu avem o sesiune la nivel de transport, despre care \u0219tie hardware-ul. Acest lucru ne permite s\u0103 definim singuri sesiunea la punctele finale \u0219i s\u0103 gestion\u0103m acolo conflictele care apar. Adic\u0103 nu suntem limita\u021bi la una sau mai multe sesiuni (ca \u00een cazul TCP), ci putem crea at\u00e2t de multe c\u00e2te avem nevoie. \u00cen al doilea r\u00e2nd, transferul de date prin UDP se face mai repede dec\u00e2t prin TCP. Astfel, teoretic, putem dep\u0103\u0219i limita actual\u0103 de vitez\u0103 atins\u0103 \u00een HTTP\/2. <\/p>\n<p>Cu toate acestea, UDP nu garanteaz\u0103 fiabilitatea transferului de date. De fapt, trimitem pur \u0219i simplu pachete, sper\u00e2nd c\u0103 de cealalt\u0103 parte le vor primi. Nu le-au primit? Ei bine, nu a fost noroc... Acest lucru a fost suficient pentru a transmite video pentru adul\u021bi, dar pentru lucruri mai serioase este nevoie de fiabilitate, ceea ce \u00eenseamn\u0103 c\u0103 va trebui s\u0103 ad\u0103ug\u0103m ceva deasupra UDP-ului.<\/p>\n<p>A\u0219a cum s-a \u00eent\u00e2mplat \u0219i \u00een cazul HTTP\/2, lucr\u0103rile pentru crearea unui nou protocol au \u00eenceput la Google \u00een 2012, adic\u0103 aproximativ \u00een aceea\u0219i perioad\u0103 cu \u00eenceputul lucrului la SPDY. \u00cen 2013, Jim Roskind a prezentat publicului larg <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.google.com\/document\/d\/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34\/edit\">protocolul QUIC (Quick UDP Internet Connections)<\/a><\/noindex>, \u0219i deja \u00een 2015 a fost inclus un Internet Draft pentru standardizare \u00een IETF. Deja la acel moment, protocolul dezvoltat de Roskind la Google se deosebea semnificativ de standardul propus, a\u0219a c\u0103 versiunea Google a \u00eenceput s\u0103 fie numit\u0103 gQUIC.<\/p>\n<h4>Ce este QUIC<\/h4>\n<p>\n\u00cen primul r\u00e2nd, a\u0219a cum s-a men\u021bionat, este un wrapper peste UDP. Peste UDP se construie\u0219te o conexiune QUIC, unde, similar cu HTTP\/2, pot exista mai multe fluxuri. Aceste fluxuri exist\u0103 doar la punctele finale \u0219i sunt gestionate independent. Dac\u0103 un pachet se pierde \u00eentr-un flux, celelalte nu sunt afectate.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: distrugerea fundamentelor \u0219i o lume nou\u0103 minunat\u0103\" src=\"\/wp-content\/uploads\/2019\/11\/0a64aa26d9b8216db56d389fa48578a5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Ilustra\u021bie Daniel Steinberg<\/i><\/p>\n<p>\u00cen al doilea r\u00e2nd, criptarea este acum implementat\u0103 nu ca un nivel separat, ci este integrat\u0103 \u00een protocol. Acest lucru permite stabilirea conexiunii \u0219i schimbul de chei publice \u00eentr-o singur\u0103 str\u00e2ngere de m\u00e2n\u0103, precum \u0219i utilizarea unui mecanism ingenios de 0-RTT handshake, evit\u00e2nd astfel \u00eent\u00e2rzierile la str\u00e2ngerea de m\u00e2n\u0103. \u00cen plus, acum este posibil s\u0103 se cripteze pachete de date separate. Acest lucru permite decriptarea pachetelor primite independent, f\u0103r\u0103 a a\u0219tepta finalizarea primirii datelor din flux. Acest mod de operare era \u00een general imposibil \u00een TCP, deoarece TLS \u0219i TCP func\u021bionau independent unul de cel\u0103lalt, \u0219i TLS nu putea \u0219ti pe ce buc\u0103\u021bi va t\u0103ia datele TCP. Prin urmare, nu putea preg\u0103ti segmentele sale astfel \u00eenc\u00e2t acestea s\u0103 se aliniaz\u0103 segmentelor TCP unul c\u00e2te unul \u0219i s\u0103 poat\u0103 fi decriptate independent. Toate aceste \u00eembun\u0103t\u0103\u021biri permit QUIC s\u0103 reduc\u0103 laten\u021ba comparativ cu TCP.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: distrugerea fundamentelor \u0219i o lume nou\u0103 minunat\u0103\" src=\"\/wp-content\/uploads\/2019\/11\/cb3c522636f7a052a0f5988fe7ea3a65.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n\u00cen al treilea r\u00e2nd, conceptul de fluxuri u\u0219oare permite debarasarea conexiunii de adresa IP a clientului. Acest lucru este important, de exemplu, atunci c\u00e2nd clientul comut\u0103 de la un acces Wi-Fi la altul, schimb\u00e2ndu-\u0219i astfel IP-ul. \u00cen acest caz, utiliz\u00e2nd TCP, are loc un proces lung, \u00een care conexiunile TCP existente cad din cauza timeout-ului \u0219i se creeaz\u0103 noi conexiuni cu noul IP. \u00cen cazul QUIC, clientul continu\u0103 pur \u0219i simplu s\u0103 trimit\u0103 pachete serverului de pe noul IP cu vechiul ID al fluxului. Deoarece ID-ul fluxului este acum unic \u0219i nu este reutilizat, serverul \u00een\u021belege c\u0103 clientul a schimbat IP-ul, retransmite pachetele pierdute \u0219i continu\u0103 comunica\u021bia pe noua adres\u0103.<\/p>\n<p>\u00cen al patrulea r\u00e2nd, QUIC este implementat la nivelul aplica\u021biei, nu al sistemului de operare. Acest lucru, pe de o parte, permite modific\u0103ri mai rapide ale protocolului, deoarece pentru a ob\u021bine o actualizare este suficient s\u0103 actualizezi biblioteca, f\u0103r\u0103 a a\u0219tepta o nou\u0103 versiune a sistemului de operare. Pe de alt\u0103 parte, aceasta duce la o cre\u0219tere semnificativ\u0103 a consumului de procesor.<\/p>\n<p>\u0218i la final, s\u0103 discut\u0103m despre antete. Compresia antetelor se num\u0103r\u0103 printre aspectele care difer\u0103 \u00een QUIC \u0219i gQUIC. Nu v\u0103d sens \u00een a dedica prea mult timp acestui subiect, voi men\u021biona doar c\u0103 \u00een versiunea supus\u0103 standardiz\u0103rii, compresia antetelor a fost f\u0103cut\u0103 c\u00e2t mai asem\u0103n\u0103toare cu compresia antetelor din HTTP\/2. Mai multe detalii pot fi citite <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">aici<\/a><\/noindex>.<\/p>\n<h4>C\u00e2t de rapid este?<\/h4>\n<p>\nAceasta este o \u00eentrebare complex\u0103. Problema este c\u0103, deocamdat\u0103, nu avem un standard, a\u0219a c\u0103 nu prea avem ce m\u0103sura. Probabil, singurele date statistice de care dispunem sunt cele de la Google, care folose\u0219te gQUIC din 2013 \u0219i \u00een 2016 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.ietf.org\/proceedings\/96\/slides\/slides-96-quic-3.pdf\">a raportat \u00een fa\u021ba IETF<\/a><\/noindex>, c\u0103 aproximativ 90% din traficul c\u0103tre serverele lor din browserul Chrome utilizeaz\u0103 acum QUIC. \u00cen aceea\u0219i prezentare, ei anun\u021b\u0103 c\u0103 prin gQUIC paginile se \u00eencarc\u0103 cu aproximativ 5% mai rapid, iar la redarea video sunt cu 30% mai pu\u021bine blocaje comparativ cu TCP. <\/p>\n<p>\u00cen 2017, un grup de cercet\u0103tori condus de Arash Molavi Kakhki a publicat <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">o munc\u0103 semnificativ\u0103<\/a><\/noindex> o cercetare asupra performan\u021bei gQUIC comparativ cu TCP. <br \/>\nStudiul a identificat c\u00e2teva sl\u0103biciuni ale gQUIC, cum ar fi instabilitatea la amestecarea pachetelor de re\u021bea, egoismul \u00een utilizarea l\u0103\u021bimii de band\u0103 \u0219i o transmitere mai lent\u0103 a obiectelor mici (de p\u00e2n\u0103 la 10 kB). Acest din urm\u0103 aspect, \u00eens\u0103, se compenseaz\u0103 prin utilizarea 0-RTT. \u00cen toate celelalte cazuri studiate, gQUIC a demonstrat o cre\u0219tere a vitezei comparativ cu TCP. Despre cifre concrete este dificil de vorbit. Cel mai bine este s\u0103 citi\u021bi <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">studiul \u00een sine<\/a><\/noindex> sau <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.apnic.net\/2018\/01\/29\/measuring-quic-vs-tcp-mobile-desktop\/\">o postare scurt\u0103<\/a><\/noindex>.<\/p>\n<p>Aici trebuie men\u021bionat c\u0103 aceste date se refer\u0103 strict la gQUIC \u0219i nu sunt actuale pentru standardul \u00een dezvoltare. Ce va fi pentru QUIC: deocamdat\u0103 este un mister, dar exist\u0103 speran\u021ba c\u0103 sl\u0103biciunile identificate la gQUIC vor fi luate \u00een considerare \u0219i corectate.<\/p>\n<h2>Pu\u021bin despre viitor: ce se \u00eent\u00e2mpl\u0103 cu HTTP\/3?<\/h2>\n<p>\n\u0218i aici este totul clar: API-ul nu se va schimba. Totul va r\u0103m\u00e2ne exact la fel ca \u00een HTTP\/2. Dac\u0103 API-ul r\u0103m\u00e2ne acela\u0219i, trecerea la HTTP\/3 va necesita utilizarea unei versiuni noi a bibliotecii pe backend, care suport\u0103 transportul prin QUIC. Totu\u0219i, va trebui s\u0103 men\u021binem un fallback pentru versiunile vechi de HTTP, deoarece internetul nu este preg\u0103tit pentru o tranzi\u021bie complet\u0103 la UDP.<\/p>\n<h4>Cine deja suport\u0103<\/h4>\n<p>\nIat\u0103 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/quicwg\/base-drafts\/wiki\/Implementations\">list\u0103<\/a><\/noindex> implement\u0103rilor existente QUIC. De\u0219i nu exist\u0103 un standard, lista nu este rea. <\/p>\n<p>Niciun browser nu suport\u0103 \u00een prezent QUIC \u00een versiunea de produc\u021bie. Recent, a existat informa\u021bia c\u0103 Chrome a activat suportul pentru HTTP\/3, dar deocamdat\u0103 doar \u00een Canary. <\/p>\n<p>Dintre backend-uri, HTTP\/3 este suportat doar de <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/caddyserver\/caddy\">Caddy<\/a><\/noindex> \u0219i <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/http3-the-past-present-and-future\/\">Cloudflare<\/a><\/noindex>, dar deocamdat\u0103 experimental. NGINX, la sf\u00e2r\u0219itul prim\u0103verii 2019, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.nginx.com\/blog\/nginx-1-16-1-17-released\/\">au anun\u021bat<\/a><\/noindex>, a anun\u021bat c\u0103 lucreaz\u0103 la suportul pentru HTTP\/3, dar deocamdat\u0103 nu a finalizat.<\/p>\n<h4>Ce probleme exist\u0103<\/h4>\n<p>\nTr\u0103im \u00eentr-o lume real\u0103, \u00een care nicio tehnologie mare nu poate ajunge la mas\u0103 f\u0103r\u0103 a \u00eent\u00e2lni rezisten\u021b\u0103, iar QUIC nu este o excep\u021bie.<\/p>\n<p>Cel mai important, trebuie cumva s\u0103 explic\u0103m browserului c\u0103 \"https:\/\/\" acum nu mai \u00eenseamn\u0103 neap\u0103rat c\u0103 duce la portul TCP 443. S-ar putea s\u0103 nu existe deloc TCP. Pentru aceasta se folose\u0219te antetul Alt-Svc. Acesta permite browserului s\u0103 comunice c\u0103 acest site web este de asemenea disponibil pe un alt protocol la o anumit\u0103 adres\u0103. \u00cen teorie, aceasta ar trebui s\u0103 func\u021bioneze perfect, dar \u00een practic\u0103 vom \u00eent\u00e2lni probleme, cum ar fi faptul c\u0103 UDP ar putea fi, de exemplu, interzis pe firewall pentru a evita atacurile DDoS.<\/p>\n<p>Dar chiar dac\u0103 UDP nu este interzis, clientul ar putea fi \u00een spatele unui router NAT, care este configurat s\u0103 men\u021bin\u0103 sesiunea TCP pe adresa IP, iar cum noi folosim UDP, care nu are sesiuni hardware, NAT nu va men\u021bine conexiunea, iar sesiunea QUIC <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">va fi constant \u00eentrerupt\u0103.<\/a><\/noindex>. <\/p>\n<p>Toate aceste probleme sunt legate de faptul c\u0103 UDP nu a fost folosit anterior pentru transmiterea con\u021binutului internetului, iar produc\u0103torii de echipamente nu au putut prevedea c\u0103 a\u0219a ceva se va \u00eent\u00e2mpla vreodat\u0103. La fel, administratorii nu \u00een\u021beleg \u00eenc\u0103 foarte bine cum s\u0103 \u00ee\u0219i configureze re\u021belele pentru a func\u021biona cu QUIC. Aceast\u0103 situa\u021bie se va schimba treptat, \u0219i, \u00een orice caz, astfel de schimb\u0103ri vor dura mai pu\u021bin timp dec\u00e2t implementarea unui nou protocol de transport. <\/p>\n<p>\u00cen plus, a\u0219a cum a fost deja descris, QUIC cre\u0219te semnificativ utilizarea procesorului. Daniel Stenberg <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=idViw4anA6E\">a evaluat<\/a><\/noindex> cre\u0219terea procesorului p\u00e2n\u0103 la de trei ori.<\/p>\n<h4>C\u00e2nd va fi HTTP\/3<\/h4>\n<p>\nStandard <noindex><a rel=\"nofollow\" href=\"https:\/\/datatracker.ietf.org\/wg\/quic\/about\/\">vor s\u0103 accepte<\/a><\/noindex> \u00cen mai 2020, av\u00e2nd \u00een vedere c\u0103, \u00een prezent, documentele planificate pentru iulie 2019 r\u0103m\u00e2n incomplete, se poate spune c\u0103 data va fi, cel mai probabil, am\u00e2nat\u0103.<\/p>\n<p>\u00cencep\u00e2nd din 2013, Google folose\u0219te propria implementare gQUIC. Dac\u0103 ne uit\u0103m la cererea HTTP trimis\u0103 motorului de c\u0103utare Google, putem observa asta:<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: distrugerea fundamentelor \u0219i o lume nou\u0103 minunat\u0103\" src=\"\/wp-content\/uploads\/2019\/11\/af422268eb85b488c7be1b70c6d33fad.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Conclusions<\/h2>\n<p>\nQUIC pare \u00een prezent o tehnologie destul de neterminat\u0103, dar foarte promi\u021b\u0103toare. Av\u00e2nd \u00een vedere c\u0103 \u00een ultimii 20 de ani toate optimiz\u0103rile protocoalelor de transport s-au concentrat \u00een principal pe TCP, QUIC, c\u00e2\u0219tig\u00e2nd \u00een majoritatea cazurilor \u00een performan\u021b\u0103, arat\u0103 deja foarte bine. <\/p>\n<p>Cu toate acestea, \u00eenc\u0103 exist\u0103 probleme nerezolvate cu care va trebui s\u0103 facem fa\u021b\u0103 \u00een urm\u0103torii c\u00e2\u021biva ani. Procesul poate dura mai mult din cauza hardware-ului, pe care nimeni nu \u00eel iube\u0219te s\u0103-l actualizeze, dar toate problemele par a fi solu\u021bionabile, iar mai devreme sau mai t\u00e2rziu vom avea cu to\u021bii HTTP\/3. <\/p>\n<p>Viitorul nu este departe!<br \/>\n<br \/>Sursa: <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.2 - 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\/ro\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"ro_RO\" \/>\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\/ro\/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: distrugerea funda\u021biilor \u0219i o lume nou\u0103 minunat\u0103 | ProHoster","description":"De peste 20 de ani ne uit\u0103m la paginile web prin protocolul HTTP. Majoritatea utilizatorilor nu se g\u00e2nde\u0219te deloc la ce este \u0219i cum func\u021bioneaz\u0103.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","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\/ro\/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\/ro\/wp-json\/wp\/v2\/posts\/52181","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=52181"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/52181\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=52181"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=52181"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=52181"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}