{"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\/sq\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","title":{"rendered":"HTTP\/3: shkat\u00ebrrimi i bazave dhe nj\u00eb bot\u00eb e re e \u00e7uditshme","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>K\u00ebto 20 vitet e fundit, ne kemi eksploruar faqet e internetit p\u00ebrmes protokollit HTTP. Shumica e p\u00ebrdoruesve nuk mendojn\u00eb kurr\u00eb se \u00e7far\u00eb \u00ebsht\u00eb dhe si funksionon. T\u00eb tjer\u00eb e din\u00eb se n\u00ebn HTTP q\u00ebndron TLS, dhe n\u00ebn t\u00eb TCP, n\u00ebn t\u00eb IP, etj. Nd\u00ebrsa t\u00eb tret\u00eb - heretik\u00ebt - mendojn\u00eb se TCP \u00ebsht\u00eb nj\u00eb gj\u00eb e kaluar, ata synojn\u00eb di\u00e7ka m\u00eb t\u00eb shpejt\u00eb, t\u00eb besueshme dhe t\u00eb sigurt. Por n\u00eb p\u00ebrpjekjet e tyre p\u00ebr t\u00eb shpikur nj\u00eb protokoll ideal t\u00eb ri, ata jan\u00eb rikthyer te teknologjit\u00eb e viteve '80 dhe p\u00ebrpiqen t\u00eb nd\u00ebrtojn\u00eb mbi to nj\u00eb bot\u00eb t\u00eb re, t\u00eb mrekullueshme.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: shkat\u00ebrrimi i bazave dhe nj\u00eb bot\u00eb e re e \u00e7uditshme\" 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>Pak histori: HTTP\/1.1<\/h2>\n<p>\nN\u00eb vitin 1997, protokolli i shk\u00ebmbimit t\u00eb informacionit tekstual HTTP versioni 1.1 mori RFC-n\u00eb e tij. N\u00eb at\u00eb koh\u00eb, protokolli ishte p\u00ebrdorur nga shfletuesit p\u00ebr disa vite, dhe standardi i ri q\u00ebndroi p\u00ebr pes\u00ebmb\u00ebdhjet\u00eb vjet t\u00eb tjera. Protokolli punonte vet\u00ebm mbi baz\u00ebn e nj\u00eb modeli k\u00ebrkes\u00eb-p\u00ebrgjigje dhe ishte kryesisht i dedikuar p\u00ebr transmetimin e informacionit tekstual.<\/p>\n<p>HTTP ishte dizajnuar p\u00ebr t\u00eb punuar mbi protokollin TCP, q\u00eb garanton dor\u00ebzimin e besuesh\u00ebm t\u00eb paketave deri te destinacioni. Funksionimi i TCP bazuar n\u00eb vendosjen dhe mbajtjen e nj\u00eb lidhjeje t\u00eb besueshme midis pikave p\u00ebrfundimtare dhe ndarjes s\u00eb trafik\u00ebve n\u00eb segmente. Segmentet kan\u00eb numrin e tyre sekondar dhe nj\u00eb checksum. N\u00ebse ndonj\u00ebher\u00eb ndonj\u00eb nga segmentet nuk mb\u00ebrrin ose arrin me nj\u00eb checksum t\u00eb gabuar, at\u00ebher\u00eb shk\u00ebmbimi do t\u00eb ndaloj\u00eb derisa t\u00eb rikuperohet segmenti i humbur.<\/p>\n<p>N\u00eb HTTP\/1.0, lidhja TCP u mbyll pas \u00e7do k\u00ebrkese. Kjo ishte jasht\u00ebzakonisht e shpenzuar, pasi vendosja e lidhjes TCP (3-Way-Handshake) \u00ebsht\u00eb nj\u00eb proces i ngadalsh\u00ebm. N\u00eb HTTP\/1.1 u prezantua mekanizmi keep-alive, i cili lejon rinovimin e nj\u00eb lidhje p\u00ebr disa k\u00ebrkesa. Megjithat\u00eb, pasi mund t\u00eb b\u00ebhet leht\u00ebsisht nj\u00eb ngushtic\u00eb, n\u00eb implementime t\u00eb ndryshme t\u00eb HTTP\/1.1 lejohet hapja e disa lidhjeve TCP p\u00ebr nj\u00eb host t\u00eb vet\u00ebm. P\u00ebr shembull, n\u00eb Chrome dhe n\u00eb versionet e fundit t\u00eb Firefox \u00ebsht\u00eb e lejuar deri n\u00eb gjasht\u00eb lidhje.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: shkat\u00ebrrimi i bazave dhe nj\u00eb bot\u00eb e re e \u00e7uditshme\" src=\"\/wp-content\/uploads\/2019\/11\/b1c131da8e62ace741f3064f2fb96c60.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nKriptimi parashikohej gjithashtu t\u00eb ishte l\u00ebn\u00eb n\u00eb duar t\u00eb protokolleve t\u00eb tjera, dhe p\u00ebr k\u00ebt\u00eb arsye mbi TCP filloi p\u00ebrdorimi i protokollit TLS, i cili mbron me besueshm\u00ebri t\u00eb dh\u00ebnat, por gjithashtu rriti m\u00eb tej koh\u00ebn e nevojshme p\u00ebr vendosjen e lidhjes. N\u00eb p\u00ebrfundim, procesi i dor\u00ebzimit duket k\u00ebshtu:<br \/>\n <img decoding=\"async\" alt=\"HTTP\/3: shkat\u00ebrrimi i bazave dhe nj\u00eb bot\u00eb e re e \u00e7uditshme\" src=\"\/wp-content\/uploads\/2019\/11\/2fdccf56e0ed29444557836fdc65351b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Ilustrimi Cloudflare<\/i><\/p>\n<p>K\u00ebshtu, HTTP\/1.1 kishte nj\u00eb s\u00ebr\u00eb problemesh:<\/p>\n<ul>\n<li>Vendosje e ngadalshme e lidhjes.<\/li>\n<li>T\u00eb dh\u00ebnat transmetohen n\u00eb nj\u00eb format tekstual, q\u00eb do t\u00eb thot\u00eb se transmetimi i imazheve, videove dhe informacionit tjet\u00ebr jo-tekstual nuk \u00ebsht\u00eb efikas.<\/li>\n<li>Nj\u00eb lidhje TCP p\u00ebrdoret p\u00ebr nj\u00eb k\u00ebrkes\u00eb, k\u00ebshtu q\u00eb k\u00ebrkesat e tjera duhet ose t\u00eb gjejn\u00eb nj\u00eb lidhje tjet\u00ebr ose t\u00eb presin derisa k\u00ebrkesa aktuale t\u00eb lirohet.<\/li>\n<li>Mb\u00ebshtetet vet\u00ebm modeli pull. N\u00eb standard nuk ka asgj\u00eb p\u00ebr server-push.<\/li>\n<li>Header-at transmetohen si tekst.<\/li>\n<\/ul>\n<p>\nN\u00ebse server-push realizohet mjaft mir\u00eb p\u00ebrmes protokollit WebSocket, at\u00ebher\u00eb me problemet e tjera do t\u00eb duhej t\u00eb merreshim m\u00eb radikalisht.<\/p>\n<h2>Pak modernitet: HTTP\/2<\/h2>\n<p>\nN\u00eb vitin 2012, n\u00eb brend\u00ebsi t\u00eb Google filloi puna mbi protokollin SPDY (shkruhet 'spidi'). Protokolli u krijua p\u00ebr t\u00eb zgjidhur problemet kryesore t\u00eb HTTP\/1.1 dhe gjithashtu duhet t\u00eb ruante prapavij\u00ebn p\u00ebrkat\u00ebse. N\u00eb vitin 2015, grupi i pun\u00ebs IETF paraqiti specifikimin HTTP\/2, i bazuar n\u00eb protokollin SPDY. K\u00ebtu jan\u00eb ndryshimet n\u00eb HTTP\/2:<\/p>\n<ul>\n<li>Serializimi binar.<\/li>\n<li>Multipleximi i disa k\u00ebrkesave HTTP n\u00eb nj\u00eb lidhje TCP.<\/li>\n<li>Server-push nga kutia (pa WebSocket).<\/li>\n<\/ul>\n<p>\nProtokolli b\u00ebri nj\u00eb hap t\u00eb madh p\u00ebrpara. Ai <noindex><a rel=\"nofollow\" href=\"https:\/\/http2.akamai.com\/demo\">fiton ndjesh\u00ebm ndaj versionit t\u00eb par\u00eb n\u00eb shpejt\u00ebsi<\/a><\/noindex> dhe nuk k\u00ebrkon krijimin e disa lidhjeve TCP: t\u00eb gjitha k\u00ebrkesat p\u00ebr nj\u00eb host jan\u00eb t\u00eb multipluara n\u00eb nj\u00eb. Pra, n\u00eb nj\u00eb lidhje ka disa 'streams', secili me ID-n\u00eb e tij. Si bonus, vjen server-push i kutis\u00eb.<\/p>\n<p>Megjithat\u00eb, multipleximi shpien n\u00eb nj\u00eb problem tjet\u00ebr themelor. Imagjinoni se ne ekzekutojm\u00eb asinkronikisht 5 k\u00ebrkesa p\u00ebr nj\u00eb server t\u00eb vet\u00ebm. Kur p\u00ebrdorim HTTP\/2, t\u00eb gjitha k\u00ebto k\u00ebrkesa do t\u00eb ekzekutohen n\u00eb kuad\u00ebr t\u00eb nj\u00eb lidhje TCP, dhe k\u00ebshtu, n\u00ebse nj\u00eb nga segmentet e ndonj\u00eb k\u00ebrkese humbet ose arrin gabim, transmetimi i t\u00eb gjitha k\u00ebrkesave dhe p\u00ebrgjigjeve do t\u00eb ndaloj\u00eb derisa t\u00eb rikuperohet segmenti i humbur. \u00cbsht\u00eb evidente se sa m\u00eb keq t\u00eb jet\u00eb cil\u00ebsia e lidhjes, aq m\u00eb ngadal\u00eb funksionon HTTP\/2. <noindex><a rel=\"nofollow\" href=\"https:\/\/http3-explained.haxx.se\/en\/why-tcphol.html\">Sipas Daniel Steinberg<\/a><\/noindex>, n\u00eb kushte ku paketat e humbura p\u00ebrb\u00ebjn\u00eb 2% t\u00eb t\u00eb gjitha, HTTP\/1.1 n\u00eb shfletues tregon m\u00eb mir\u00eb se HTTP\/2 duke hapur 6 lidhje, jo nj\u00eb.<\/p>\n<p>Ky problem quhet 'blocking i head-of-line' dhe, fatkeq\u00ebsisht, nuk duket se mund t\u00eb zgjidhet duke p\u00ebrdorur TCP.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: shkat\u00ebrrimi i bazave dhe nj\u00eb bot\u00eb e re e \u00e7uditshme\" src=\"\/wp-content\/uploads\/2019\/11\/234a6dc218a9acf8d2212fbdf28f2188.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Ilustrimi Daniel Steinberg<\/i><\/p>\n<p>Si p\u00ebrfundim, zhvilluesit e standardit HTTP\/2 b\u00ebn\u00eb nj\u00eb pun\u00eb t\u00eb jasht\u00ebzakonshme dhe b\u00ebn\u00eb praktikisht gjith\u00e7ka q\u00eb mund t\u00eb b\u00ebhej n\u00eb nivelin aplikativ t\u00eb modelit OSI. Ka ardhur koha t\u00eb kalojm\u00eb n\u00eb nivelin e transportit dhe t\u00eb shpikim nj\u00eb protokoll t\u00eb ri transporti.<\/p>\n<h2>Na nevoja nj\u00eb protokoll t\u00eb ri: UDP vs TCP<\/h2>\n<p>\nShpejt u kuptua se implementimi i nj\u00eb protokolli t\u00eb ri t\u00eb nivelit t\u00eb transportit \u00ebsht\u00eb nj\u00eb detyr\u00eb e pamundur n\u00eb realitetin e sot\u00ebm. Problemi \u00ebsht\u00eb se pajisjet e nivelit t\u00eb transportit, si ruter\u00ebt, firewall-et, dhe server\u00ebt NAT, kan\u00eb njohuri t\u00eb caktuara, dhe \u00ebsht\u00eb jasht\u00ebzakonisht e v\u00ebshtir\u00eb t'i m\u00ebsohet atyre di\u00e7ka t\u00eb re. P\u00ebr m\u00eb tep\u00ebr, mb\u00ebshtetje p\u00ebr protokollet e transportit \u00ebsht\u00eb e integruar n\u00eb b\u00ebrtham\u00ebn e sistemeve operative, dhe b\u00ebrthamat nuk ndryshojn\u00eb leht\u00ebsisht.<\/p>\n<p>Dhe k\u00ebtu mund t\u00eb heqim dor\u00eb dhe t\u00eb themi \"Sigurisht, do ta shpikim nj\u00eb HTTP\/3 me preferenca dhe kurtizana, por do t\u00eb zbatohen p\u00ebr 10-15 vjet (af\u00ebrsisht n\u00eb at\u00eb koh\u00eb shumica e pajisjeve do t\u00eb z\u00ebvend\u00ebsohen)\", por ka nj\u00eb opsion tjet\u00ebr jo aq t\u00eb duksh\u00ebm: t\u00eb p\u00ebrdorim protokollin UDP. Po, ai protokoll mbi t\u00eb cilin ne d\u00ebrgonim skedar\u00eb n\u00eb rrjetin lokal n\u00eb fund t\u00eb viteve '90 dhe fillim t\u00eb viteve 2000. Praktikisht t\u00eb gjitha pajisjet e sotme din\u00eb t\u00eb punojn\u00eb me t\u00eb.<\/p>\n<p>Cilat jan\u00eb avantazhet e UDP n\u00eb krahasim me TCP? S\u00eb pari, \u00ebsht\u00eb se nuk kemi sesion n\u00eb nivelin e transportit, p\u00ebr t\u00eb cilin pajisjet jan\u00eb t\u00eb informuara. Kjo na lejon t\u00eb p\u00ebrcaktojm\u00eb vet\u00eb sesionin n\u00eb pikat p\u00ebrfundimtare dhe atje t\u00eb zgjidhim konfliktet q\u00eb lindin. K\u00ebshtu, ne nuk jemi t\u00eb kufizuar n\u00eb nj\u00eb ose disa seanca (si n\u00eb TCP), por mund t\u00eb krijojm\u00eb sa m\u00eb shum\u00eb sa na nevojitet. S\u00eb dyti, transferi i t\u00eb dh\u00ebnave p\u00ebrmes UDP ndodh m\u00eb shpejt se p\u00ebrmes TCP. Prandaj, n\u00eb teori, mund t\u00eb kalojm\u00eb plafonin e shpejt\u00ebsis\u00eb aktual t\u00eb arritur n\u00eb HTTP\/2. <\/p>\n<p>Megjithat\u00eb, UDP nuk garanton besueshm\u00ebrin\u00eb e transferimit t\u00eb t\u00eb dh\u00ebnave. N\u00eb thelb, ne thjesht d\u00ebrgojm\u00eb paketa, duke shpresuar se do t\u00eb marrin n\u00eb an\u00ebn tjet\u00ebr. Nuk e mor\u00ebn? Fatkeq\u00ebsisht... Kjo ishte e mjaftueshme p\u00ebr transmetimin e videove p\u00ebr t\u00eb rritur, por p\u00ebr gj\u00ebra m\u00eb serioze na nevojitet besueshm\u00ebria, dhe kjo do t\u00eb thot\u00eb se do t\u00eb duhet t\u00eb shtojm\u00eb di\u00e7ka t\u00eb tjera mbi UDP.<\/p>\n<p>Ashtu si n\u00eb rastin e HTTP\/2, puna p\u00ebr krijimin e nj\u00eb protokolli t\u00eb ri filloi n\u00eb Google n\u00eb vitin 2012, pra rreth t\u00eb nj\u00ebjt\u00ebs koh\u00eb me fillimin e pun\u00ebs mbi SPDY. N\u00eb vitin 2013, Jim Roskind e prezantoi p\u00ebr publikun e gjer\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.google.com\/document\/d\/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34\/edit\">protokollin QUIC (Quick UDP Internet Connections)<\/a><\/noindex>, dhe gjat\u00eb vitit 2015, u paraqit nj\u00eb Draft Interneti p\u00ebr standardizim n\u00eb IETF. N\u00eb at\u00eb koh\u00eb, protokolli i zhvilluar nga Roskind n\u00eb Google dallohej ndjesh\u00ebm nga ai q\u00eb ishte propozuar p\u00ebr standardizim, prandaj versioni i Google u quajt gQUIC.<\/p>\n<h4>\u00c7far\u00eb \u00ebsht\u00eb QUIC<\/h4>\n<p>\nS\u00eb pari, si\u00e7 u tha m\u00eb par\u00eb, \u00ebsht\u00eb nj\u00eb mb\u00ebshtjell\u00ebs mbi UDP. Pjesa mbi UDP ngjitet QUIC-connection, n\u00eb t\u00eb cil\u00ebn, ngjash\u00ebm me HTTP\/2, mund t\u00eb ekzistojn\u00eb disa stream. K\u00ebto stream ekzistojn\u00eb vet\u00ebm n\u00eb pikat p\u00ebrfundimtare dhe sh\u00ebrbehen n\u00eb m\u00ebnyr\u00eb t\u00eb pavarur. N\u00ebse ndodhi humbja e nj\u00eb pakete n\u00eb nj\u00eb stream, t\u00eb tjer\u00ebt nuk preken fare.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: shkat\u00ebrrimi i bazave dhe nj\u00eb bot\u00eb e re e \u00e7uditshme\" src=\"\/wp-content\/uploads\/2019\/11\/0a64aa26d9b8216db56d389fa48578a5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Ilustrimi Daniel Steinberg<\/i><\/p>\n<p>S\u00eb dyti, enkriptimi tani realizohet jo si nj\u00eb nivel t\u00eb ve\u00e7ant\u00eb, por \u00ebsht\u00eb i inkorporuar n\u00eb protokoll. Kjo lejon t\u00eb krijojm\u00eb nj\u00eb lidhje dhe t\u00eb shk\u00ebmbejm\u00eb \u00e7el\u00ebsat publik\u00eb me nj\u00eb dor\u00ebheqje, dhe gjithashtu lejon p\u00ebrdorimin e mekanizmit t\u00eb men\u00e7ur 0-RTT handshake dhe t\u00eb shmangim vonesat gjat\u00eb dor\u00ebzimit. P\u00ebr m\u00eb tep\u00ebr, tani mund t\u00eb enkriptojm\u00eb paketa t\u00eb ve\u00e7anta t\u00eb dh\u00ebnash. Kjo lejon q\u00eb t\u00eb mos presim p\u00ebrfundimin e pranimit t\u00eb t\u00eb dh\u00ebnave nga stream-i, por t\u00eb deshifrojm\u00eb paketat e marra n\u00eb m\u00ebnyr\u00eb t\u00eb pavarur. Ky mod p\u00ebr pun\u00eb ishte krejt\u00ebsisht i pamundur n\u00eb TCP, sepse TLS dhe TCP punonin pavar\u00ebsisht nj\u00ebri-tjetrit, dhe TLS nuk mund t\u00eb dinte se n\u00eb cilat copa do t\u00eb cop\u00ebtoheshin t\u00eb dh\u00ebnat nga TCP. Prandaj, nuk mund t\u00eb p\u00ebrgatitetin segmentet e tyre q\u00eb t\u00eb p\u00ebrputhen segmentet TCP nj\u00eb t\u00eb nj\u00ebjt\u00eb dhe t\u00eb mund t\u00eb deshifroheshin n\u00eb m\u00ebnyr\u00eb t\u00eb pavarur. T\u00eb gjitha k\u00ebto p\u00ebrmir\u00ebsime lejojn\u00eb QUIC t\u00eb zvog\u00ebloj\u00eb latency-n n\u00eb krahasim me TCP.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: shkat\u00ebrrimi i bazave dhe nj\u00eb bot\u00eb e re e \u00e7uditshme\" src=\"\/wp-content\/uploads\/2019\/11\/cb3c522636f7a052a0f5988fe7ea3a65.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nS\u00eb treti, koncepti i stream-eve t\u00eb lehta lejon q\u00eb t\u00eb \u00e7lirohet lidhja nga adresa IP e klientit. Kjo \u00ebsht\u00eb e r\u00ebnd\u00ebsishme, p\u00ebr shembull, kur klienti kalon nga nj\u00eb pik\u00eb aksesi Wi-Fi n\u00eb nj\u00eb tjet\u00ebr, duke ndryshuar adres\u00ebn e tij IP. N\u00eb k\u00ebt\u00eb rast, p\u00ebrdorimi i TCP p\u00ebrfshin nj\u00eb proces t\u00eb gjat\u00eb, gjat\u00eb t\u00eb cilit lidhjet ekzistuese TCP ndalen p\u00ebr shkak t\u00eb koh\u00ebs s\u00eb pritjes dhe krijohen lidhje t\u00eb reja nga adresa IP e re. N\u00eb rastin e QUIC, klienti thjesht vazhdon t\u00eb d\u00ebrgoj\u00eb paketa n\u00eb server nga adresa IP e re me ID-n\u00eb e vjet\u00ebr t\u00eb stream-it. Duke qen\u00eb se ID i stream-it tani \u00ebsht\u00eb unik dhe nuk rip\u00ebrdoret, serveri kupton se klienti ka nd\u00ebrruar IP-n\u00eb, d\u00ebrgon paketat e humbura dhe vazhdon komunikimin n\u00eb adres\u00ebn e re.<\/p>\n<p>S\u00eb kat\u00ebrtash, QUIC implementohet n\u00eb nivelin e aplikacionit, jo n\u00eb nivelin e sistemit operativ. Kjo, nga nj\u00ebra an\u00eb, lejon q\u00eb ndryshimet n\u00eb protokoll t\u00eb b\u00ebhen m\u00eb shpejt, sepse p\u00ebr t\u00eb marr\u00eb nj\u00eb p\u00ebrdit\u00ebsim mjafton t\u00eb p\u00ebrdit\u00ebsosh bibliotek\u00ebn, n\u00eb vend q\u00eb t\u00eb pres\u00ebsh nj\u00eb version t\u00eb ri t\u00eb OS-s\u00eb. Nga ana tjet\u00ebr, kjo \u00e7on n\u00eb rritjen e konsiderueshme t\u00eb konsumit t\u00eb procesorit.<\/p>\n<p>Dhe p\u00ebr t\u00eb p\u00ebrfunduar, titujt. Kompresimi i titujve \u00ebsht\u00eb nj\u00eb nga aspektet q\u00eb dallojn\u00eb n\u00eb QUIC dhe gQUIC. Nuk e shoh t\u00eb arsyeshme t\u00eb kaloj shum\u00eb koh\u00eb mbi k\u00ebt\u00eb, do t\u00eb them vet\u00ebm se n\u00eb versionin e dor\u00ebzuar p\u00ebr standardizim, kompresimi i titujve \u00ebsht\u00eb b\u00ebr\u00eb sa m\u00eb i ngjash\u00ebm me kompresimin e titujve n\u00eb HTTP\/2. M\u00eb shum\u00eb mund t\u00eb lexoni <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">k\u00ebtu<\/a><\/noindex>.<\/p>\n<h4>Sa m\u00eb shpejt \u00ebsht\u00eb?<\/h4>\n<p>\nKjo \u00ebsht\u00eb nj\u00eb pyetje komplekse. E v\u00ebrteta \u00ebsht\u00eb se tani nuk kemi nj\u00eb standard, ndaj nuk kemi shum\u00eb p\u00ebr t\u00eb matur. Ndoshta, t\u00eb dh\u00ebnat e vetme statistikore q\u00eb kemi jan\u00eb statistikat e Google, i cili ka p\u00ebrdorur gQUIC q\u00eb nga viti 2013 dhe n\u00eb vitin 2016 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.ietf.org\/proceedings\/96\/slides\/slides-96-quic-3.pdf\">raportoi p\u00ebr IETF<\/a><\/noindex>, se rreth 90% e trafikut q\u00eb i shkon server\u00ebve t\u00eb tyre nga shfletuesi Chrome tani p\u00ebrdor QUIC. N\u00eb k\u00ebt\u00eb prezantim ata njoftojn\u00eb se p\u00ebrmes gQUIC, faqet ngarkohen rreth 5% m\u00eb shpejt, dhe n\u00eb video streaming ka 30% m\u00eb pak nd\u00ebrprerje krahasuar me TCP. <\/p>\n<p>N\u00eb vitin 2017, nj\u00eb grup hulumtuesish i udh\u00ebhequr nga Arash Molavi Kakhki publikoi <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">nj\u00eb pun\u00eb t\u00eb madhe<\/a><\/noindex> nj\u00eb studim mbi performanc\u00ebn e gQUIC krahasuar me TCP. <br \/>\nStudimi zbuloi disa dob\u00ebsi t\u00eb gQUIC, si paaft\u00ebsia p\u00ebr t\u00eb q\u00ebndruar e q\u00ebndrueshme ndaj shk\u00ebmbimit t\u00eb paketave rrjetit, ngopjen (pap\u00ebrshtatshm\u00ebrin\u00eb) ndaj kapacitetit t\u00eb kanalit dhe d\u00ebrgimin m\u00eb t\u00eb ngadalt\u00eb t\u00eb objekteve t\u00eb vogla (deri n\u00eb 10 kB). Sidoqoft\u00eb, kjo e fundit mund t\u00eb kompensohet duke p\u00ebrdorur 0-RTT. N\u00eb t\u00eb gjitha rastet e tjera t\u00eb shqyrtuara, gQUIC tregoi nj\u00eb rritje t\u00eb shpejt\u00ebsis\u00eb krahasuar me TCP. P\u00ebr shifrat konkrete \u00ebsht\u00eb e v\u00ebshtir\u00eb t\u00eb flitet. M\u00eb s\u00eb miri \u00ebsht\u00eb t\u00eb lexoni <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">studimin e vet\u00eb<\/a><\/noindex> ose <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.apnic.net\/2018\/01\/29\/measuring-quic-vs-tcp-mobile-desktop\/\">nj\u00eb post t\u00eb shkurt\u00ebr<\/a><\/noindex>.<\/p>\n<p>K\u00ebtu duhet th\u00ebn\u00eb se k\u00ebto t\u00eb dh\u00ebna jan\u00eb p\u00ebr gQUIC, dhe ato nuk jan\u00eb t\u00eb azhurnuara p\u00ebr standardin n\u00eb zhvillim. Ajo q\u00eb do t\u00eb ndodh\u00eb p\u00ebr QUIC: p\u00ebr momentin \u00ebsht\u00eb nj\u00eb mister i ruajtur mir\u00eb, por ka shpres\u00eb se dob\u00ebsit\u00eb e identifikuara te gQUIC do t\u00eb merren parasysh dhe do t\u00eb korrigjohen.<\/p>\n<h2>Pak p\u00ebr t\u00eb ardhmen: \u00e7far\u00eb po ndodh me HTTP\/3?<\/h2>\n<p>\nK\u00ebtu gjith\u00e7ka \u00ebsht\u00eb kristalisht e qart\u00eb: API nuk do t\u00eb ndryshoj\u00eb. Gjith\u00e7ka do t\u00eb mbetet ashtu si\u00e7 ishte n\u00eb HTTP\/2. N\u00ebse API mbetet i nj\u00ebjt\u00eb, kalimi n\u00eb HTTP\/3 duhet t\u00eb zgjidhet duke p\u00ebrdorur nj\u00eb version t\u00eb ri t\u00eb bibliotek\u00ebs s\u00eb pasm\u00eb, q\u00eb mb\u00ebshtet transportin n\u00ebp\u00ebrmjet QUIC. Megjithat\u00eb, ende do t\u00eb duhet t\u00eb mbajm\u00eb nj\u00eb fallback n\u00eb versionet e vjetra t\u00eb HTTP, sepse interneti aktualisht nuk \u00ebsht\u00eb i gatsh\u00ebm p\u00ebr nj\u00eb kalim t\u00eb plot\u00eb n\u00eb UDP.<\/p>\n<h4>Kush e mb\u00ebshtet tashm\u00eb<\/h4>\n<p>\nK\u00ebtu \u00ebsht\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/quicwg\/base-drafts\/wiki\/Implementations\">e atributeve<\/a><\/noindex> implementimin ekzistues t\u00eb QUIC. Pavar\u00ebsisht munges\u00ebs s\u00eb standardit, lista \u00ebsht\u00eb e mir\u00eb. <\/p>\n<p>Asnj\u00eb shfletues aktualisht nuk mb\u00ebshtet QUIC n\u00eb versionin e prodhimit. S\u00eb fundmi, kishte informacione q\u00eb n\u00eb Chrome u aktivizua mb\u00ebshtetje p\u00ebr HTTP\/3, por p\u00ebr momentin vet\u00ebm n\u00eb Canary. <\/p>\n<p>Nga backend-et, vet\u00ebm <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/caddyserver\/caddy\">Caddy<\/a><\/noindex> dhe <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/http3-the-past-present-and-future\/\">Cloudflare<\/a><\/noindex>, por p\u00ebr momentin eksperimentalisht. NGINX n\u00eb fund t\u00eb pranver\u00ebs 2019 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.nginx.com\/blog\/nginx-1-16-1-17-released\/\">konfirmuan<\/a><\/noindex>, q\u00eb filluan pun\u00ebn p\u00ebr mb\u00ebshtetje t\u00eb HTTP\/3, por ende nuk e kan\u00eb p\u00ebrfunduar.<\/p>\n<h4>Cilat jan\u00eb problemet<\/h4>\n<p>\nNe jetojm\u00eb n\u00eb nj\u00eb bot\u00eb reale, ku asnj\u00eb teknologji e madhe nuk mund t\u00eb kaloj\u00eb n\u00eb mas\u00eb pa u p\u00ebrballur me rezistenc\u00eb, dhe QUIC nuk \u00ebsht\u00eb p\u00ebrjashtim.<\/p>\n<p>M\u00eb e r\u00ebnd\u00ebsishmja, duhet n\u00eb nj\u00eb m\u00ebnyr\u00eb t\u00eb qart\u00eb q\u00eb t'i shpjegojm\u00eb shfletuesit se \u201chttps:\/\/\u201d tani nuk \u00ebsht\u00eb fakt q\u00eb \u00e7on n\u00eb portin 443 t\u00eb TCP. Atje mund t\u00eb mos ket\u00eb fare TCP. P\u00ebr k\u00ebt\u00eb p\u00ebrdoret titulli Alt-Svc. Ai lejon t\u00eb informohet shfletuesi se ky website \u00ebsht\u00eb gjithashtu i aksesuesh\u00ebm n\u00eb nj\u00eb protokoll t\u00eb caktuar n\u00eb nj\u00eb adres\u00eb t\u00eb caktuar. N\u00eb teorin\u00eb, kjo duhet t\u00eb funksionoj\u00eb si ore, por n\u00eb praktik\u00eb ndeshemi me faktin se UDP mund t\u00eb jet\u00eb, p\u00ebr shembull, i ndaluar n\u00eb firewall p\u00ebr t\u00eb parandaluar sulmet DDoS.<\/p>\n<p>Por edhe n\u00ebse UDP nuk \u00ebsht\u00eb i ndaluar, klienti mund t\u00eb jet\u00eb pas nj\u00eb router NAT, i cili \u00ebsht\u00eb i konfiguruar p\u00ebr t\u00eb mbajtur sesionet TCP p\u00ebrmes adres\u00ebs IP, dhe pasi p\u00ebrdorim UDP q\u00eb nuk ka nj\u00eb seanc\u00eb fizike, NAT nuk do t\u00eb mbaj\u00eb lidhjen dhe seanca e QUIC <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">do t\u00eb nd\u00ebrpritet vazhdimisht<\/a><\/noindex>. <\/p>\n<p>T\u00eb gjitha k\u00ebto probleme lidhen me faktin se UDP m\u00eb par\u00eb nuk ishte p\u00ebrdorur p\u00ebr transmetimin e p\u00ebrmbajtjes s\u00eb internetit dhe prodhuesit e pajisjeve nuk mund t\u00eb parashikonin q\u00eb di\u00e7ka e till\u00eb do t\u00eb ndodhte nj\u00eb dit\u00eb. Po ashtu, administrator\u00ebt ende nuk e kuptojn\u00eb mir\u00eb se si t\u00eb konfigurojn\u00eb rrjetet e tyre p\u00ebr t\u00eb punuar me QUIC. Kjo situat\u00eb do t\u00eb ndryshoj\u00eb ngadal\u00eb, dhe n\u00eb \u00e7do rast, nj\u00eb ndryshim i till\u00eb do t\u00eb marr\u00eb m\u00eb pak koh\u00eb sesa p\u00ebr t\u00eb futur nj\u00eb protokoll t\u00eb ri n\u00eb nivelin e transportit. <\/p>\n<p>P\u00ebr m\u00eb tep\u00ebr, si\u00e7 \u00ebsht\u00eb p\u00ebrshkruar m\u00eb par\u00eb, QUIC rrit ndjesh\u00ebm p\u00ebrdorimin e procesor\u00ebve. Daniel Stenberg <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=idViw4anA6E\">vler\u00ebsoi<\/a><\/noindex> rritjen e procesor\u00ebve deri n\u00eb tre her\u00eb.<\/p>\n<h4>Kur do t\u00eb ndodh\u00eb HTTP\/3<\/h4>\n<p>\nStandardi <noindex><a rel=\"nofollow\" href=\"https:\/\/datatracker.ietf.org\/wg\/quic\/about\/\">kan\u00eb p\u00ebr q\u00ebllim ta miratojn\u00eb<\/a><\/noindex> deri n\u00eb maj 2020, por duke marr\u00eb parasysh se aktualisht dokumentet mbeten t\u00eb pap\u00ebrfunduara, t\u00eb planifikuara p\u00ebr korrik 2019, mund t\u00eb themi se data p\u00ebrfundimisht do t\u00eb shtyhet.<\/p>\n<p>Por m\u00eb shum\u00eb se 10 vjet, Google ka p\u00ebrdorur implementimin e tij t\u00eb gQUIC q\u00eb nga viti 2013. N\u00ebse hedhim nj\u00eb Blick n\u00eb k\u00ebrkes\u00ebn HTTP q\u00eb i d\u00ebrgohet motorit t\u00eb k\u00ebrkimit t\u00eb Google, mund ta shohim k\u00ebt\u00eb:<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: shkat\u00ebrrimi i bazave dhe nj\u00eb bot\u00eb e re e \u00e7uditshme\" src=\"\/wp-content\/uploads\/2019\/11\/af422268eb85b488c7be1b70c6d33fad.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>P\u00ebrfundimet<\/h2>\n<p>\nQUIC aktualisht duket si nj\u00eb teknologji e papjekur, por shum\u00eb premtuese. Duke marr\u00eb parasysh se p\u00ebr 20 vitet e fundit, t\u00eb gjitha optimizimet e protokolleve t\u00eb nivelit t\u00eb transportit kan\u00eb qen\u00eb kryesisht p\u00ebr TCP, QUIC, i cili n\u00eb shum\u00eb raste fiton n\u00eb performanc\u00eb, duket tashm\u00eb mjaft mir\u00eb. <\/p>\n<p>Megjithat\u00eb, ende ekzistojn\u00eb probleme t\u00eb pazgjidhura me t\u00eb cilat do t\u00eb duhet t\u00eb merremi n\u00eb vitet n\u00eb vijim. Procesi mund t\u00eb zgjatet p\u00ebr shkak t\u00eb pajisjeve, t\u00eb cilat askush nuk i p\u00eblqen t'i p\u00ebrdit\u00ebsoj\u00eb, por megjithat\u00eb t\u00eb gjitha problemet duken mjaft t\u00eb zgjidhshme, dhe sooner apo later t\u00eb gjith\u00eb ne do t\u00eb kemi HTTP\/3. <\/p>\n<p>E ardhmja \u00ebsht\u00eb af\u00ebr!<br \/>\n<br \/>Burimi: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dodopizzaio\/blog\/473930\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u043e\u0442 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 20 \u043b\u0435\u0442 \u043c\u044b \u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0432\u0435\u0431-\u0441\u0442\u0440\u0430\u043d\u0438\u0447\u043a\u0438 \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 HTTP. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0435 \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u0438 \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442. \u0414\u0440\u0443\u0433\u0438\u0435 \u0437\u043d\u0430\u044e\u0442, \u0447\u0442\u043e \u0433\u0434\u0435-\u0442\u043e \u043f\u043e\u0434 HTTP \u0435\u0441\u0442\u044c TLS, \u0430 \u043f\u043e\u0434 \u043d\u0438\u043c TCP, \u043f\u043e\u0434 \u043a\u043e\u0442\u043e\u0440\u044b\u043c IP \u0438 \u0442\u0430\u043a \u0434\u0430\u043b\u0435\u0435. \u0410 \u0442\u0440\u0435\u0442\u044c\u0438 \u2013 \u0435\u0440\u0435\u0442\u0438\u043a\u0438 \u2013 \u0441\u0447\u0438\u0442\u0430\u044e\u0442, \u0447\u0442\u043e TCP \u2013 \u044d\u0442\u043e \u043f\u0440\u043e\u0448\u043b\u044b\u0439 \u0432\u0435\u043a, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-52181","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.0.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u043e\u0442 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 20 \u043b\u0435\u0442 \u043c\u044b \u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0432\u0435\u0431-\u0441\u0442\u0440\u0430\u043d\u0438\u0447\u043a\u0438 \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 HTTP. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0435 \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u0438 \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"sq_AL\" \/>\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\/sq\/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: shkat\u00ebrrimi i themeleve dhe nj\u00eb bot\u00eb e re e mrekullueshme | ProHoster","description":"Tani ka m\u00eb shum\u00eb se 20 vjet ne shikojm\u00eb faqe t\u00eb internetit p\u00ebrmes protokollit HTTP. Shumica e p\u00ebrdoruesve n\u00eb t\u00eb v\u00ebrtet\u00eb nuk e mendojn\u00eb se \u00e7far\u00eb \u00ebsht\u00eb dhe si funksionon.","canonical_url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sq_AL","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\/sq\/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\/sq\/wp-json\/wp\/v2\/posts\/52181","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/comments?post=52181"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/52181\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media?parent=52181"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/categories?post=52181"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/tags?post=52181"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}