{"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\/sv\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","title":{"rendered":"HTTP\/3: F\u00f6rst\u00f6relsen av grunderna och en underbar ny v\u00e4rld","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>I \u00f6ver 20 \u00e5r har vi tittat p\u00e5 webbsidor via protokollet HTTP. De flesta anv\u00e4ndare t\u00e4nker \u00f6verhuvudtaget inte p\u00e5 vad det \u00e4r och hur det fungerar. Andra vet att TLS ligger n\u00e5gonstans under HTTP, och under det TCP, under vilket ligger IP och s\u00e5 vidare. Och de tredje \u2013 heretikerna \u2013 anser att TCP \u00e4r f\u00f6r\u00e5ldrat, de vill ha n\u00e5got snabbare, mer p\u00e5litligt och s\u00e4krare. Men i sina f\u00f6rs\u00f6k att uppfinna ett nytt perfekt protokoll har de \u00e5terg\u00e5tt till teknologier fr\u00e5n 80-talet och f\u00f6rs\u00f6ker bygga sin underbara nya v\u00e4rld p\u00e5 dem.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: F\u00f6rst\u00f6relsen av grunderna och en underbar ny v\u00e4rld\" 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>Lite historia: HTTP\/1.1<\/h2>\n<p>\n\u00c5r 1997 fick protokollet f\u00f6r \u00f6verf\u00f6ring av textinformation HTTP version 1.1 sitt RFC. Vid den tidpunkten hade protokollet anv\u00e4nts av webbl\u00e4sare i flera \u00e5r, och den nya standarden h\u00f6ll i ytterligare femton. Protokollet fungerade enbart enligt principen f\u00f6r beg\u00e4ran-svar och var huvudsakligen avsett f\u00f6r \u00f6verf\u00f6ring av textinformation.<\/p>\n<p>HTTP designades f\u00f6r att fungera ovanp\u00e5 protokollet TCP, som garanterar p\u00e5litlig leverans av paket till mottagaren. TCP:s funktion bygger p\u00e5 att etablera och uppr\u00e4tth\u00e5lla en p\u00e5litlig anslutning mellan slutpunkter och dela upp trafik i segment. Segmenten har ett sekventiellt nummer och en kontrollsumma. Om n\u00e5got av segmenten inte kommer fram eller kommer med en felaktig kontrollsumma, stoppas \u00f6verf\u00f6ringen tills det f\u00f6rlorade segmentet har \u00e5terst\u00e4llts.<\/p>\n<p>I HTTP\/1.0 st\u00e4ngdes TCP-anslutningen efter varje beg\u00e4ran. Det var oerh\u00f6rt sl\u00f6saktigt, eftersom etableringen av en TCP-anslutning (3-v\u00e4gs handskakning) \u00e4r en l\u00e5ngsam process. I HTTP\/1.1 introducerades mekanismen keep-alive, som g\u00f6r det m\u00f6jligt att \u00e5teranv\u00e4nda en och samma anslutning f\u00f6r flera beg\u00e4rningar. Men eftersom det kan bli en flaskhals, till\u00e5ts i olika implementationer av HTTP\/1.1 att \u00f6ppna flera TCP-anslutningar till samma v\u00e4rd. Till exempel till\u00e5ter Chrome och de senaste versionerna av Firefox upp till sex anslutningar.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: F\u00f6rst\u00f6relsen av grunderna och en underbar ny v\u00e4rld\" src=\"\/wp-content\/uploads\/2019\/11\/b1c131da8e62ace741f3064f2fb96c60.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nKryptering skulle ocks\u00e5 \u00f6verl\u00e5tas till andra protokoll, och f\u00f6r det b\u00f6rjade protokollet TLS att anv\u00e4ndas \u00f6ver TCP, vilket skyddade data p\u00e5 ett tillfredsst\u00e4llande s\u00e4tt, men som ytterligare \u00f6kade den tid som beh\u00f6vdes f\u00f6r att etablera en anslutning. I slut\u00e4ndan blev processen f\u00f6r handskakning s\u00e5 h\u00e4r:<br \/>\n <img decoding=\"async\" alt=\"HTTP\/3: F\u00f6rst\u00f6relsen av grunderna och en underbar ny v\u00e4rld\" src=\"\/wp-content\/uploads\/2019\/11\/2fdccf56e0ed29444557836fdc65351b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Cloudflare-illustration<\/i><\/p>\n<p>S\u00e5ledes hade HTTP\/1.1 flera problem:<\/p>\n<ul>\n<li>L\u00e5ngsam anslutningstid.<\/li>\n<li>Data skickas i textformat, vilket inneb\u00e4r att \u00f6verf\u00f6ring av bilder, videor och annan icke-textlig information \u00e4r ineffektiv.<\/li>\n<li>En TCP-anslutning anv\u00e4nds f\u00f6r en f\u00f6rfr\u00e5gan, vilket betyder att andra f\u00f6rfr\u00e5gningar antingen m\u00e5ste hitta en annan anslutning eller v\u00e4nta tills den aktuella f\u00f6rfr\u00e5gan sl\u00e4pper den.<\/li>\n<li>Endast pull-modellen st\u00f6ds. Standarden inneh\u00e5ller inget om server-push.<\/li>\n<li>Rubriker \u00f6verf\u00f6rs som text.<\/li>\n<\/ul>\n<p>\nOm server-push n\u00e5gonlunde implementeras med hj\u00e4lp av WebSocket-protokollet, m\u00e5ste \u00f6vriga problem l\u00f6sas mer radikalt.<\/p>\n<h2>Lite modernitet: HTTP\/2<\/h2>\n<p>\n\u00c5r 2012 inleddes arbetet med protokollet SPDY (uttalas \"spidi\") inuti Google. Protokollet syftade till att l\u00f6sa de st\u00f6rsta problemen med HTTP\/1.1 och skulle samtidigt bevara bak\u00e5tkompatibiliteten. \u00c5r 2015 presenterade IETFs arbetsgrupp specifikationen HTTP\/2, baserad p\u00e5 protokollet SPDY. H\u00e4r \u00e4r vilka skillnader som fanns i HTTP\/2:<\/p>\n<ul>\n<li>Bin\u00e4r serialisering.<\/li>\n<li>Multiplexering av flera HTTP-f\u00f6rfr\u00e5gningar i en enda TCP-anslutning.<\/li>\n<li>Server-push out-of-the-box (utan WebSocket).<\/li>\n<\/ul>\n<p>\nProtokollet var ett stort framsteg. Det \u00e4r avsev\u00e4rt <noindex><a rel=\"nofollow\" href=\"https:\/\/http2.akamai.com\/demo\">snabbare \u00e4n f\u00f6rsta versionen<\/a><\/noindex> och kr\u00e4ver inga flera TCP-anslutningar: alla f\u00f6rfr\u00e5gningar till en v\u00e4rd multiplexeras i en. Det vill s\u00e4ga, i en anslutning finns flera s\u00e5 kallade str\u00f6mmar, var och en med sitt ID. Som bonus ing\u00e5r server-push.<\/p>\n<p>Men multiplexering medf\u00f6r ett annat centralt problem. T\u00e4nk dig att vi asynkront g\u00f6r 5 f\u00f6rfr\u00e5gningar till en server. Med HTTP\/2 kommer alla dessa f\u00f6rfr\u00e5gningar att utf\u00f6ras inom ramen f\u00f6r en enda TCP-anslutning, vilket betyder att om en av segmenten av n\u00e5gon f\u00f6rfr\u00e5gan g\u00e5r f\u00f6rlorad eller kommer fel, kommer \u00f6verf\u00f6ringen av alla f\u00f6rfr\u00e5gningar och svar att stoppas tills det f\u00f6rlorade segmentet \u00e5terskapas. Det \u00e4r uppenbart att ju s\u00e4mre anslutningskvaliteten \u00e4r, desto l\u00e5ngsammare fungerar HTTP\/2. <noindex><a rel=\"nofollow\" href=\"https:\/\/http3-explained.haxx.se\/en\/why-tcphol.html\">Enligt Daniel Steinbergs uppskattning<\/a><\/noindex>, under f\u00f6rh\u00e5llanden d\u00e4r f\u00f6rlorade paket utg\u00f6r 2 % av alla, presterar HTTP\/1.1 b\u00e4ttre i webbl\u00e4saren \u00e4n HTTP\/2 eftersom det \u00f6ppnar 6 anslutningar ist\u00e4llet f\u00f6r en.<\/p>\n<p>Detta problem kallas \"head-of-line blocking\" och tyv\u00e4rr \u00e4r det inte m\u00f6jligt att l\u00f6sa detta med hj\u00e4lp av TCP.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: F\u00f6rst\u00f6relsen av grunderna och en underbar ny v\u00e4rld\" src=\"\/wp-content\/uploads\/2019\/11\/234a6dc218a9acf8d2212fbdf28f2188.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Illustration av Daniel Steinberg<\/i><\/p>\n<p>Som ett resultat har utvecklarna av HTTP\/2-standarden gjort ett enormt arbete och genomf\u00f6rt praktiskt taget allt som kunde g\u00f6ras p\u00e5 applikationsniv\u00e5n inom OSI-modellen. Det \u00e4r nu dags att g\u00e5 ned till transportniv\u00e5n och uppfinna ett nytt transportprotokoll.<\/p>\n<h2>Vi beh\u00f6ver ett nytt protokoll: UDP vs TCP<\/h2>\n<p>\nDet blev ganska snabbt uppenbart att inf\u00f6ra ett helt nytt transportprotokoll \u00e4r en uppgift som \u00e4r om\u00f6jlig i dagens verklighet. Problemet \u00e4r att transportniv\u00e5n \u00e4r k\u00e4nd av h\u00e5rdvaror eller mellanled (routrar, brandv\u00e4ggar, NAT-servrar...), och att l\u00e4ra dem n\u00e5got nytt \u00e4r en ytterst sv\u00e5r uppgift. Dessutom \u00e4r st\u00f6det f\u00f6r transportprotokoll inb\u00e4ddat i k\u00e4rnan av operativsystem, och k\u00e4rnor f\u00f6r\u00e4ndras inte direkt s\u00e4rskilt villigt.<\/p>\n<p>Vid det h\u00e4r laget skulle man kunna ge upp och s\u00e4ga \"Sj\u00e4lvklart kommer vi att uppfinna en ny HTTP\/3 med preferenser och kurtisaner, men det kommer att ta 10\u201315 \u00e5r innan den verkligen implementeras (ungef\u00e4r s\u00e5 l\u00e5ng tid tar det att byta ut de flesta av h\u00e5rdvarorna)\", men det finns en annan, kanske inte s\u00e5 uppenbar, m\u00f6jlighet: att anv\u00e4nda UDP-protokollet. Ja, just det protokollet som vi anv\u00e4nde f\u00f6r att skicka filer lokalt i slutet av 90-talet och b\u00f6rjan av 00-talet. N\u00e4stan all nuvarande h\u00e5rdvara klarar det.<\/p>\n<p>Vad \u00e4r f\u00f6rdelarna med UDP j\u00e4mf\u00f6rt med TCP? F\u00f6r det f\u00f6rsta, vi har ingen session p\u00e5 transportniv\u00e5n som h\u00e5rdvaran k\u00e4nner till. Detta g\u00f6r att vi sj\u00e4lva kan definiera sessionen p\u00e5 slutpunkterna och hantera eventuella konflikter d\u00e4r. Det betyder att vi inte \u00e4r begr\u00e4nsade till en eller flera sessioner (som med TCP), utan kan skapa s\u00e5 m\u00e5nga vi beh\u00f6ver. F\u00f6r det andra sker data\u00f6verf\u00f6ringen via UDP snabbare \u00e4n via TCP. P\u00e5 s\u00e5 s\u00e4tt kan vi teoretiskt \u00f6vervinna dagens hastighetsgr\u00e4ns, som n\u00e5ddes i HTTP\/2. <\/p>\n<p>Men UDP garanterar inte p\u00e5litlighet i data\u00f6verf\u00f6ringen. Faktum \u00e4r att vi bara skickar paket och hoppas att de tas emot i andra \u00e4nden. Fick vi inte dem? Ja, trist... Detta var tillr\u00e4ckligt f\u00f6r att \u00f6verf\u00f6ra videor f\u00f6r vuxna, men f\u00f6r mer seri\u00f6sa saker beh\u00f6vs p\u00e5litlighet, vilket inneb\u00e4r att vi m\u00e5ste bygga n\u00e5got annat ovanp\u00e5 UDP.<\/p>\n<p>Precis som i fallet med HTTP\/2 b\u00f6rjade arbetet med att skapa ett nytt protokoll p\u00e5 Google \u00e5r 2012, vilket var ungef\u00e4r samtidigt som arbetet med SPDY inleddes. \u00c5r 2013 presenterade Jim Roskind protokollet f\u00f6r allm\u00e4nheten. <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.google.com\/document\/d\/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34\/edit\">protokollet QUIC (Quick UDP Internet Connections)<\/a><\/noindex>, och redan 2015 inf\u00f6rdes ett Internet Draft f\u00f6r standardisering inom IETF. Vid den tidpunkten skilde sig protokollet som utvecklades av Roskind p\u00e5 Google kraftigt fr\u00e5n det som lades fram f\u00f6r standardisering, d\u00e4rf\u00f6r b\u00f6rjade man kalla Googles version f\u00f6r gQUIC.<\/p>\n<h4>Vad \u00e4r QUIC<\/h4>\n<p>\nF\u00f6r det f\u00f6rsta, som redan n\u00e4mnts, \u00e4r detta en omslag \u00f6ver UDP. Ovanp\u00e5 UDP byggs en QUIC-anslutning, d\u00e4r flera str\u00f6mmar kan existera p\u00e5 samma s\u00e4tt som med HTTP\/2. Dessa str\u00f6mmar finns endast p\u00e5 \u00e4ndpunkterna och hanteras oberoende. Om ett paket g\u00e5r f\u00f6rlorat i en str\u00f6m p\u00e5verkar det inte de andra.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: F\u00f6rst\u00f6relsen av grunderna och en underbar ny v\u00e4rld\" src=\"\/wp-content\/uploads\/2019\/11\/0a64aa26d9b8216db56d389fa48578a5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Illustration av Daniel Steinberg<\/i><\/p>\n<p>F\u00f6r det andra \u00e4r kryptering nu inte enskild niv\u00e5, utan inkluderad i protokollet. Detta m\u00f6jligg\u00f6r att uppr\u00e4tta en anslutning och utbyta publika nycklar i ett enda handslag, samt att anv\u00e4nda den smarta mekanismen 0-RTT handslag f\u00f6r att helt undvika f\u00f6rdr\u00f6jningar vid handskakningar. Dessutom kan man nu kryptera enskilda datapaket. Detta m\u00f6jligg\u00f6r att inte beh\u00f6va v\u00e4nta p\u00e5 att datamottagningen fr\u00e5n str\u00f6mmen ska avslutas, utan att avkoda de mottagna paketen oberoende. Denna arbetsmetod var \u00f6verhuvudtaget inte m\u00f6jlig i TCP, eftersom TLS och TCP arbetade oberoende av varandra, och TLS kunde inte veta hur TCP skulle dela upp datan. D\u00e4rmed kunde den inte f\u00f6rbereda sina segment s\u00e5 att de passade in i TCP-segment ett till ett och kunde avkodas oberoende. Alla dessa f\u00f6rb\u00e4ttringar g\u00f6r att QUIC kan minska latensen j\u00e4mf\u00f6rt med TCP.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: F\u00f6rst\u00f6relsen av grunderna och en underbar ny v\u00e4rld\" src=\"\/wp-content\/uploads\/2019\/11\/cb3c522636f7a052a0f5988fe7ea3a65.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nF\u00f6r det tredje m\u00f6jligg\u00f6r konceptet med l\u00e4tta str\u00f6mmar att koppla bort anslutningen fr\u00e5n klientens IP-adress. Detta \u00e4r viktigt, exempelvis n\u00e4r en klient v\u00e4xlar mellan olika Wi-Fi-\u00e5tkomstpunkter och \u00e4ndrar sin IP. I s\u00e5dana fall, n\u00e4r TCP anv\u00e4nds, sker en l\u00e5ng process d\u00e4r befintliga TCP-anslutningar kopplas bort p\u00e5 grund av timeout och nya anslutningar skapas med den nya IP:n. Vid QUIC, forts\u00e4tter klienten bara att skicka paket till servern med den nya IP:n och den gamla str\u00f6ms ID. Eftersom str\u00f6m-ID nu \u00e4r unikt och inte \u00e5teranv\u00e4nds, f\u00f6rst\u00e5r servern att klienten har bytt IP, skickar de f\u00f6rlorade paketen och forts\u00e4tter kommunikationen p\u00e5 den nya adressen.<\/p>\n<p>F\u00f6r det fj\u00e4rde implementeras QUIC p\u00e5 applikationsniv\u00e5 snarare \u00e4n operativsystemsniv\u00e5. \u00c5 ena sidan m\u00f6jligg\u00f6r detta snabbare f\u00f6r\u00e4ndringar i protokollet, eftersom man bara beh\u00f6ver uppdatera biblioteket f\u00f6r att f\u00e5 en uppgradering, ist\u00e4llet f\u00f6r att v\u00e4nta p\u00e5 en ny version av operativsystemet. \u00c5 andra sidan leder detta till en kraftig \u00f6kning av processoranv\u00e4ndningen.<\/p>\n<p>Och slutligen, rubriker. Komprimering av rubriker h\u00f6r definivt till de saker som skiljer sig mellan QUIC och gQUIC. Jag ser ingen mening med att \u00e4gna mycket tid \u00e5t detta, jag kan bara s\u00e4ga att i versionen som presenterades f\u00f6r standardisering gjordes komprimeringen av rubriker s\u00e5 lik som m\u00f6jligt komprimeringen av rubriker i HTTP\/2. Mer information kan l\u00e4sas <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">h\u00e4r<\/a><\/noindex>.<\/p>\n<h4>Hur mycket snabbare \u00e4r det?<\/h4>\n<p>\nDet \u00e4r en komplex fr\u00e5ga. Faktum \u00e4r att vi \u00e4nnu inte har n\u00e5got standard, s\u00e5 vi har inte mycket att m\u00e4ta. De enda statistikuppgifter vi har \u00e4r fr\u00e5n Google, som har anv\u00e4nt gQUIC sedan 2013 och \u00e5r 2016 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.ietf.org\/proceedings\/96\/slides\/slides-96-quic-3.pdf\">redovisade f\u00f6r IETF<\/a><\/noindex>, att cirka 90% av trafiken som g\u00e5r till deras servrar fr\u00e5n webbl\u00e4saren Chrome nu anv\u00e4nder QUIC. I samma presentation rapporterar de att sidor laddas ungef\u00e4r 5% snabbare genom gQUIC, och att str\u00f6mmande video har 30% f\u00e4rre avbrott j\u00e4mf\u00f6rt med TCP. <\/p>\n<p>\u00c5r 2017 publicerade en grupp forskare ledd av Arash Molavi Kakhki <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">ett stort arbete<\/a><\/noindex> om att studera prestandan av gQUIC j\u00e4mf\u00f6rt med TCP. <br \/>\nStudien avsl\u00f6jade flera svagheter i gQUIC, s\u00e5som of\u00f6rm\u00e5ga att hantera blandade n\u00e4tverkspaket, girighet (or\u00e4ttvisa) mot bandbredd och l\u00e5ngsammare \u00f6verf\u00f6ring av sm\u00e5 (upp till 10 kB) objekt. Det senare kan dock kompenseras med anv\u00e4ndning av 0-RTT. I alla andra fall som studerades visade gQUIC en \u00f6kning i hastighet j\u00e4mf\u00f6rt med TCP. Det \u00e4r sv\u00e5rt att tala om specifika siffror h\u00e4r. Det \u00e4r b\u00e4ttre att l\u00e4sa <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">sj\u00e4lva studien<\/a><\/noindex> eller <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.apnic.net\/2018\/01\/29\/measuring-quic-vs-tcp-mobile-desktop\/\">ett kort inl\u00e4gg<\/a><\/noindex>.<\/p>\n<p>H\u00e4r b\u00f6r det n\u00e4mnas att dessa data handlar om gQUIC och att de inte \u00e4r aktuella f\u00f6r den utvecklade standarden. Vad som kommer att g\u00e4lla f\u00f6r QUIC \u00e4r fortfarande en hemlighet, men det finns hopp om att svagheterna som identifierades i gQUIC kommer att beaktas och \u00e5tg\u00e4rdas.<\/p>\n<h2>Lite framtidsperspektiv: vad h\u00e4nder med HTTP\/3?<\/h2>\n<p>\nH\u00e4r \u00e4r det kristallklart: API:t kommer inte att f\u00f6r\u00e4ndras. Allt f\u00f6rblir precis som det var i HTTP\/2. Om API:t f\u00f6rblir detsamma, b\u00f6r \u00f6verg\u00e5ngen till HTTP\/3 avg\u00f6ras genom att anv\u00e4nda den senaste versionen av biblioteken p\u00e5 backend, som st\u00f6der transport via QUIC. \u00c4ven om internet just nu inte \u00e4r redo f\u00f6r en fullst\u00e4ndig \u00f6verg\u00e5ng till UDP, m\u00e5ste vi tyv\u00e4rr forts\u00e4tta att h\u00e5lla fallback till \u00e4ldre versioner av HTTP.<\/p>\n<h4>Vem st\u00f6der redan<\/h4>\n<p>\nH\u00e4r \u00e4r <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/quicwg\/base-drafts\/wiki\/Implementations\">listan<\/a><\/noindex> existerande QUIC-implementationer. Trots avsaknaden av en standard, \u00e4r listan ganska bra. <\/p>\n<p>Ingen webbl\u00e4sare st\u00f6der f\u00f6r n\u00e4rvarande QUIC i produktionsversion. Nyligen kom det fram information om att Chrome aktiverade st\u00f6d f\u00f6r HTTP\/3, men bara i Canary. <\/p>\n<p>Av backend-l\u00f6sningarna st\u00f6der endast <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/caddyserver\/caddy\">Caddy<\/a><\/noindex> och <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/http3-the-past-present-and-future\/\">Cloudflare<\/a><\/noindex>, men fortfarande p\u00e5 experimentell niv\u00e5. NGINX meddelade i slutet av v\u00e5ren 2019 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.nginx.com\/blog\/nginx-1-16-1-17-released\/\">400 f\u00f6retag. Bland dessa finns b\u00e5de sm\u00e5 startups och stora IT-f\u00f6retag.<\/a><\/noindex>, att de hade b\u00f6rjat arbeta p\u00e5 st\u00f6d f\u00f6r HTTP\/3, men de har \u00e4nnu inte slutf\u00f6rt det.<\/p>\n<h4>Vilka problem finns det<\/h4>\n<p>\nVi lever i en verklig v\u00e4rld d\u00e4r ingen stor teknik kan n\u00e5 massorna utan att m\u00f6ta motst\u00e5nd, och QUIC \u00e4r inget undantag.<\/p>\n<p>Det viktigaste \u00e4r att p\u00e5 n\u00e5got s\u00e4tt f\u00f6rklara f\u00f6r webbl\u00e4saren att \"https:\/\/\" nu inte n\u00f6dv\u00e4ndigtvis leder till TCP-port 443. D\u00e4r kan faktiskt ingen TCP finnas. F\u00f6r detta anv\u00e4nds Alt-Svc-headern. Den l\u00e5ter informera webbl\u00e4saren om att denna webbplats ocks\u00e5 \u00e4r tillg\u00e4nglig p\u00e5 ett visst protokoll p\u00e5 en viss adress. I teorin borde detta fungera perfekt, men i praktiken kan vi st\u00f6ta p\u00e5 problem, d\u00e4r UDP kan vara blockerad av brandv\u00e4ggen f\u00f6r att f\u00f6rhindra DDoS-attacker.<\/p>\n<p>Men \u00e4ven om UDP inte \u00e4r blockerad kan klienten befinna sig bakom en NAT-router som \u00e4r inst\u00e4lld f\u00f6r att uppr\u00e4tth\u00e5lla TCP-sessioner baserat p\u00e5 IP-adressen, och eftersom vi anv\u00e4nder UDP, som inte har n\u00e5gon h\u00e5rdvarusession, kommer NAT inte att h\u00e5lla anslutningen, och QUIC-sessionen <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">kommer att brytas konstant<\/a><\/noindex>. <\/p>\n<p>Alla dessa problem beror p\u00e5 att UDP tidigare inte anv\u00e4ndes f\u00f6r att \u00f6verf\u00f6ra internetinneh\u00e5ll, och h\u00e5rdvarutillverkare kunde inte f\u00f6rutse att detta skulle ske n\u00e5gon g\u00e5ng. P\u00e5 samma s\u00e4tt f\u00f6rst\u00e5r administrat\u00f6rer fortfarande inte helt hur de ska konfigurera sina n\u00e4tverk f\u00f6r att st\u00f6dja QUIC. Denna situation kommer gradvis att f\u00f6r\u00e4ndras, och i vilket fall som helst kommer s\u00e5dana f\u00f6r\u00e4ndringar att ta mindre tid \u00e4n att implementera ett nytt transportprotokoll. <\/p>\n<p>Dessutom, som redan har beskrivits, \u00f6kar QUIC kraftigt anv\u00e4ndningen av CPU. Daniel Stenberg <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=idViw4anA6E\">bed\u00f6mde<\/a><\/noindex> \u00f6kningen av CPU-anv\u00e4ndning till tre g\u00e5nger.<\/p>\n<h4>N\u00e4r kommer HTTP\/3<\/h4>\n<p>\nStandard <noindex><a rel=\"nofollow\" href=\"https:\/\/datatracker.ietf.org\/wg\/quic\/about\/\">vill acceptera<\/a><\/noindex> I maj 2020, men med tanke p\u00e5 att dokumenten som var planerade till juli 2019 fortfarande inte \u00e4r klara, kan man s\u00e4ga att datumet troligen skjuts upp.<\/p>\n<p>Google har anv\u00e4nt sin implementation av gQUIC sedan 2013. Om man tittar p\u00e5 HTTP-f\u00f6rfr\u00e5gan som skickas till Google-s\u00f6kningen kan man se detta:<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: F\u00f6rst\u00f6relsen av grunderna och en underbar ny v\u00e4rld\" src=\"\/wp-content\/uploads\/2019\/11\/af422268eb85b488c7be1b70c6d33fad.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Slutsatser<\/h2>\n<p>\nQUIC ser nu ut som en ganska r\u00e5, men mycket lovande teknik. Med tanke p\u00e5 att de senaste 20 \u00e5ren har all optimering av transportprotokoll fr\u00e4mst r\u00f6rt TCP, verkar QUIC, som i de flesta fall vinner p\u00e5 prestandan, redan nu vara ganska bra. <\/p>\n<p>Dock finns det fortfarande ol\u00f6sta problem som m\u00e5ste hanteras under de kommande \u00e5ren. Processen kan dra ut p\u00e5 tiden eftersom det handlar om h\u00e5rdvara som ingen gillar att uppdatera, men alla problem verkar \u00e4nd\u00e5 vara ganska l\u00f6sbara, och f\u00f6rr eller senare kommer vi alla att ha HTTP\/3. <\/p>\n<p>Framtiden \u00e4r n\u00e4ra!<br \/>\n<br \/>K\u00e4lla: <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\/sv\/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=\"sv_SE\" \/>\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\/sv\/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: Att rasera grunderna och en fantastisk ny v\u00e4rld | ProHoster","description":"I \u00f6ver 20 \u00e5r har vi sett webbsidor genom protokollet HTTP. De flesta anv\u00e4ndare t\u00e4nker \u00f6verhuvudtaget inte p\u00e5 vad det \u00e4r och hur det fungerar.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/52181","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=52181"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/52181\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=52181"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=52181"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=52181"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}