{"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\/nl\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","title":{"rendered":"HTTP\/3: de fundamenten ondermijnen en een wonderbaarlijke nieuwe wereld","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Al meer dan 20 jaar bekijken we webpagina's via het HTTP-protocol. De meeste gebruikers denken er helemaal niet over na wat het is en hoe het werkt. Anderen weten dat er ergens onder HTTP TLS is, en daaronder TCP, daaronder IP, en zo verder. En sommigen \u2013 ketters \u2013 beschouwen TCP als verouderd en willen iets snelers, betrouwbaarders en veiliger. Maar in hun pogingen om een nieuwe ideale protocol uit te vinden, zijn ze teruggekeerd naar technologie\u00ebn uit de jaren '80 en proberen ze daar hun wonderlijke nieuwe wereld op te bouwen.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: de fundamenten ondermijnen en een wonderbaarlijke nieuwe wereld\" 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>Een beetje geschiedenis: HTTP\/1.1<\/h2>\n<p>\nIn 1997 kreeg het tekstuitwisselingsprotocol HTTP versie 1.1 zijn RFC. Op dat moment werd het protocol al enkele jaren door browsers gebruikt, en de nieuwe standaard hield het nog vijftien jaar vol. Het protocol werkte uitsluitend volgens het verzoek-antwoordprincipe en was voornamelijk bedoeld voor het verzenden van tekstuele informatie.<\/p>\n<p>HTTP is ontworpen om bovenop het TCP-protocol te functioneren, dat een betrouwbare aflevering van pakketten aan de bestemming garandeert. TCP werkt door het opzetten en onderhouden van een betrouwbare verbinding tussen eindpunten en het opdelen van verkeer in segmenten. Segmenten hebben een volgnummer en een controlegetal. Als een van de segmenten niet aankomt of met een onjuist controlegetal arriveert, stopt de overdracht totdat het ontbrekende segment is hersteld.<\/p>\n<p>In HTTP\/1.0 werd de TCP-verbinding na elk verzoek gesloten. Dit was uiterst on effici\u00ebnt, omdat het opzetten van een TCP-verbinding (3-Way-Handshake) een traag proces is. In HTTP\/1.1 werd het keep-alive-mechanisme ge\u00efntroduceerd, waarmee \u00e9\u00e9n verbinding voor meerdere verzoeken kan worden hergebruikt. Omdat dit echter gemakkelijk een bottleneck kan worden, staan verschillende implementaties van HTTP\/1.1 het openen van meerdere TCP-verbindingen naar \u00e9\u00e9n host toe. Bijvoorbeeld, in Chrome en de recentste versies van Firefox zijn er tot zes verbindingen toegestaan.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: de fundamenten ondermijnen en een wonderbaarlijke nieuwe wereld\" src=\"\/wp-content\/uploads\/2019\/11\/b1c131da8e62ace741f3064f2fb96c60.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nVersleuteling werd ook bedoeld om aan andere protocollen te worden toevertrouwd, en daarvoor werd het TLS-protocol bovenop TCP gebruikt, dat de gegevens behoorlijk veilig beschermde, maar de tijd die nodig was om een verbinding op te zetten, nog verder verhoogde. Uiteindelijk zag het handshake-proces er als volgt uit:<br \/>\n <img decoding=\"async\" alt=\"HTTP\/3: de fundamenten ondermijnen en een wonderbaarlijke nieuwe wereld\" src=\"\/wp-content\/uploads\/2019\/11\/2fdccf56e0ed29444557836fdc65351b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Illustratie Cloudflare<\/i><\/p>\n<p>HTTP\/1.1 had dus een aantal problemen:<\/p>\n<ul>\n<li>Trage opzet van de verbinding.<\/li>\n<li>Gegevens worden in tekstformaat verzonden, wat betekent dat het verzenden van afbeeldingen, video's en andere niet-tekstuele informatie niet effici\u00ebnt is.<\/li>\n<li>\u00c9\u00e9n TCP-verbinding wordt gebruikt voor \u00e9\u00e9n verzoek, wat betekent dat andere verzoeken ofwel een andere verbinding moeten vinden, of moeten wachten totdat het huidige verzoek deze vrijgeeft.<\/li>\n<li>Alleen het pull-model wordt ondersteund. In de standaard staat niets over server-push.<\/li>\n<li>Koppen worden als tekst verzonden.<\/li>\n<\/ul>\n<p>\nAls server-push met enige moeite wordt ge\u00efmplementeerd via het WebSocket-protocol, moesten de andere problemen radicaler worden aangepakt.<\/p>\n<h2>Een beetje moderniteit: HTTP\/2<\/h2>\n<p>\nIn 2012 begon Google te werken aan het SPDY-protocol (uitgesproken als 'speedy'). Dit protocol was ontworpen om de belangrijkste problemen van HTTP\/1.1 op te lossen, terwijl het ook de achterwaartse compatibiliteit moest waarborgen. In 2015 presenteerde de IETF-werkgroep de specificatie van HTTP\/2, gebaseerd op het SPDY-protocol. Dit zijn de verschillen in HTTP\/2:<\/p>\n<ul>\n<li>Binaire serialisatie.<\/li>\n<li>Multiplexing van meerdere HTTP-verzoeken binnen \u00e9\u00e9n TCP-verbinding.<\/li>\n<li>Server-push out-of-the-box (zonder WebSocket).<\/li>\n<\/ul>\n<p>\nHet protocol betekende een grote sprong voorwaarts. Het <noindex><a rel=\"nofollow\" href=\"https:\/\/http2.akamai.com\/demo\">wint aanzienlijk aan snelheid ten opzichte van de eerste versie<\/a><\/noindex> en vereist geen meerdere TCP-verbindingen: alle verzoeken naar \u00e9\u00e9n host worden gemultiplexed in \u00e9\u00e9n verbinding. Dit betekent dat er binnen \u00e9\u00e9n verbinding meerdere zogeheten streams zijn, elk met zijn eigen ID. Als bonus is er server-push ingebouwd.<\/p>\n<p>Echter, multiplexing leidt tot een ander cruciaal probleem. Stel je voor dat we asynchroon 5 verzoeken naar dezelfde server uitvoeren. Bij het gebruik van HTTP\/2 worden al deze verzoeken uitgevoerd binnen \u00e9\u00e9n TCP-verbinding, en als een van de segmenten van een verzoek verloren gaat of incorrect aankomt, wordt de overdracht van alle verzoeken en antwoorden stopgezet totdat het verloren segment is hersteld. Het is duidelijk dat hoe slechter de kwaliteit van de verbinding, hoe langzamer HTTP\/2 werkt. <noindex><a rel=\"nofollow\" href=\"https:\/\/http3-explained.haxx.se\/en\/why-tcphol.html\">Volgens Daniel Stenberg<\/a><\/noindex>, toont HTTP\/1.1 zich beter in omstandigheden waarin verloren pakketten 2% van alles uitmaken, omdat het 6 verbindingen opent in plaats van \u00e9\u00e9n.<\/p>\n<p>Dit probleem wordt 'head-of-line blocking' genoemd en helaas is het niet mogelijk om dit op te lossen met TCP.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: de fundamenten ondermijnen en een wonderbaarlijke nieuwe wereld\" src=\"\/wp-content\/uploads\/2019\/11\/234a6dc218a9acf8d2212fbdf28f2188.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Illustratie Daniel Steinberg<\/i><\/p>\n<p>Als resultaat hebben de ontwikkelaars van de standaard HTTP\/2 enorm veel werk verricht en bijna alles gedaan wat mogelijk was op het toepassingsniveau van het OSI-model. Het is tijd om naar het transportniveau te dalen en een nieuw transportprotocol uit te vinden.<\/p>\n<h2>We hebben een nieuw protocol nodig: UDP vs TCP<\/h2>\n<p>\nHet werd al snel duidelijk dat het implementeren van een geheel nieuw transportprotocol in de huidige realiteit een onoplosbare taak is. Het probleem is dat de hardware of middle-boxes (routers, firewalls, NAT-servers\u2026) bekend zijn met het transportniveau, en ze iets nieuws aanleren is een uiterst ingewikkelde opgave. Bovendien is de ondersteuning van transportprotocollen ingebouwd in de kernel van besturingssystemen, en de kernels veranderen ook niet bepaald graag.<\/p>\n<p>En hier zou je je handen kunnen laten hangen en zeggen: \"Natuurlijk zullen we een nieuwe HTTP\/3 uitvinden met voorkeuren en courtisanes, maar het zal 10-15 jaar duren voordat deze is ge\u00efmplementeerd (ongeveer in die tijd zullen de meeste apparaten zijn vervangen)\", maar er is nog een niet zo voor de hand liggende optie: gebruik het UDP-protocol. Ja, datzelfde protocol waarmee we aan het einde van de jaren negentig en het begin van de jaren 2000 bestandjes over het lokale netwerk gooiden. Praktisch alle huidige apparaten kunnen ermee werken.<\/p>\n<p>Wat zijn de voordelen van UDP ten opzichte van TCP? In de eerste plaats dat we geen transportniveau-sessie hebben waar de hardware van weet. Dit stelt ons in staat om zelf de sessie op de eindpunten te bepalen en daar ook de conflicten op te lossen die ontstaan. Dat wil zeggen dat we niet gebonden zijn aan \u00e9\u00e9n of meerdere sessies (zoals bij TCP), maar we zoveel sessies kunnen cre\u00ebren als we nodig hebben. Ten tweede vindt de gegevensoverdracht via UDP sneller plaats dan via TCP. Theoretisch kunnen we dus de huidige snelheidslimiet die we in HTTP\/2 hebben bereikt, doorbreken. <\/p>\n<p>Echter, UDP garandeert geen betrouwbaarheid van gegevensoverdracht. In feite sturen we gewoon pakketten en hopen we dat ze aan de andere kant worden ontvangen. Niet ontvangen? Jammer dan... Dit was voldoende voor het verzenden van video's voor volwassenen, maar voor serieuzere dingen is betrouwbaarheid nodig, wat betekent dat we nog iets bovenop UDP moeten bouwen.<\/p>\n<p>Net als bij HTTP\/2 begon het werk aan het nieuwe protocol in 2012 bij Google, dat is ongeveer rond dezelfde tijd als de start van het werk aan SPDY. In 2013 presenteerde Jim Roskind het brede publiek <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.google.com\/document\/d\/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34\/edit\">het QUIC-protocol (Quick UDP Internet Connections)<\/a><\/noindex>, en in 2015 werd er een Internet Draft ingediend voor standaardisatie bij de IETF. Op dat moment verschilde het door Roskind bij Google ontwikkelde protocol aanzienlijk van het voorgestelde standaard, waardoor de Google-versie gQUIC werd genoemd.<\/p>\n<h4>Wat is QUIC<\/h4>\n<p>\nTen eerste, zoals eerder vermeld, is het een wrapper bovenop UDP. Bovenop UDP wordt een QUIC-verbinding opgezet, waarin net als bij HTTP\/2 meerdere streams kunnen bestaan. Deze streams bestaan alleen op de eindpunten en worden onafhankelijk behandeld. Als er een pakketverlies optreedt in \u00e9\u00e9n stream, heeft dat geen invloed op de andere.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: de fundamenten ondermijnen en een wonderbaarlijke nieuwe wereld\" src=\"\/wp-content\/uploads\/2019\/11\/0a64aa26d9b8216db56d389fa48578a5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Illustratie Daniel Steinberg<\/i><\/p>\n<p>Ten tweede wordt encryptie nu niet als een apart niveau gerealiseerd, maar is het ge\u00efntegreerd in het protocol. Dit maakt het mogelijk om een verbinding tot stand te brengen en publieke sleutels uit te wisselen met \u00e9\u00e9n handdruk, en het stelt ons in staat om het slimme mechanisme van 0-RTT handshake te gebruiken en \u00fcberhaupt vertragingen bij de handshake te vermijden. Bovendien kunnen nu afzonderlijke datapakketten gecodeerd worden. Dit maakt het mogelijk om niet te wachten op het afsluiten van gegevensontvangst uit de stream, maar ontvangen pakketten onafhankelijk te ontsleutelen. Zo'n werkwijze was in TCP helemaal niet mogelijk, omdat TLS en TCP onafhankelijk van elkaar werkten en TLS niet kon weten in welke stukken TCP de gegevens zouden worden verdeeld. En dus kon het geen segmenten voorbereiden die precies in de TCP-segmenten pasten en onafhankelijk konden worden ontsleuteld. Al deze verbeteringen stellen QUIC in staat om de latentie te verlagen in vergelijking met TCP.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: de fundamenten ondermijnen en een wonderbaarlijke nieuwe wereld\" src=\"\/wp-content\/uploads\/2019\/11\/cb3c522636f7a052a0f5988fe7ea3a65.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nTen derde maakt het concept van lichte streams het mogelijk om de verbinding los te koppelen van het IP-adres van de client. Dit is bijvoorbeeld belangrijk wanneer de client van het ene Wi-Fi-toegangspunt naar een ander schakelt, waarbij zijn IP verandert. In dit geval vindt er bij gebruik van TCP een langdurig proces plaats, waarin bestaande TCP-verbindingen tijdig worden verbroken en nieuwe verbindingen worden aangemaakt met het nieuwe IP. In het geval van QUIC blijft de client gewoon pakketten naar de server sturen vanaf het nieuwe IP met de oude stream-ID. Aangezien de stream-ID nu uniek is en niet opnieuw wordt gebruikt, begrijpt de server dat de client van IP is veranderd, stuurt verloren pakketten opnieuw en gaat de communicatie op het nieuwe adres verder.<\/p>\n<p>Ten vierde wordt QUIC op toepassingsniveau ge\u00efmplementeerd en niet op het niveau van het besturingssysteem. Dit maakt het aan de ene kant mogelijk om sneller wijzigingen in het protocol door te voeren, omdat het voldoende is om de bibliotheek bij te werken in plaats van te wachten op een nieuwe versie van het besturingssysteem. Aan de andere kant leidt dit tot een sterke toename van het CPU-gebruik.<\/p>\n<p>Dan de headers. Headercompressie is precies zo'n aspect dat verschilt tussen QUIC en gQUIC. Ik zie niet in waarom we hier veel tijd aan zouden moeten besteden, ik zeg alleen dat in de versie die ter standaardisatie is ingediend, de headercompressie zo veel mogelijk gelijk is gemaakt aan die van HTTP\/2. Meer details zijn te lezen. <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">hier<\/a><\/noindex>.<\/p>\n<h4>Hoeveel sneller is het?<\/h4>\n<p>\nDit is een complexe vraag. Het probleem is dat we op dit moment geen standaard hebben, dus er is niet veel te meten. De enige statistieken die we hebben, zijn die van Google, dat gQUIC sinds 2013 gebruikt en in 2016 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.ietf.org\/proceedings\/96\/slides\/slides-96-quic-3.pdf\">voor de IETF verslag heeft uitgebracht,<\/a><\/noindex>, dat ongeveer 90% van het verkeer naar hun servers vanuit de Chrome-browser nu QUIC gebruikt. In dezelfde presentatie geven ze aan dat pagina's via gQUIC ongeveer 5% sneller laden, terwijl er bij streamingvideo's 30% minder haperingen zijn in vergelijking met TCP. <\/p>\n<p>In 2017 publiceerde een groep onderzoekers onder leiding van Arash Molavi Kakhki <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">veel werk<\/a><\/noindex> een studie over de prestaties van gQUIC in vergelijking met TCP. <br \/>\nHet onderzoek heeft verschillende zwakke punten van gQUIC aan het licht gebracht, zoals kwetsbaarheid voor netwerkpakketvermeandering, hebzucht (unfairness) met betrekking tot de kanaalcapaciteit en tragere overdracht van kleine (tot 10 kB) objecten. Dit laatste kan overigens gecompenseerd worden met 0-RTT. In alle andere onderzochte gevallen toonde gQUIC een snelheidstoename in vergelijking met TCP. Over specifieke cijfers hier praten is moeilijk. Het is beter om <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">de studie zelf<\/a><\/noindex> of <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.apnic.net\/2018\/01\/29\/measuring-quic-vs-tcp-mobile-desktop\/\">een korte post<\/a><\/noindex>.<\/p>\n<p>Hier moet worden vermeld dat dit gegevens zijn over gQUIC en zij zijn niet relevant voor de momenteel ontwikkelde standaard. Wat er met QUIC zal gebeuren, blijft voorlopig een raadsel, maar er is hoop dat de zwakke punten die in gQUIC zijn vastgesteld, zullen worden aangepakt en gecorrigeerd.<\/p>\n<h2>Een beetje toekomstmuziek: en wat met HTTP\/3?<\/h2>\n<p>\nHier is alles kristalhelder: de API zal niet veranderen. Alles blijft precies zoals het was in HTTP\/2. En als de API hetzelfde blijft, moet de overstap naar HTTP\/3 worden gemaakt door de nieuwste versie van de bibliotheek aan de backend te gebruiken, die transport via QUIC ondersteunt. Het zal echter nog geruime tijd duren voordat er een fallback naar oudere versies van HTTP nodig is, omdat het internet momenteel niet klaar is voor een volledige overstap naar UDP.<\/p>\n<h4>Wie ondersteunt al<\/h4>\n<p>\nHier is <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/quicwg\/base-drafts\/wiki\/Implementations\">de lijst<\/a><\/noindex> bestaande QUIC-implementaties. Ondanks het gebrek aan een standaard, is de lijst niet slecht. <\/p>\n<p>Geen enkele browser ondersteunt momenteel QUIC in een productieversie. Recent was er informatie dat Chrome ondersteuning voor HTTP\/3 heeft ingeschakeld, maar alleen in Canary. <\/p>\n<p>Van de backends ondersteunt alleen <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/caddyserver\/caddy\">Caddy<\/a><\/noindex> en <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/http3-the-past-present-and-future\/\">Cloudflare<\/a><\/noindex>, maar momenteel experimenteel. NGINX heeft eind lente 2019 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.nginx.com\/blog\/nginx-1-16-1-17-released\/\">de aanvang aan van de distributie van het laatste blok \/8. Vanaf dat moment kon elke klant van de registrar slechts 1024 adressen verkrijgen, wat de uitputting van de voorraad enigszins vertraagde. Maar in 2015 had RIPE nog 16 miljoen beschikbare IP-adressen, en in de zomer van 2019 was dit aantal gedaald<\/a><\/noindex>, bekendgemaakt dat ze werken aan ondersteuning voor HTTP\/3, maar dat is nog niet afgerond.<\/p>\n<h4>Welke problemen zijn er<\/h4>\n<p>\nWe leven in een echte wereld waar geen enkele grote technologie populair kan worden zonder weerstand te ondervinden, en QUIC is daarop geen uitzondering.<\/p>\n<p>Het belangrijkste is dat je de browser moet uitleggen dat \"https:\/\/\" nu niet noodzakelijk naar poort 443 TCP leidt. TCP kan daar zelfs helemaal niet zijn. Dit wordt gedaan met de Alt-Svc-header. Hiermee kan de browser worden ge\u00efnformeerd dat deze website ook beschikbaar is op een ander protocol op een bepaald adres. In theorie zou dit als een klok moeten werken, maar in de praktijk stuiten we op het feit dat UDP bijvoorbeeld geblokkeerd kan zijn op de firewall om DDoS-aanvallen te voorkomen.<\/p>\n<p>Maar zelfs als UDP niet is geblokkeerd, kan de client zich achter een NAT-router bevinden, die is ingesteld om TCP-sessies vast te houden op IP-adres, en omdat we UDP gebruiken, dat geen hardware sessie heeft, zal NAT de verbinding niet behouden, en zal de QUIC-sessie <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">constant worden onderbroken<\/a><\/noindex>. <\/p>\n<p>Al deze problemen zijn gerelateerd aan het feit dat UDP vroeger niet werd gebruikt voor het verzenden van internetinhoud, en hardwarefabrikanten konden niet voorzien dat dit ooit zou gebeuren. Evenzo begrijpen beheerders tot nu toe niet goed hoe ze hun netwerken correct kunnen configureren om met QUIC te werken. Deze situatie zal langzaam veranderen, en in ieder geval zullen soortgelijke veranderingen minder tijd kosten dan de implementatie van een nieuw transportprotocol. <\/p>\n<p>Bovendien, zoals al beschreven, verhoogt QUIC het CPU-gebruik aanzienlijk. Daniel Stenberg <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=idViw4anA6E\">schatte<\/a><\/noindex> de groei in CPU-gebruik tot drie keer.<\/p>\n<h4>Wanneer komt HTTP\/3<\/h4>\n<p>\nDe standaard <noindex><a rel=\"nofollow\" href=\"https:\/\/datatracker.ietf.org\/wg\/quic\/about\/\">willen ze aannemen<\/a><\/noindex> In mei 2020, maar gezien het feit dat de documenten die voor juli 2019 gepland waren momenteel nog niet af zijn, kan worden gezegd dat de datum waarschijnlijk zal worden uitgesteld.<\/p>\n<p>Google gebruikt sinds 2013 zijn eigen implementatie van gQUIC. Als je de HTTP-aanroep bekijkt die naar de Google-zoekmachine wordt verzonden, zie je dit:<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3: de fundamenten ondermijnen en een wonderbaarlijke nieuwe wereld\" src=\"\/wp-content\/uploads\/2019\/11\/af422268eb85b488c7be1b70c6d33fad.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Conclusies<\/h2>\n<p>\nQUIC lijkt nu een vrij onvolmaakte, maar zeer veelbelovende technologie. Gezien het feit dat de afgelopen 20 jaar alle optimalisaties van transportprotocols voornamelijk met TCP te maken hadden, ziet QUIC, dat meestal beter presteert, er al heel goed uit. <\/p>\n<p>Echter, er blijven nog onopgeloste problemen die we de komende jaren moeten aanpakken. Het proces kan zich uitstrekken door de hardware die niemand graag bijwerkt, maar alle problemen lijken redelijk oplosbaar en vroeg of laat zullen we allemaal HTTP\/3 hebben. <\/p>\n<p>De toekomst is nabij!<br \/>\n<br \/>Bron: <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\/nl\/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=\"nl_NL\" \/>\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\/nl\/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: de basis afbreken en een wonderbaarlijke nieuwe wereld | ProHoster","description":"Al meer dan 20 jaar bekijken we webpagina's via het HTTP-protocol. De meeste gebruikers denken er helemaal niet over na wat het is en hoe het werkt.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/52181","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=52181"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/52181\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=52181"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=52181"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=52181"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}