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.

​

Reacties (88)

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.

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.

Is toch volgens mij meer dan alleen dat, omdat ook meerdere bestanden via 1 aanvraag kunnen (tegelijk html, css, plaatjes, scriptfiles, etc).

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.

Dus niet bij Tweakers: PKCS #1 RSA-versleuteling (via Let's encrypt)
Wel bij bijv. https://google.nl

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.

Een goede uitleg over QUIC is hier te vinden:
https://ma.ttias.be/googl...tocol-moving-web-tcp-udp/

Als ik het goed heb is de handshake en handshake cache anders dan nu bij TLS. Met name het sneller opnieuw opzetten na een eerder vertrouwde verbinding is nieuw. En dat dit over UDP gebeurd dus je dit niet apart voor welke (parallelle) verbinding met de site hoeft te doen.

Elliptische curves zijn niet de argoritmes waar ik op doel. En het klopt is niet HTTP/3 specifiek, ik doelde op de manier van testen; hoe Google dat ook met Quic heeft gedaan.

Je kunt in Chrome in de info pagina's meer details vinden over je connecties, ook de Quic die je nu opbouwd.

Er is vast net zoals met http/2 een cliënt header, zodat de server weet wat ie kan doen. UDP heeft sowieso minder aankomst garantie en is dus lichter dan TLS. Fallback is gewoon http/2.

HTTP/2 heeft al dat je meerdere requests in 1x kunt sturen, de server kan push request doen en dan een reply van de browser krijgen welke files al in de browser cache staan. Waarna de server meerdere files in 1x achter elkaar over de verbinding terug stuurt. Denk bijvoorbeeld aan request voor homepage, server vraagt of CSS en images in cache staan en stuurt daarna in 1x alleen de missende files.
Doet de Tweakers server dat ook?

[Reactie gewijzigd door djwice op 27 september 2019 18:56]

Onze site werken de afbeeldingen niet bij http/2 icm Safari. Nog nooit echt onderzocht waarom, binnenkort toch maar eens doen als het zoveel impact kan hebben!

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/2 is eigenlijk een beetje een tussen versie. De problemen die opgelost zouden moeten worden zijn eigenlijk niet helemaal opgelost. Omdat dat in combinatie met TCP niet kan. Wat nu nog geen HTTP/2 ondersteunt zal het waarschijnlijk simpelweg skippen. Zodat we straks alleen nog HTTP/1 en HTTP/3.

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

Met CSS Sprites kun je het aantal requests een beetje verminderen.

Dat werkt leuk voor achtergrondafbeeldingen als je je site zelf beheert. Mijn klanten gaan dat niet kunnen / willen doen. Zij willen snel met drag and drop hun media uploaden, de rest moet gewoon werken en vanzelf gaan. (Terecht ook)

Maar ook dat superveel op Wordpress draait, terwijl als je de pagina's daarvan goed omzet naar statisch, dan is de serverload 1/50ste of minder. Standaardinstellingen van WP zijn een gruwel, een Raspberry Pi kan misschien 1 pagina per seconde genereren.

case in point: de perfecte website

Shit's legible and gets your fucking point across (if you had one instead of just 5mb pics of hipsters drinking coffee)

Exact waar ik me al tijden enorm aan erger. Steeds meer sites worden zo omdat het zo hip is maar het geeft geen identiteit. Het geeft me ook niet echt vertrouwen in zo'n bedrijf, als je alleen maar met uiterlijk bezig bent...

Bijna, hij is de leesknop vergeten te activeren. Kun je zijn font overrulen in leesmodus.

"Maar wij leven toch niet meer in het inbel-tijdperk...", even vergeten dat mensen nog steeds op ADSL zitten en die maar 300kbps halen.. Dus, eens. Optimaliseren moet nog steeds kunnen.

Snelheid, snelheid en snelheid. Dat is het enige waar mensen in geinteresseerd zijn. Stabiliteit en veiligheid boeit niemand wat. We bouwen troep, proppen website vol met libraries waarvan we nog geen 10% gebruiken en zijn dan blij met een nieuwe HTTP standaard om onze rotzooi weer snel te krijgen. De omgekeerde wereld.

Wil je als website-eigenaar snelheid, stop dan eens met het gebruiken van gedrochten als Wordpress, Drupal en Joomla. Daarnaast, HTTP/1 is makkelijk een stuk sneller te krijgen door request pipelining aan te zetten, maar dat doen we niet omdat er imcompetente webproxy bouwers zijn waardoor dat misgaat.

TLS zit niet anders in HTTP/3 dan in HTTP/1. En al zou het meer in HTTP/3 zitten, dan nog is er configuratie nodig om het werkend te krijgen. TLS is ooit een magisch iets dat je met een simpele knop aan kan zetten en dat het dan werkt. HTTP/3 maakt TLS dus niet simpeler.

[Reactie gewijzigd door Faeron op 28 september 2019 13:33]

Oke ik ga hier even offtopic, ben ik mij dus zeker bewust van. Ik vind de redenatie dat je voor snelheid "gedrochten als Wordpress, Drupal en Joomla niet moet kiezen" nogal vreemd. Wellicht dat dit ~5 jaar geleden het geval was, maar vandaag de dag zijn deze systemen in de basis gewoon heel erg goed. Als je ze vol hangt met 10 extensies/plugin/uitbreiding van obscure ontwikkelaars vraag je uiteraard om problemen. Maar als je deze systemen gebruikt waarvoor ze gemaakt zijn en netjes op door bouwt volgens de aangeleverde patterns kan is het bloedsnel.

Wellicht dat jij deze ervaring een lange tijd geleden hebt opgedaan toen het ook nog gewoon een rotzooi was. Ik raad je in dat geval echt aan om er nog eens naar te kijken, je zult zien dat er echt dingen sterk zijn verbeterd.

Weer even terug on-topic, ik denk dat het grote voordeel van HTTP/3 hem gewoon zit in het verminderen van requests. Het aantal internet aansluitingen en apparaten die data versturen groeit enorm en zal dit blijven doen. Je moet op een manier druk van de ketel afhalen om ook in de toekomst alles snel en vlot laten te verlopen. Verder vraag ik mij af welke beveiligingsproblemen jij bij HTTP/3 ziet, daar heb ik zelf namelijk nog niks over gelezen (zit ook niet zo diep in de materie moet ik zeker toegeven).

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.

Kutten met instellingen van een webserver is een implementatie-issue, geen protocol-issue. Ik heb met mijn webserver nog nooit hoeven kutten met dat soort instellingen om het goed werkend te krijgen.

Bij HTTP/1.1 was je volledig afhankelijk van KeepAlive om de boel een beetje snel te krijgen, al helemaal met de overhead van SSL. Bij HTTP/2 is die overhead voor een groot deel verdwenen, kunnen er meer requests tegelijk over 1 verbinding en is keepalive niet meer belangrijk.
Bij Apache liep je dan al vrij snel tegen het max aantal connecties aan.

Dus? Dat werkte toch? Wat vooral een probleem is dat request pipelining niet standaard aanstond, omdat incompetente webproxy bouwers dat niet begrepen. Daardoor behaalde niemand de maximale snelheid met HTTP/1.

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.

Nee, websockets hebben HTTP nodig voor de initializatie. Daarna is het een binair protocol geworden, waarbij HTTP niet meer gebruikt wordt.

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.

Als ik het goed begrijp is TCP vervangen door QUIC, wat vervolgens op UDP is gebouwd. QUIC zorgt daarmee dus voor de foutafhandeling waar dit bij HTTP/2 nog door TCP werd gedaan. Met TCP is het nu zo dat een connectie gebruikt kan worden voor meerdere streams. Als één van deze streams een fout heeft gaat de hele connectie op slot. Bij QUIC gaan de andere streams gewoon door en vind foutcorrectie plaats op die ene stream. De kans op fouten door UDP wordt dus niet zozeer verkleind, maar de foutafhandeling is efficiënter gemaakt.

Disclaimer, dit is volledig geschreven met info van Wikipedia op een donderdag avond

TCP is de tegenhanger van UDP dat wel foutcorrectie heeft (en dan inderdaad alles opnieuw laat doen), QUIC is dan waarschijnlijk gebouwd om te werken binnen het UDP-protocol, een andere OSI-laag dus, dat is althans ook wat ik opmaak uit het verhaal van @vrow.

"een andere OSI laag". Nee. Het OSI model is primair een theoretisch model, en de IP familie van protocollen trekt zich weinig aan van de OSI theorie. HTTP/1.1 over TCP over IP zijn 3 protocollen die volgens OSI in twee layers zouden moeten passen (Transport/Session). HTTP/3 over QUIC over UDP over IP zijn zelfs 4 protocollen in 2 lagen.

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.

is het niet handmatig te implementeren?.. met een library of zo als je toch al ASP.NET draait om je website te hosten?

Niet als je host via IIS, want in de kern gebruikt IIS http.sys om SSL en http listeners te gebruiken en dergelijke. Als je alles zelf doet, inclusief het opbouwen van de verbinding, kan je natuurlijk doen wat je wilt, je bepaald zelf wat je over een socket heen zet.

Volgens mij heeft Microsoft nooit mogelijkheden aan http.sys toegevoegd in een reeds bestaande versie van Windows Server.

Onwaar.

Dat zit niet in http.sys maar in de crypto provider

I stand corrected. Het klopt dat bijvoorbeeld Windows 7 nooit HTTP/2 ondersteuning heeft gekregen, waardoor zelfs IE 11 op Windows 7 het niet heeft. Zie ook dit.

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

En google C en C++ voor Chromium *mindblown*. Nee maar had jij van Mozilla iets anders verwacht dan?

Beter gebruik je quinn: https://github.com/djc/quinn / https://crates.io/crates/quinn
quinn gebruikt rustls, wat een native en moderne (zonder legacy protocollen) tls implementatie is. quinn bestaat ook langer dan neqo als ik mij niet vergis.

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.

Naast dat http/2 en http/3 alleen in browsers werken, lang niet alle componenten die gebruikt worden door native software en gebruik maken van webservices hebben daar ondersteuning voor.

Een probleem in veel (bedrijfs)netwerken is dat UDP verbindingen niet zijn toegestaan of op een andere manier worden beperkt.

Nooit van gehoord. De reden om Quic op UDP te bouwen, in plaats van een nieuw protocol te ontwikkel als Transport Layer is juist dat UDP al massaal ondersteund wordt. Maar evenwel verwacht ik dat servers tot in lengte van dagen compatibel blijven met HTTP/1.1 als "fallback" voor als de browser geen nieuwere versie ondersteund, en andersom.

The Zep Man heeft het over firewalls en dergelijke die niet zomaar alle verbindingen toestaan. In een goed beveiligd (bedrijfs-)netwerk kun je overigens überhaupt niet direct naar buiten verbinden en moet dat via een proxy server.

Een streng afgestelde firewall zal wellicht geen UDP toelaten op poorten 80 en 443

En het is technisch mogelijk om UDP af te knijpen ivt TCP, wat zeker als er normaal gesproken weinig UDP-verkeer hoort te zijn. Dan kan je daarmee misschien wat overlast van bijvoorbeeld games die niet gespeeld horen te worden.

Beter ff widespread MPTCP support

Super gaaf dat grote bedrijven hiermee aan de slag gaat. En heel goed dat, net als bij HTTP/2, een versleutelde verbinding de standaard is. Sterker nog, een website over een niet-versleutelde HTTP verbinding binnen halen kan nog geen eens met deze protocollen. Ik merk nu al dat een niet HTTPS website vinden best lastig is, maar in de komende jaren zal dat onmogelijk worden.

Daarnaast denk ik dat de vermindering van het aantal requests ook echt nodig is. Naast een betere performance bespaart het simpelweg ook bandbreedte, resources en daarmee elektriciteit. Over dat laatste durf ik het niet met zekerheid te zeggen, maar het lijkt mij dat als bijv. een heel serverpark HTTP/3 gebruikt je in theorie een daling in stroomverbruik zou moeten zien.

[Reactie gewijzigd door n9iels op 26 september 2019 21:38]

Dat niet kunnen vinden van niet HTTPS is een behoorlijk probleem. Er is enorm veel nuttige info van een paar jaar terug die niet HTTPS wordt aangeboden. Google en co verbannen deze geweldige content naar pagina 30 en verder, als ze het al helemaal niet uit de analen verwijderen, en resultaat is dat anno 2019 meer nuttige info op het internet verdwijnt dan erbij komt. HTTPS heeft de grote portalen groter gemaakt, en de kleine informatieve website weggejaagd.

[Reactie gewijzigd door blanka op 26 september 2019 23:04]

Dat heeft eerder met de Google zoekmachine te maken van het HTTP protocol. Als Google gaat discrimineren, om het zo te noemen, op basis van protocol krijg je helaas dat effect. HTTP zal altijd backwards compatible blijven voorlopig, dus oude content blijft inzichtelijk. Hoe Google erop reageert is aan hun.

Wikipedia grossiert inmiddels in dode referenties, dus ergens gebeurt er iets van:
Niemand komt meer op mijn pagina, omdat Google mij naar pagina 30+ verbannen heeft, en daarom zeg ik mijn hosting maar op, en dus is er weer een stukje informatie op het net verdwenen.

Het mooie van quic is dat het geen last heeft van het switchen van netwerk of ipadres. Een ssh implementatie hiervan is https://mosh.org/
Klap thuis je laptop dicht, in de trein of op kantoor weer open, en je ssh verbinding leeft nog. Over brakke verbindingen werkt het ook veel beter dan een traditionele ssh verbinding.