Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Cloudflare, Firefox en Chrome starten ondersteuning voor http/3

Het Cloudflare-netwerk ondersteunt voortaan http/3, de specificatie die het huidige http/2 opvolgt en onder andere voor een sneller internet moet zorgen. Ook Chrome heeft vroege ondersteuning en voor Firefox is deze op komst.

De http/3-ondersteuning is nog experimenteel maar functioneel en de gezamenlijke start van Cloudflare, Chrome en Firefox toont aan dat de procedure voor internetstandaardisatie werkt, schrijft Cloudflare. In de praktijk bracht Cloudflare de ondersteuning al geruime tijd gefaseerd naar klanten, maar in de komende week kan elke klant van het bedrijf http/3-ondersteuning verwachten.

Chrome Canary heeft sinds vorige week ondersteuning voor de komende versie van het Hypertext Transfer Protocol; deze is in te schakelen met de flag "--enable-quic --quic-version=h3-23". Mozilla volgt binnenkort met een nightly van Firefox. Ook de commandlinetool curl ondersteunt het.

De voornaamste verandering bij de derde generatie van de http-specificatie is dat deze in plaats van tcp het door Google bedachte quic als transportprotocol gebruikt. Quic staat voor Quick UDP Internet Connections en werkt via udp. Het protocol brengt de communicatie tussen client en server om connecties op te zetten flink terug, met implementatie van tls 1.3 voor het realiseren van versleutelde verbindingen. Daardoor kunnen sneller verbindingen gelegd worden en verbeteren de latency en de beveiliging, zo is het doel.

De http/3-specificatie is momenteel nog een concepttekst waar de Internet Engineering Task Force nog aan werkt.

Door Olaf van Miltenburg

Nieuwscoördinator

26-09-2019 • 19:57

88 Linkedin Google+

Reacties (88)

Wijzig sortering
Nginx 1.17 de huidige development branch ('mainline') krijgt support voor QUIC en HTTP/3

https://www.nginx.com/blog/nginx-1-16-1-17-released

"What’s Coming in NGINX 1.17"

"Development has also started on support for QUIC and HTTP/3 – the next significant update to the transport protocols that will deliver websites, applications, and APIs. This is a significant undertaking, but likely to arrive during the NGINX 1.17 development cycle."

Helaas nog niets in de changelogs tot nu toe. (Sinds twee dagen zitten we op 1.17.4) https://nginx.org/en/CHANGES

Overigens heb ik nginx 'mainline' in productie gedraaid toen http/2 net af was, maar dat was wel een bumpy ride. Dat zal ik niet snel meer doen.
Thanks for the pointer.

Merk op dat "May 21, 2019" was de post date van die indicatie. Ik denk dat het gewoon niet gelukt is binnen de 1.17.x release cycle...
Hoe zit het eigenlijk met de adaptatie van http/2. Ik heb de indruk dat dit nog niet zo veel gebruikt wordt. Volgt deze nieuwe standaard de http/2 standaard niet te snel op, en levert dat geen weerstand op bij het migreren naar deze standaard ? ( ja, waarom moeten we nu naar http/3? We zijn ook niet naar http/2 gegaan en alles werkt nog)
Wij zijn een paar jaar terug wel volledig naar http/2 gegaan en direct na de switch nam de klanttevredenheid toe én ging de conversie van de site structureel omhoog en is de server belasting afgenomen door http/2. Daarnaast ging onze ranking omhoog omdat de klant ervaring was verbeterd t.o.v. de concurrentie.

Door naar http/3 te gaan zal het zelfde gebeuren; site staat ~ 200ms eerder op het scherm en de load op onze servers zal afnemen (minder handshakes). De beleving van de bezoeker verbeterd wat over het algemeen leidt tot betere conversie en betere ranking, dus meer zichtbaarheid van het merk en meer omzet tegen lagere kosten.

No brainier toch?

Google Ads en Facebook Ads gebruiken Quic al een aantal jaren, net zoals ~10% van de Chrome gebruikers op Google services geen AES maar een Quantum Processor proof encryptie algoritme krijgen. Toekomstige standaard techniek live testen, gaat er iets mis? Volgend request krijg je gewoon weer AES tot de volgende update. Heb je tot nu toe vast niets van gemerkt, hooguit soms verrast als een avertentie of Google dienst eens heel snel op je scherm stond ;)

Quic bestaat al een tijdje zie ook nieuws: Google: quic-protocol maakt laden van webpagina's sneller uit 2015, geeft aan dat het in 2013 bedacht is.

[Reactie gewijzigd door djwice op 26 september 2019 20:53]

en is de server belasting afgenomen door http/2
Heb je dat gemeten? Het grootste verschil tussen http/1 met ssl en http/2 was dat het totale aantal connecties een stuk lager is en er daardoor wat minder ssl-handshakes waren. Maar merk je daar zulke grote verschillen in serverbelasting van?
Door naar http/3 te gaan zal het zelfde gebeuren
Effectief is http/3 eigenlijk gewoon http/2 over udp. Maar doordat dat quic-protocol volledig in de client wordt afgehandeld, vermoed ik dat er misschien zelfs wel meer dan werk voor nodig is.
site staat ~ 200ms eerder op het scherm en de load op onze servers zal afnemen (minder handshakes)
Dat eerste is alleen zo in de 'perfecte' situatie dat er een relatief langzame verbinding is. In landen met goed internet, zoals Nederland, zou ik daardoor niet te hoge verwachtingen hebben hierbij. Zelfs niet met mobiel internet.
Verder ben ik benieuwd in hoeverre die voordelen overeind blijven in de echte wereld. Sowieso moet er e.e.a. aan firewalls en routering voor veranderen, als ergens een firewall op je route udp-verkeer naar poort 443 weigert kom je daar pas achter nadat het een tijdje is misgegaan :/

Ik ben verder heel benieuwd naar hoe Google het protocol laat werken in de huidige situatie. Want voorlopig kan je niet zomaar aannemen dat een server http/3 ondersteunt, wat dan worst-case betekent dat je een http/1 verbinding via tcp moet maken (net als nu met http/2) om er daarna pas achter te komen dat je ook http/3 had kunnen gebruiken.
gebruikers op Google services geen AES maar een Quantum Processor proof encryptie algoritme krijgen
Dat staat los van http/3. Ze hebben niks aan TLS (1.3) verandert. En je kan nu al bijvoorbeeld "elliptic curve" gebruiken; waarschijnlijk is je verbinding hier met Tweakers daar al mee.
Is toch volgens mij meer dan alleen dat, omdat ook meerdere bestanden via 1 aanvraag kunnen (tegelijk html, css, plaatjes, scriptfiles, etc).
Bedoel je via 1 aanvraag of via 1 verbinding?

Dat eerste zou een significante afwijking van de werking van http/1 en 2 zijn en kan ik me niet herinneren gezien te hebben. En dat 2e gebeurt al met http/2, maar wordt nu nog wel gehinderd doordat tcp alles netjes op volgorde wil. Bij udp/quic kunnen meerdere requests (min of meer) asynchroon per bestand via 1 "verbinding" verwerkt worden.
Dus niet bij Tweakers: PKCS #1 RSA-versleuteling (via Let's encrypt)
Het was en is me niet duidelijk waarom http/3 betere encryptie zou bieden dan http/2 aangezien beide in principe TLS 1.3 (kunnen) gebruiken.
Dus waarom http/3 dan bestand is tegen quantum computing en http/2 niet, zie ik niet.

Voor wat betreft onze ssl-configuratie. Als er iets verbeterd kan worden, horen we dat graag. Het is erg moeilijk hier fatsoenlijk leesbare documentatie over te vinden. Soms wordt aanbevolen welke ciphers je aan moet zetten, maar dan vaak niet waarom die ciphers wel en anderen niet. Of je moet maar raden wat het precies is/doet. Voor mij is het daardoor nog wel aardig wat abacadabra (voor Kees een stuk minder).

Een van onze manieren om te checken of onze SSL-config op orde is, is door de ssllabs-tester van Qualys uit te voeren. En die geeft ons een nette A+ (en google.nl een A).

Aan de hand van de output bij Qualys zie ik ook niet wat wij dan zouden missen. Kan je dat toelichten? En als je tips voor het aanpassen hebt, horen we dat natuurlijk graag.
De adoptie van http/2 gaat juist erg snel, en de ondersteuning is bijna perfect; (95% volgens caniuse.com).
Het geeft enorme snelheidswinst, en geeft een boost in de adoptie van https, omdat dat een vereiste is.
Dat HTTPS vereist was is al niet meer zo, al ondersteunen alle browsers h2c niet, voor tls terminating loadbalancer zoals haproxy is het wel fijn dat http/2 wel al gedecrypt is, maar wel als http/2 naar de backend wordt doorgestuurd

https://http2.github.io/faq/#does-http2-require-encryption
De site die je nu bezoekt wordt geserveerd met HTTP/2.0 ;) Grappig genoeg wordt cijfers.tweakers.net nog over HTTP1.1 geserveerd.

Als gebruiker merk je het vaak simpelweg niet.

[Reactie gewijzigd door Caayn op 26 september 2019 20:17]

Alle moderne browsers hebben op dit moment ondersteuning voor HTTP/2.
HTTP/3 is net als HTTP/2 een protocol door Google, voor Google (en andere soort gelijke internet reuzen). De gemiddelde website aanbieder haalt er niet veel voordeel uit. Het maakt het web complex en dus vatbaarder voor fouten. In plaats van het hele protocol op de schop te gooien te bate van hun eigen clouddiensten, had Google beter een eigen protocol kunnen klussen binnen websockets en de HTTP standaard daarmee simpel en eenvoudig kunnen houden voor partijen die al die complexiteit niet nodig hebben.
Hoezo heeft een gemiddelde website aanbieder geen voordeel bij HTTP/2 of HTTP/3? Meer snelheid is voor de conversie en SEO-optimalisatie van een website enorm gunstig. Daarnaast zorgt HTTP/3 voor minder requests wat dus ook minder trafic/belasting op servers betekend. Lijkt mij een redelijke win-win situatie.

Het lijkt mij eerder dat men het met HTTP/3 juist versimpelt. Want (als ik het goed begrijp) zit TLS als het ware ingebakken. Dat betekend een "laag" minder in het verkeer wat voor minder complexiteit zorgt.

[Reactie gewijzigd door n9iels op 26 september 2019 22:10]

Beter haal je je website door de hete was. Tegenwoordig krijg je regelmatig 2-3MB per pagina voor je kiezen, terwijl 0,5MB meer dan genoeg moet zijn.
Daar ben ik het zeker mee eens! Afbeelding verkleinen en comprimeren bijv. lijkt heel lastig te zijn |:( Maar dat verminderd niet het aantal requests tussen client en server :)
HTTP/2 is een flinke verbetering voor elke serieuze website. Waar ik vroeger nog aan het kutten was met keepalive instellingen om een webserver overeind te houden is dat met HTTP/2 en moderne threaded webservers geen probleem meer.
Helaas zitten er wel nadelen aan, het aantal bugs in HTTP/2 implementaties is fors geweest. Heb een tijd Apache met mod_h2 gedraaid, ben daar erg vaak tegen bugs aangelopen (cient compatibiliteit, geheugenlekken en DoS bugs waren nogal een probleem). Met nginx daarentegen geen enkel probleem.
Google is zo groot op het internet dat dit haast onvermijdelijk is. Als Google met http/3 efficiënter kan werken dan heeft dat wereldwijd een positieve uitwerking op de stikstofuitstoot van het internetgebruik. Als je zelf minder complexiteit nodig hebt kan je toch nog steeds http 1.1 gebruiken?
beter een eigen protocol kunnen klussen binnen websockets
Websockets hebben HTTP nodig. Jij stelt dus voor om een protocol bovenop websockets bovenop HTTP1.1 te maken. Kijk eens naar het artikel: HTTP/3 is significant sneller dan HTTP/1.1, omdat er minder berichten uitgewisseld moeten worden. Jouw voorstel levert een supertraag protocol op door het stapelen van al die lagen.
De voornaamste verandering bij de derde generatie van de http-specificatie is dat deze in plaats van tcp het door Google bedachte quic als transportprotocol gebruikt. Quic staat voor Quick UDP Internet Connections en werkt via udp. Het protocol brengt de communicatie tussen client en server om connecties op te zetten flink terug, met implementatie van tls 1.3 voor het realiseren van versleutelde verbindingen. Daardoor kunnen sneller verbindingen gelegd worden en verbeteren de latency en de beveiliging, zo is het doel.
Mij is altijd geleerd dat UDP geen foutcorrectie heeft (alwaar een boel tijdwinst zal zitten gok ik zo) en ik kan mij voorstellen dat data dat over het internet gaat een hogere 'failure rate' heeft en foutcorrectie dus soms wel nodig is. Hoe gaat dit dan afgevangen worden in http/3?

[Reactie gewijzigd door CH4OS op 26 september 2019 22:30]

Quic kan gebruik maken van Forward Error Correction. In dat geval worden de datapakketjes allemaal iets groter, omdat in elk pakketje een stukje redundantie zit over het vorige.
Vergelijk met raid5: 3 schijven waarvan je er 2 moet hebben. Ik stuur ze je over de post. De post had eerst hele langzame maar betrouwbare bakfietsen. De bezorger verloor weleens een pakket onderweg, maar zag dat altijd en raapte het op en ging verder (TCP, hoewel het in werkelijkheid iets anders gaat, maar dit is beter voor het verhaal).
De bakfietsen waren klein (weinig bandbreedte, modems/adsl) dus stuurde je liefst zo weinig mogelijk.

Nu rijden met de nieuwste electrische bussen, van 0 tot 100 in een milliseconde en grote laadbakken. Dus stuur je in elke bus zo'n raid-schijf en komt er dan eentje niet aan, dan is er nog niks aan de hand.

Ook dit is erg versimpeld natuurlijk, in het echt heeft elk pakketje een beetje van deze data. Iets grotere pakketjes maar door de enorm lagere latency werkt alles veel sneller.

Maar misschien heeft http3 nog wel meer dingen ingebouwd. Quic kan van zichzelf dit in elk geval ondersteunen. Maar ik durf niet te zeggen of dit nu al gebeurd of dat er iets anders gebruikt wordt. Ik kan daar nog niks concreets over vinden.
UDP heeft inderdaad geen eigen foutcorrectie. Ook het concept van een 'verbinding' bestaat niet bij UDP.
Alle berichten zijn effectief 'fire and forget' en je moet maar hopen dat er iets terug komt.

Als je dat toch nodig hebt, dan zal je dat dus zelf moeten implementeren.

In theorie zou je simpelweg het TCP-protocol in de applicatielaag van beide zijden van die 'UDP-verbinding' kunnen implementeren. Het aantal packets en de momenten waarop die verstuurt worden verandert dan weinig aan, er staat alleen in de package-header dat het een udp- ipv tcp-packet is. Maar dan zit je natuurlijk met de relatief ouderwetse manier van werken daarvan.

Google wilde dus een actuele vervanger met ruwweg de functionaliteit van TCP maken, maar kon op IP-niveau niet zomaar een helemaal nieuw protocol introduceren. Dan zit je helemaal met veel gedoe bij routers en firewalls.
Daarom hebben ze deze 'hack' toegepast; door die vervanger voor TCP te implementeren via UDP-packets.

Bijkomend voordeel is dat ze het precies-pas kunnen maken voor HTTP, groot nadeel is dat het van de OS-laag (of zelfs de netwerk-interface) 'omhoog' gaat naar de applicatie-laag.
Eindelijk! Gaaf dat nu niet alleen Google Ads over Quic de TLS handshake zullen doen, maar gaandeweg andere sites dit nu ook kunnen doen.

Ben er al mee bezig sinds begin 2015, dus het wordt hoog tijd. Ook zit er een soort trust in het protocol, als je al eerder een handshake hebt uitgewisseld en je bezoekt de site na een tijdje opnieuw, dan is de dialoog korter.

Scheelt dus veel tijd voor het serveren van de eerste bytes (meer dan 100-200ms), waardoor de internetpagina's sneller en eerder op je scherm zullen staan. Ook aanspreken van API's zal daardoor snellere responses geven, zeker als je een API minder dan 1x per 10 minuten raadpleegde zal het verschil in response tijd duidelijk merkbaar zijn.

Tijd om cloud providers wakker te schudden (als je geen CloudFlare hebt). Voor Microsoft IIS moest voor HTTP/2 een wijziging in het core OS worden gedaan, hopelijk voor HTTP/3 niet :-)

[Reactie gewijzigd door djwice op 26 september 2019 21:12]

Voor Microsoft IIS moest voor HTTP/2 een wijziging in het core OS worden gedaan, hopelijk voor HTTP/3 niet :-)
Gezien IIS niet zijn eigen TLS implementatie heeft, reken er maar op dat er een update voor Windows zelf moet komen.
Dan komt dit waarschijnlijk pas in een Windows Server versie na 2019. Volgens mij heeft Microsoft nooit mogelijkheden aan http.sys toegevoegd in een reeds bestaande versie van Windows Server.
Misschien leuk om te weten dat Cloudflare en Mozilla de Rust programmeertaal gebruiken voor hun HTTP/3 en QUIC implementaties :) Dit zijn bovendien losstaande 'crates' dus hopelijk relatief eenvoudig te gebruiken in andere projecten.

[Reactie gewijzigd door jandem op 26 september 2019 20:36]

Cool! Een lijst met andere Quic implementaties vindt je hier https://github.com/quicwg/base-drafts/wiki/Implementations
Over quic heb ik wel eens eerder gelezen. Het idee is goed, maar in tegenstelling tot de overgang van HTTP/1.1 naar HTTP/2 zal er mogelijk meer geleund moeten worden op backwards compatibility. Een probleem in veel (bedrijfs)netwerken is dat UDP verbindingen niet zijn toegestaan of op een andere manier worden beperkt.

Op dit item kan niet meer gereageerd worden.


Apple iPhone 11 Nintendo Switch Lite LG OLED C9 Google Pixel 4 FIFA 20 Samsung Galaxy S10 Sony PlayStation 5 Elektrische auto

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2019 Hosting door True