{"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\/da\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","title":{"rendered":"HTTP\/3: nedbrydning af grundl\u00e6ggende principper og en vidunderlig ny verden","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>I over 20 \u00e5r har vi set websteder gennem HTTP-protokollen. De fleste brugere t\u00e6nker slet ikke over, hvad det er, og hvordan det fungerer. Andre ved, at der et sted under HTTP er TLS, og under det TCP, og under det IP, og s\u00e5 videre. Og nogle \u2013 de heretikere \u2013 mener, at TCP er fortid, og de \u00f8nsker noget hurtigere, mere p\u00e5lideligt og sikkert. Men i deres fors\u00f8g p\u00e5 at finde en ny ideel protokol er de g\u00e5et tilbage til teknologierne fra 80'erne og pr\u00f8ver at bygge en vidunderlig ny verden p\u00e5 dem.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: nedbrydning af grundl\u00e6ggende principper og en vidunderlig ny verden\" 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>Lidt historie: HTTP\/1.1<\/h2>\n<p>\nI 1997 fik tekstudvekslingsprotokollen HTTP version 1.1 sit RFC. P\u00e5 det tidspunkt var protokollen allerede blevet brugt af browsere i flere \u00e5r, og den nye standard holdt i yderligere femten. Protokollen fungerede kun efter foresp\u00f8rgsels-svar-princippet og var hovedsageligt beregnet til at overf\u00f8re tekstinformation.<\/p>\n<p>HTTP blev designet til at arbejde oven p\u00e5 TCP-protokollen, som sikrer p\u00e5lidelig levering af pakker til modtageren. TCP's funktionsm\u00e5de er baseret p\u00e5 at etablere og opretholde en p\u00e5lidelig forbindelse mellem endepunkter og opdelt trafik i segmenter. Segmenterne har deres egen sekvensnummer og kontrolsum. Hvis et af segmenterne ikke kommer frem, eller kommer med en forkert kontrolsum, stopper transmissionen, indtil det tabte segment er genoprettet.<\/p>\n<p>I HTTP\/1.0 blev TCP-forbindelsen lukket efter hver foresp\u00f8rgsel. Dette var ekstremt spild, da etableringen af en TCP-forbindelse (3-Way-Handshake) ikke er en hurtig proces. I HTTP\/1.1 blev der introduceret en keep-alive-mekanisme, der tillader genbrug af \u00e9n forbindelse til flere foresp\u00f8rgsler. Men da det let kan blive en flaskehals, tillader forskellige implementeringer af HTTP\/1.1 \u00e5bning af flere TCP-forbindelser til \u00e9n v\u00e6rt. For eksempel tillader Chrome og de nyeste versioner af Firefox op til seks forbindelser.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: nedbrydning af grundl\u00e6ggende principper og en vidunderlig ny verden\" src=\"\/wp-content\/uploads\/2019\/11\/b1c131da8e62ace741f3064f2fb96c60.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nKryptering blev ogs\u00e5 meningen skulle overlades til andre protokoller, og derfor anvendte man TLS-protokollen oven p\u00e5 TCP, som ganske p\u00e5lideligt beskyttede data, men ogs\u00e5 i h\u00f8jere grad \u00f8gede den tid, der kr\u00e6ves for at etablere forbindelsen. I sidste ende s\u00e5 h\u00e5ndtryksprocessen s\u00e5dan ud:<br \/>\n <img decoding=\"async\" alt=\"HTTP\/3: nedbrydning af grundl\u00e6ggende principper og en vidunderlig ny verden\" src=\"\/wp-content\/uploads\/2019\/11\/2fdccf56e0ed29444557836fdc65351b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Illustration Cloudflare<\/i><\/p>\n<p>S\u00e5ledes havde HTTP\/1.1 en r\u00e6kke problemer:<\/p>\n<ul>\n<li>Langsom oprettelse af forbindelse.<\/li>\n<li>Data overf\u00f8res som tekst, hvilket g\u00f8r overf\u00f8rslen af billeder, videoer og anden ikke-tekstual information ineffektiv.<\/li>\n<li>\u00c9n TCP-forbindelse bruges til \u00e9n anmodning, hvilket betyder, at de \u00f8vrige anmodninger m\u00e5 finde en anden forbindelse eller vente, indtil den nuv\u00e6rende anmodning afsluttes.<\/li>\n<li>Kun pull-modellen underst\u00f8ttes. Der er ikke noget om server-push i standarden.<\/li>\n<li>Overskrifterne sendes som tekst.<\/li>\n<\/ul>\n<p>\nHvis server-push sv\u00e6rt kan implementeres via WebSocket-protokollen, s\u00e5 skulle der findes mere radikale l\u00f8sninger til de \u00f8vrige problemer.<\/p>\n<h2>Lidt modernitet: HTTP\/2<\/h2>\n<p>\nI 2012 begyndte Google at arbejde p\u00e5 SPDY-protokollen (udtales \"spidi\"). Protokollen skulle l\u00f8se de vigtigste problemer ved HTTP\/1.1 og skulle samtidig bevare bagudkompatibilitet. I 2015 pr\u00e6senterede IETF\u2019s arbejdsgruppe specifikationen for HTTP\/2, baseret p\u00e5 SPDY-protokollen. Her er de forskelle, der var i HTTP\/2:<\/p>\n<ul>\n<li>Bin\u00e6r serialisering.<\/li>\n<li>Multiplexing af flere HTTP-anmodninger i \u00e9n TCP-forbindelse.<\/li>\n<li>Server-push lige fra starten (uden WebSocket).<\/li>\n<\/ul>\n<p>\nProtokollen var et stort skridt fremad. Den betydeligt <noindex><a rel=\"nofollow\" href=\"https:\/\/http2.akamai.com\/demo\">overg\u00e5r den f\u00f8rste version med hensyn til hastighed<\/a><\/noindex> og kr\u00e6ver ikke oprettelse af flere TCP-forbindelser: alle anmodninger til \u00e9n v\u00e6rt multiplexes i \u00e9n. Det vil sige, at der i \u00e9n forbindelse er flere s\u00e5kaldte streams, hver med sit ID. Som en bonus f\u00e5r man server-push lige fra starten.<\/p>\n<p>Men multiplexing f\u00f8rer til et andet grundl\u00e6ggende problem. T\u00e6nk p\u00e5, at vi asynkront laver 5 anmodninger til \u00e9n server. N\u00e5r vi bruger HTTP\/2, vil alle disse anmodninger blive udf\u00f8rt inden for \u00e9n TCP-forbindelse, og hvis en hvilken som helst segment af nogen anmodning g\u00e5r tabt eller er forkert, stopper transmissionen af alle anmodninger og svar, indtil det tabte segment er genoprettet. Det er indlysende, at jo d\u00e5rligere kvaliteten af forbindelsen er, desto langsommere fungerer HTTP\/2. <noindex><a rel=\"nofollow\" href=\"https:\/\/http3-explained.haxx.se\/en\/why-tcphol.html\">If\u00f8lge Daniel Stenberg<\/a><\/noindex>, i situationer hvor tabte pakker udg\u00f8r 2% af alle, pr\u00e6sterer HTTP\/1.1 i browseren bedre end HTTP\/2, da den \u00e5bner 6 forbindelser i stedet for \u00e9n.<\/p>\n<p>Dette problem kaldes \"head-of-line blocking\", og desv\u00e6rre ser det ikke ud til at kunne l\u00f8ses ved brug af TCP.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: nedbrydning af grundl\u00e6ggende principper og en vidunderlig ny verden\" src=\"\/wp-content\/uploads\/2019\/11\/234a6dc218a9acf8d2212fbdf28f2188.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Illustration af Daniel Steinberg<\/i><\/p>\n<p>Som konklusion har udviklerne af HTTP\/2-standarden udf\u00f8rt et kolossalt stykke arbejde og gjort stort set alt, hvad der kunne g\u00f8res p\u00e5 applikationsniveau i OSI-modellen. Det er tid til at bev\u00e6ge sig ned p\u00e5 transportniveauet og opfinde en ny transportprotokol.<\/p>\n<h2>Vi har brug for en ny protokol: UDP vs TCP<\/h2>\n<p>\nDet blev hurtigt klart, at implementering af en helt ny transportprotokol er en umulig opgave i dagens realiteter. Problemet er, at transportlaget er kendt af hardware enheder eller middle-boxes (routere, firewalls, NAT-servere\u2026), og det er en yderst kompleks opgave at l\u00e6re dem noget nyt. Desuden er underst\u00f8ttelse af transportprotokoller indbygget i kernen af operativsystemerne, og kernerne \u00e6ndres heller ikke s\u00e5 villigt.<\/p>\n<p>Her kunne man give op og sige: \"Vi vil selvf\u00f8lgelig opfinde ny HTTP\/3 med pr\u00e6ferencer og kurtisaner, men det vil tage 10-15 \u00e5r at implementere (det er omtrent den tid, det vil tage, f\u00f8r de fleste enheder er udskiftet),\" men der er endnu en ikke s\u00e5 indlysende mulighed: at bruge UDP-protokollen. Ja, lige pr\u00e6cis den protokol, vi brugte til at sende filer lokalt i slutningen af 90'erne og starten af 00'erne. N\u00e6sten alt dagens udstyr kan arbejde med den.<\/p>\n<p>Hvad er fordelene ved UDP i forhold til TCP? F\u00f8rst og fremmest, at vi ikke har en transportsessionsforbindelse, som udstyret kender til. Dette giver os mulighed for selv at definere sessionen p\u00e5 endepunkterne og der ogs\u00e5 l\u00f8se opst\u00e5ede konflikter. Det vil sige, at vi ikke er begr\u00e6nset til \u00e9n eller flere sessioner (som i TCP), men kan oprette s\u00e5 mange vi har brug for. For det andet sker dataoverf\u00f8rslen hurtigere over UDP end over TCP. Teoretisk set kan vi derfor bryde den nuv\u00e6rende hastighedsgr\u00e6nse, der er n\u00e5et i HTTP\/2. <\/p>\n<p>Men UDP garanterer ikke p\u00e5lideligheden af dataoverf\u00f8rsel. Faktisk sender vi bare pakker og h\u00e5ber, at de bliver modtaget i den anden ende. Fik de ikke det? N\u00e5, s\u00e5 var det ikke heldigt... Dette var tilstr\u00e6kkeligt til at transmittere voksenvideoer, men til mere seri\u00f8se ting er der behov for p\u00e5lidelighed, hvilket betyder, at det bliver n\u00f8dvendigt at l\u00e6gge noget ekstra oven p\u00e5 UDP.<\/p>\n<p>Som med HTTP\/2 begyndte arbejdet med at skabe den nye protokol i Google i 2012, alts\u00e5 omtrent samtidig med begyndelsen p\u00e5 arbejdet med SPDY. I 2013 pr\u00e6senterede Jim Roskind protokollen for offentligheden. <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.google.com\/document\/d\/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34\/edit\">QUIC-protokollen (Quick UDP Internet Connections)<\/a><\/noindex>, og allerede i 2015 blev der indsendt et Internet Draft til standardisering i IETF. Allerede p\u00e5 det tidspunkt adskilte den protokol, der blev udviklet af Roskind hos Google, sig kraftigt fra den, som blev pr\u00e6senteret til standard, s\u00e5 Googles version blev kaldt gQUIC.<\/p>\n<h4>Hvad er QUIC<\/h4>\n<p>\nFor det f\u00f8rste, som n\u00e6vnt, er det et lag oven p\u00e5 UDP. Oven p\u00e5 UDP opbygges en QUIC-forbindelse, hvor flere streams kan eksistere p\u00e5 samme tid, ligesom med HTTP\/2. Disse streams eksisterer kun p\u00e5 endpoints og h\u00e5ndteres uafh\u00e6ngigt. Hvis der sker et pakketab i en stream, p\u00e5virker det ikke de andre.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: nedbrydning af grundl\u00e6ggende principper og en vidunderlig ny verden\" src=\"\/wp-content\/uploads\/2019\/11\/0a64aa26d9b8216db56d389fa48578a5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Illustration af Daniel Steinberg<\/i><\/p>\n<p>For det andet er kryptering nu implementeret ikke som et separat lag, men som en del af protokollen. Dette muligg\u00f8r, at man kan etablere en forbindelse og udveksle offentlige n\u00f8gler i \u00e9t handshake, og det muligg\u00f8r ogs\u00e5 brugen af en smart mekanisme til 0-RTT handshake, hvilket helt undg\u00e5r forsinkelser ved handshaket. Desuden kan man nu kryptere individuelle datapakker. Dette g\u00f8r det muligt at dechiffrere de modtagne pakker uafh\u00e6ngigt af, om dataene fra streamen er fuldf\u00f8rt. En s\u00e5dan driftsmode var helt umulig i TCP, da TLS og TCP arbejdede uafh\u00e6ngigt af hinanden, og TLS ikke kunne vide, hvordan dataene ville blive opdelt af TCP. Derfor kunne det ikke forberede sine segmenter, s\u00e5 de matchede TCP-segmenterne en til en og kunne dekrypteres uafh\u00e6ngigt. Alle disse forbedringer g\u00f8r det muligt for QUIC at reducere latens i forhold til TCP.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: nedbrydning af grundl\u00e6ggende principper og en vidunderlig ny verden\" src=\"\/wp-content\/uploads\/2019\/11\/cb3c522636f7a052a0f5988fe7ea3a65.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nFor det tredje tillader konceptet med lette streams at adskille forbindelsen fra klientens IP-adresse. Dette er vigtigt, for eksempel n\u00e5r klienten skifter fra et Wi-Fi-netv\u00e6rk til et andet, hvilket \u00e6ndrer sin IP. I dette tilf\u00e6lde gennemg\u00e5r TCP en lang proces, hvor eksisterende TCP-forbindelser falder ud p\u00e5 grund af timeout, og der oprettes nye forbindelser med den nye IP. I tilf\u00e6lde af QUIC forts\u00e6tter klienten simpelthen med at sende pakker til serveren fra den nye IP med det gamle stream-ID. Da stream-ID'et nu er unikt og ikke genbruges, forst\u00e5r serveren, at klienten har \u00e6ndret IP, sender de tabte pakker, der mangler, og forts\u00e6tter kommunikationen p\u00e5 den nye adresse.<\/p>\n<p>For det fjerde implementeres QUIC p\u00e5 applikationsniveau og ikke p\u00e5 operativsystemniveau. Dette g\u00f8r det hurtigere at foretage \u00e6ndringer i protokollen, da man blot skal opdatere biblioteket for at f\u00e5 en opdatering i stedet for at vente p\u00e5 en ny version af OS. P\u00e5 den ene side f\u00f8rer det til en betydelig stigning i CPU-forbruget.<\/p>\n<p>Og til sidst, overskrifterne. Kompressionen af overskrifterne er netop et aspekt, der adskiller QUIC fra gQUIC. Jeg ser ikke nogen grund til at bruge meget tid p\u00e5 dette, jeg vil kun sige, at i den version, der er blevet fremsat til standardisering, er kompressionen af overskrifterne gjort s\u00e5 ligesom kompressionen i HTTP\/2. Du kan l\u00e6se mere <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">her<\/a><\/noindex>.<\/p>\n<h4>Hvor meget hurtigere er det?<\/h4>\n<p>\nDet er et komplekst sp\u00f8rgsm\u00e5l. Tingen er, at vi ikke har en standard endnu, s\u00e5 der er ikke meget at m\u00e5le. M\u00e5ske er de eneste statistiske data, vi har, statistikken fra Google, som har brugt gQUIC siden 2013 og i 2016 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.ietf.org\/proceedings\/96\/slides\/slides-96-quic-3.pdf\">rapporterede til IETF<\/a><\/noindex>, at omkring 90% af trafikken til deres servere fra Chrome-browseren nu bruger QUIC. I denne samme pr\u00e6sentation rapporterer de, at sider indl\u00e6ses cirka 5% hurtigere gennem gQUIC, og at der er 30% f\u00e6rre h\u00e6ngninger i streamingvideo i forhold til TCP. <\/p>\n<p>I 2017 offentliggjorde en gruppe forskere ledet af Arash Molavi Kakhki <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">stort arbejde<\/a><\/noindex> en unders\u00f8gelse af ydeevnen af gQUIC sammenlignet med TCP. <br \/>\nUnders\u00f8gelsen afd\u00e6kkede flere svagheder ved gQUIC, s\u00e5som ustabilitet over for netv\u00e6rkspakkeombygningsmetoder, gr\u00e5dighed (unfairness) i forhold til kanalens b\u00e5ndbredde og langsommere overf\u00f8rsel af sm\u00e5 (op til 10 kB) objekter. Det sidste kan dog kompensere for ved hj\u00e6lp af 0-RTT. I alle andre unders\u00f8gte tilf\u00e6lde viste gQUIC en hastighedsfor\u00f8gelse i forhold til TCP. Det er sv\u00e6rt at tale om konkrete tal her. Det er bedre at l\u00e6se <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">selve unders\u00f8gelsen<\/a><\/noindex> eller <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.apnic.net\/2018\/01\/29\/measuring-quic-vs-tcp-mobile-desktop\/\">et kort indl\u00e6g<\/a><\/noindex>.<\/p>\n<p>Her skal det siges, at dette data specifikt handler om gQUIC, og at de ikke er relevante for den standard, der er under udvikling. Hvad der vil ske for QUIC: Det forbliver en hemmelighed, men der er h\u00e5b om, at de svagheder, der blev identificeret i gQUIC, vil blive taget i betragtning og rettet.<\/p>\n<h2>En smule fremtidsudsigter: hvad med HTTP\/3?<\/h2>\n<p>\nHer er alt glasklart: API'en vil ikke \u00e6ndre sig. Alt forbliver pr\u00e6cis som det var i HTTP\/2. Hvis API'en forbliver den samme, skal overgangen til HTTP\/3 h\u00e5ndteres ved at bruge en ny version af biblioteket p\u00e5 backend, som underst\u00f8tter transport via QUIC. Men det vil tage lang tid, f\u00f8r vi kan slippe for at have et fallback til gamle HTTP-versioner, da internettet i \u00f8jeblikket ikke er klart til en fuldst\u00e6ndig overgang til UDP.<\/p>\n<h4>Hvem underst\u00f8tter allerede<\/h4>\n<p>\nHer er <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/quicwg\/base-drafts\/wiki\/Implementations\">liste<\/a><\/noindex> eksisterende QUIC-implementeringer. P\u00e5 trods af manglen p\u00e5 en standard er listen ikke d\u00e5rlig. <\/p>\n<p>Ingen browser underst\u00f8tter i \u00f8jeblikket QUIC i produktionsversionen. For nylig blev der meldt om, at Chrome har aktiveret underst\u00f8ttelse af HTTP\/3, men kun i Canary. <\/p>\n<p>Af backend-l\u00f8sninger underst\u00f8tter kun <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/caddyserver\/caddy\">Caddy<\/a><\/noindex> og <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/http3-the-past-present-and-future\/\">Cloudflare<\/a><\/noindex>, men det er stadig eksperimentelt. NGINX arbejdede i slutningen af for\u00e5ret 2019 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.nginx.com\/blog\/nginx-1-16-1-17-released\/\">at de kun havde to blokke tilbage \/8.<\/a><\/noindex>, hvilket indikerer, at de er i gang med at arbejde p\u00e5 underst\u00f8ttelse af HTTP\/3, men de er endnu ikke f\u00e6rdige.<\/p>\n<h4>Hvilke problemer der er<\/h4>\n<p>\nVi lever i en virkelighed, hvor ingen store teknologier kan n\u00e5 masserne uden at m\u00f8de modstand, og QUIC er intet undtagelse.<\/p>\n<p>Det vigtigste er, at man p\u00e5 en eller anden m\u00e5de skal forklare browseren, at \"https:\/\/\" nu ikke n\u00f8dvendigvis peger p\u00e5 TCP-port 443. Der kan slet ikke v\u00e6re TCP. Dette g\u00f8res ved hj\u00e6lp af Alt-Svc headeren. Den tillader browseren at vide, at denne hjemmeside ogs\u00e5 er tilg\u00e6ngelig p\u00e5 en bestemt protokol via en bestemt adresse. I teorien skulle dette fungere som smurt, men i praksis vil vi st\u00f8de p\u00e5, at UDP muligvis er blokkeret af en firewall for at forhindre DDoS-angreb.<\/p>\n<p>Men selv hvis UDP ikke er blokeret, kan klienten befinde sig bag en NAT-router, der er konfigureret til at opretholde TCP-sessionen p\u00e5 IP-adressen, og da vi bruger UDP, som ikke har en h\u00e5rd sessionsh\u00e5ndtering, vil NAT ikke opretholde forbindelsen, og QUIC-sessionen <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">vil konstant blive afbrudt.<\/a><\/noindex>. <\/p>\n<p>Alle disse problemer er relateret til, at UDP tidligere ikke har v\u00e6ret brugt til at overf\u00f8re internetindhold, og hardwareproducenterne kunne ikke forudse, at dette en dag ville ske. Ligeledes forst\u00e5r administratorer heller ikke helt, hvordan de korrekt skal konfigurere deres netv\u00e6rk til at arbejde med QUIC. Denne situation vil langsomt \u00e6ndre sig, og under alle omst\u00e6ndigheder vil s\u00e5danne \u00e6ndringer tage mindre tid end implementeringen af en ny transportprotokol. <\/p>\n<p>Derudover, som allerede n\u00e6vnt, \u00f8ger QUIC kraftigt CPU-brugen. Daniel Stenberg <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=idViw4anA6E\">vurderede<\/a><\/noindex> stigningen i CPU-brug til op til tre gange.<\/p>\n<h4>Hvorn\u00e5r kommer HTTP\/3<\/h4>\n<p>\nStandarten <noindex><a rel=\"nofollow\" href=\"https:\/\/datatracker.ietf.org\/wg\/quic\/about\/\">\u00f8nskes vedtaget.<\/a><\/noindex> I maj 2020, men givet at de nuv\u00e6rende dokumenter, der er planlagt til juli 2019, stadig ikke er f\u00e6rdige, kan man sige, at datoen sandsynligvis vil blive udsat.<\/p>\n<p>Google har brugt sin implementation af gQUIC siden 2013. Hvis man ser p\u00e5 HTTP-anmodningen, der sendes til Googles s\u00f8gemaskine, kan man se dette:<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: nedbrydning af grundl\u00e6ggende principper og en vidunderlig ny verden\" src=\"\/wp-content\/uploads\/2019\/11\/af422268eb85b488c7be1b70c6d33fad.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Konklusioner<\/h2>\n<p>\nQUIC fremst\u00e5r nu som en ret uudviklet, men meget lovende teknologi. I betragtning af at de sidste 20 \u00e5r har fokus v\u00e6ret p\u00e5 optimeringer af transportprotokoller stort set kun med TCP, ser QUIC, som i de fleste tilf\u00e6lde vinder p\u00e5 ydeevne, allerede nu ret godt ud. <\/p>\n<p>Der er dog stadig uafklarede problemer, som vi skal tackle i de kommende \u00e5r. Processen kan tr\u00e6kke ud, fordi der er hardware involveret, som ingen elsker at opdatere, men alle problemer ser faktisk ud til at v\u00e6re h\u00e5ndterbare, og f\u00f8r eller senere vil vi alle have HTTP\/3. <\/p>\n<p>Fremtiden er ikke langt v\u00e6k!<br \/>\n<br \/>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dodopizzaio\/blog\/473930\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u043e\u0442 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 20 \u043b\u0435\u0442 \u043c\u044b \u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0432\u0435\u0431-\u0441\u0442\u0440\u0430\u043d\u0438\u0447\u043a\u0438 \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 HTTP. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0435 \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u0438 \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442. \u0414\u0440\u0443\u0433\u0438\u0435 \u0437\u043d\u0430\u044e\u0442, \u0447\u0442\u043e \u0433\u0434\u0435-\u0442\u043e \u043f\u043e\u0434 HTTP \u0435\u0441\u0442\u044c TLS, \u0430 \u043f\u043e\u0434 \u043d\u0438\u043c TCP, \u043f\u043e\u0434 \u043a\u043e\u0442\u043e\u0440\u044b\u043c IP \u0438 \u0442\u0430\u043a \u0434\u0430\u043b\u0435\u0435. \u0410 \u0442\u0440\u0435\u0442\u044c\u0438 \u2013 \u0435\u0440\u0435\u0442\u0438\u043a\u0438 \u2013 \u0441\u0447\u0438\u0442\u0430\u044e\u0442, \u0447\u0442\u043e TCP \u2013 \u044d\u0442\u043e \u043f\u0440\u043e\u0448\u043b\u044b\u0439 \u0432\u0435\u043a, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-52181","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u043e\u0442 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 20 \u043b\u0435\u0442 \u043c\u044b \u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0432\u0435\u0431-\u0441\u0442\u0440\u0430\u043d\u0438\u0447\u043a\u0438 \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 HTTP. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0435 \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u0438 \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\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\/da\/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: At nedbryde grundlagene og den vidunderlige nye verden | ProHoster","description":"I over 20 \u00e5r har vi set websteder over HTTP-protokollen. De fleste brugere bekymrer sig slet ikke om, hvad det er, og hvordan det fungerer.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/52181","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=52181"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/52181\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=52181"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=52181"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=52181"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}