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.
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.

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 Televisies

'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