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
×

Tweakers Awards 18/19

Wat vind jij de beste tech- en elektronicaproducten van het afgelopen jaar? De Tweakers Awards stembussen zijn nog drie dagen open. Laat je stem gelden en ontvang 50 ippies. Bovendien maak je kans op een Sony PlayStation 4 Pro 1TB, GoPro Hero 7 of Sonos One.

Stemmen

Http/3 gaat Googles http-over-quic in plaats van tcp gebruiken

De Internet Engineering Task Force heeft Googles http-over-quic gekozen als netwerkprotocol voor http/3, de opvolger van het huidige http/2. Daarmee wordt de komende http-versie niet op tcp gebaseerd.

IETF-leden hebben hun goedkeuring gegeven aan het voorstel dat http-over-quic wordt hernoemd naar http/3 en dat de ontwikkeling door de QUIC Working Group wordt overgenomen door de HTTP Working Group. Het is de tweede keer dat door Google ontwikkelde technologie het tot http-standaard schopt. De http/2-standaard uit 2015 bouwde voort op Googles spdy-protocol.

Quic staat voor Quick UDP Internet Connections en werkt via udp. Het protocol zorgt ten opzichte van tcp voor aanzienlijk minder round trips die nodig zijn om een connectie tussen client en server te bewerkstelligen. Het opzetten van beveiligde ssl-verbindingen levert bij tcp bijvoorbeeld een flinke toename op van het aantal requests en antwoorden. Bij http-over-quic is ssl standaard geïmplementeerd en de huidige versie maakt gebruik van het nieuwe tls 1.3.

Door de afname van het aantal onderhandelingen tussen client en server verbetert http-over-quic de netwerklatency en kunnen webpagina's sneller laden. Http-over-quic is de implementatie van quic in het http-protocol, zoals Google die in juli 2016 als ontwerp-standaard in 2016 bij de IETF voorstelde.

Onder andere Chrome, Opera en Googles servers ondersteunen quic al. Daarnaast is Facebook begonnen met de adoptie, schrijft ZDNet.

Door Olaf van Miltenburg

Nieuwscoördinator

14-11-2018 • 09:58

135 Linkedin Google+

Submitter: Muncher

Reacties (135)

Wijzig sortering
Als SSL standaard geïmplementeerd is en er zou dan een vulnerability geconstateerd worden, leidt dat dan tot een patch op http/3 en alle applicaties die dat gebruiken of tot een patch op het OS? Beter gezegd, wat is het effect?

[Reactie gewijzigd door oef! op 14 november 2018 10:06]

Ik zou verwachten dat de patch moet toegepast worden op een library of framework dat gebruikt wordt door de applicaties die draaien op het OS.

Applicaties gaan normaal niet telkens het wiel opnieuw uitvinden. Maar wel dus gebruik maken van een gedeelde component. Het zou wel kunnen dat die gedeelde component in het OS geïntegreerd wordt.

Er komt dus een extra laag bij. Eéntje die zich situeert tussen UDP en de applicatie. In de oude/huidige manier bevond die laag zich tussen TCP en de applicatie. Een goed voorbeeld daarvan is dit: https://curl.haxx.se/libcurl/

Op je firewall moet je misschien wel iets aanpassen. Want het nieuwe http-verkeer verloopt niet meer langs TCP poorten 80 en 443 zoals dat gebruikelijk was. Proxy's en webfilters hebben ook aanpassingen nodig, net zoals antivirussoftware die http-verkeer scannen.
QUIC is UDP/443 dus portforwarding/nat/firewalling etc. moet hiervoor ingericht worden.
Het is iets ingewikkelder dan dat. Een essentieel verschil tussen TCP en UDP is dat je met TCP verbindingen opzet. Je NAT oplossing kan TCP verbindingen uniek identificeren, en van elke verbinding de TCP poort afzonderlijk herschrijven. Daardoor kun je met 2 webbrowsers achter een NAT naar dezelfde website surfen, zonder dat die zaken door elkaar lopen.

UDP heeft geen verbindingen. Elk pakketje is afzonderlijk geaddreseerd. Hoe moet je nu die pakketjes uit elkaar houden als NAT gateway? Daarvoor moet je complexere oplossingen inzetten, zoals STUN.
UDP heeft geen verbindingen. Elk pakketje is afzonderlijk geaddreseerd. Hoe moet je nu die pakketjes uit elkaar houden als NAT gateway? Daarvoor moet je complexere oplossingen inzetten, zoals STUN.
Met dat laatste ben ik het echter niet akkoord. Ook zonder STUN kunnen UDP-bron-poortnummer herschreven worden zodat er altijd unieke "verbindingen" kunnen onderscheiden worden. ("Verbindingen" in de zin van twee eindpunten die regelmatig met elkaar pakketjes uitwisselen.) STUN is noodzakelijk wanneer beide server en client zich achter een NAT gateway bevinden omdat geen van beide in dat geval een inkomende verbinding kan accepteren. Dit omdat er enkel een "verbinding" kan gemaakt worden als de client (met intern IP) als eerste contact zoekt met de server. Enkel op dat moment kan de NAT gateway een "verbinding" registreren omdat het bij een inkomende verbinding niet kan nagaan naar welk intern IP het pakket moet gestuurd worden. Tenzij natuurlijk iemand daarvoor een portforwarding regel heeft aangemaakt of eventueel automatisch via UPnP. Ok, Maar dan wordt het al wel héél ingewikkeld.

Vergeet ook niet dat het UDP-protocol zelf geen verbindingen en zelfs geen betrouwbare transport aanbied. Maar dat deze zaken in de hoger gelegen laag nog wel geïmplementeerd kunnen worden. In dit geval zal dat ook zeker gebeuren want betrouwbare overdracht van de data is wel gewenst in het geval van HTTP-(web)-verkeer.
Op dezelfde manier als TCP verbindingen. De Sourceport kan nog steeds gevarieerd worden.
Maar laten we wel zijn: NAT is een Kludge om max een 10tal bits aan de IP address space toe te voegen.
Verder is NAT nutteloos.
Vergeet NAT om het goed te doen en gebruik IPv6 dan is dat uberhaupt geen issue meer.

STUN is nodig bij SIP omdat in het SIP protocol het PUBLIC adres voor de RTP link moet worden opgegeven. Dat is voor 1:1 verbindingen niet nodig. Dat is ook het issue van FTP vs. SFTP (SCP).
Portfowarding en NAT limiteren inkomende verbindingen. Je browser zal echter een uitgaande verbinding moeten leggen met de server. In principe zou het dus moeten werken met een standaard setup.

Maar indien je een server draait/wil draaien heb je wel een portforwarding nodig voor de UDP poort 443, die niet dezelfde is als de TCP poort 443, dus moet men daar even bij nadenken.
Een firewall gaat ook normaal niet direct UDP poort 443 blokkeren, maar iemand die heel beveiligingsbewust is zou die poort eventueel wel geblokkeerd kunnen hebben. Bvb om P2P verkeer tegen te gaan. Er zijn allicht mensen die een software firewall gebruiken op hun toestel. Ik zou dus zeker uitkijken naar updates daarvoor want die kunnen best wel eens zulk verkeer blokkeren.
Je hebt meestal met NAT te maken..., maar mensen die services aanbieden om welke reden dan ook zullen NAT moeten opzetten voor IPv4, IPv6 natuurlijk niet.
Zoals ik het lees: met http/3 bestaat er geen "plain" http meer. Alle verbindingen zijn encrypted, anders kun je geen http/3 verbinding maken. Ze hebben gekozen om alleen de meest recente standaard te ondersteunen, als minmium. Maar ze sluiten daarmee niet uit dat ook in de toekomst nog nieuwere standaarden ondersteund kunnen raken. Dat zal wel patching betekenen, want dat moeten zowel servers als client natuurlijk dan ook gaan ondersteunen.

Overigens is een kans op een kwetsbaarheid in de hele standaard onwaarschijnlijk*:

Wat eerder mogelijk is, zoals bijvoorbeeld nu ook al bij TLS1.2 het geval is, is dat voor bepaalde cryptografische methoden binnen de standaard blijkt dat er een kwetsbaarheid in zit, of dat deze als 'zwak' worden beschouwd. Een voorbeeld is 3DES-algoritme, dat is eigenlijk te zwak met een te kleine sleutelgrootte, waardoor het theoretisch gekraakt kan worden bij grote hoeveelheden onderschepte daa.

Ook als er binnen TLS 1.3 kwetsbaarheden worden ontdekt, zal het voor beheerders vooral een kwestie zijn van support voor die kwetsbare algoritmes uit te schakelen. Net zoals je nu als het goed is als support voor weak ciphers uitschakelt.


*Ff extreem kort door de bocht: de standaard is "we communiceren veilig door middel van cryptografie, en wel door deze verzameling van technieken en mechanismes". Wat je vervolgens ziet is dat in de implementatie en is sommige van de technieken kwetsbaarheden zitten. Alhoewel SSLv3 wel echt volledig kwetsbaar is. Zet ondersteuning hiervoor alsjeblieft uit waar het kan.
Zelfs http/2 vereist de facto encryptie tijdens het transport. Hoewel het niet in de http/2 standaard is opgenomen (wel in spdy waarop het gebasseerd is) hebben alle browsermakers beslist om geen unencrypted http/2 toe te staan.
SSL/TLS zat al niet in de kernel.. dus wat dat betreft veranderd er weinig.
Als SSL standaard geïmplementeerd is en er zou dan een vulnerability geconstateerd worden, leidt dat dan tot een patch op http/3 en alle applicaties die dat gebruiken of tot een patch op het OS? Beter gezegd, wat is het effect?

Als er een kwetsbaarheid gevonden wordt in TLS 3.0, dan verandert er niet zo heel veel. Applicaties die de eigen HTTP/TLS stack gebruiken zoals Chrome komen met een update. Dat moeten ze nu ook al, want ze dragen de TLS stack ook mee.

Applicaties die de OS stack gebruiken voor HTTP/QUICK (zoals Edge op .Net applicaties op Windows) vereisen een Windows Update patch, waarna ze weer beschermd zijn. Precies zoals nu waar Microsoft de TLS stack een update geeft.
Maar UDP is eigenlijk 'fire-and-forget' en geeft geen garantie geeft dat een datagram aankomt, waar TCP een ACK teruggeeft zodat je weet dat het ontvangen is. Hoe kan UDP dan betrouwbaar worden ingezet voor HTTP?
Van Wikipedia:
QUIC uses UDP as its basis, which does not include error correction. Instead, each QUIC request is separately multiplexed and error corrected at the level of the QUIC driver, not the underlying transmission protocol. In addition to providing error correction, like TCP, QUIC's data also includes packet routing information that allows it to be multiplexed at the protocol layer. This means that if an error occurs in one stream, like the favicon example above, the protocol stack can continue servicing other streams independently. This can be very useful in improving performance on error-prone links, as in most cases considerable additional data may be received before TCP notices a packet is missing or broken, and all of this data is blocked or even flushed while the error is corrected. In QUIC, this data is free to be processed while the single multiplexed stream is repaired.
Om te zeggen zelfde als TCP is erg kort door de bocht. QUIC lijkt dus juist grote voordelen te hebben op onbetrouwbare verbindingen, omdat i.t.t. TCP errors afgehandeld kunnen worden zonder dat de verbinding onderbroken wordt.

[Reactie gewijzigd door Niet Henk op 14 november 2018 10:22]

Een meer grafische weergave hier.
Maar UDP is eigenlijk 'fire-and-forget' en geeft geen garantie geeft dat een datagram aankomt, waar TCP een ACK teruggeeft zodat je weet dat het ontvangen is. Hoe kan UDP dan betrouwbaar worden ingezet voor HTTP?
Omdat in QUIC zelf een soort van TCP protocol zit ingebakken dat beter/sneller is dan het huidige (verouderde) TCP protocol. Door UDP te gebruiken heb de snelheidswinst en backwards-compatibility op alle netwerk apparaten.
Bedankt voor je antwoord, interessant! Ik heb ernaar gezocht en kwam de volgende spec tegen:

IETF draft: QUIC Loss Detection and Congestion Control

Hier noemen ze ook de verschillen tussen QUICK en TCP :)

[Reactie gewijzigd door P1nGu1n op 14 november 2018 10:17]

Hoe kan UDP dan betrouwbaar worden ingezet voor HTTP?
Op dezelfde manier als TCP dat regelt..
Met een ACK? Dat doet UDP niet. Kan je je antwoord misschien verduidelijken?
IP is by design een Best Effort netwerk. Dat betekent dat het een "fire-and-forget" principe hanteert. TCP is een laag bovenop IP (laag 3 in het OSI model) die in de gaten houdt of een bericht wel aankomt, en het anders opnieuw probeert. Maar als je dat niet in de eerste laag doet (lees, UDP) gebruikt, kun je dat nog steeds in de volgende laag doen. In dit geval verwacht ik dat de controle van laag 4 (TCP/UDP) naar laag 7 (HTTP/2 / HTTP/3) verhuist.
QUIC is een transport layer (i.i.g. volgens Wikipedia), dus is laag 4.

Dat deze een andere transport layer gebruikt maakt het wel wat verwarrend.

Dat er gezegd wordt dat dit TLS vervangt, is gewoonweg incorrect. QUIC wordt beveiligd met TLS, en TLS wordt dus verplaatst van laag 7 naar laag 4, en hierdoor kan een snelheidswinst geboekt worden (zie de IETF draft over beveiliging van QUIC).

QUIC vervangt dus TCP voor HTTP verkeer, niet TLS. En omdat TLS direct met QUIC toegepast kan worden, is het niet meer nodig om TLS in de application layer toe te passen. Je hebt dus HTTP verkeer over QUIC, in plaats van HTTPS verkeer over TCP.

Tenminste, da's zover ik het begreep
QUIC integreert TCP, TLS en HTTP in één, het vervangt dus niet alleen TCP.
Nee, dat is gewoonweg niet correct.

QUIC is een transport layer. Deze layer ondersteund transport layer security (TLS) met o.a. 0-rtt, en is geoptimaliseerd voor HTTP verkeer.

HTTP-over-QUIC is een toepassing van QUIC, welke dus hernoemd is naar HTTP\3. Deze integreert QUIC en HTTP.

QUIC doet niks met TCP, maar ondersteund enkel UDP. HTTP-over-QUIC ook niet. Bij een toekomstige webserver zullen waarschijnlijk oudere versies van HTTP(S) ondersteund worden, en is het aan de client om te kiezen of hij een TCP verbinding met HTTPS wilt, of een HTTP\3 verbinding.

QUIC vervangt natuurlijk enkel TCP voor verbindingen naar HTTP\3 websites (en andere toepassingen die besluiten QUIC te gebruiken).

Tevens is voor QUIC TLS dus optioneel. In Opera zijn het zelfs twee flags, opera://flags/#enable-quic en opera://flags/#enable-quic-https, waarbij die tweede een iets verkeerd gekozen naam heeft (zou quic-tls en niet quic-https moeten zijn).

QUIC integreert niet TCP, het vervangt het. Het doet niks met TCP. En of het TLS vervangt... Als ik zo'n kopje met ingebouwde lepel gebruik, worden niet ineens lepels vervangen, ik heb gewoon de lepel al in mijn kopje zitten en hoef dus niet zelf over lepels na te denken.

[Reactie gewijzigd door Niet Henk op 14 november 2018 11:50]

QUIC doet niks met TCP, maar ondersteund enkel UDP
Dat zegt Olaf ook niet, hij zegt dat het TCP integreert, als in, het biedt hetzelfde gedrag als TCP doet (continuë streams ipv losse pakketjes), met nog een hele boel andere zaken (zoals meerdere streams ipv 1 per verbinding, TLS ingebouwd, etc.). Het is in feite gewoon een verbeterde versie van TCP.

Dat het layert op UDP heeft gewoon te maken met legacy. Als het direct een IP protocol zou zijn dan moeten er heel veel devices geüpdatet worden om QUIC te ondersteunen. Door UDP te gebruiken voorkom je dat gedoe. QUIC gebruikt UDP gewoon zoals TCP ook IP gebruikt.

[Reactie gewijzigd door .oisyn op 14 november 2018 14:07]

Waarom is het dan sneller vraag je je af? Als er een pakketje mist moet dat alsnog terug worden gecommuniceerd en opnieuw verzonden...
Ja, goede vraag. Waarschijnlijk is TCP verouderd. UDP is ook verouderd, maar zo'n dunne laag dat het weinig vertraging oplevert. Door een modernere techniek op een hogere laag toe te passen heb je veel minder last van UDP dan van TCP denk ik.
TCP is helemaal niet verouderd.
Dat heeft er niets mee te maken.

Engineering is een trade-off. Je moet altijd keuzes maken. Kies ik oplossing A, dat in geval X beter werkt, of oplossing B, dat in geval Y beter werkt ? Kies ik er voor om oplossing C her te gebruiken, die al bestaat, of kies ik voor oplossing D, die bloedjenieuw is ?

TCP was bedoeld voor file-transfers. Veel data. Veel pakketjes. Proberen de optimale bandbreedte te vinden, zodat je je grote hoop data zo snel mogelijk over kon pompen. Maar het web is anders. Dat zijn geen grote files. Dat zijn heel veel kleine files. Dan is de overhead om de verbinding op te zetten relatief duur. En het opzetten van de TCP verbinding gebeurd *voordat* de applicatie (je browser en de webserver) zelf zijn verbinding opzetten (lees: certificaten en keys uitwisselen). En dan moet het uiteindelijke web-request en het antwoord nog worden gestuurd.

Zoals je ziet, 3 stappen. Voor iedere stap worden minstens twee pakketjes gestuurd. Het plaatje bij het artikel suggereert zelfs dat er 4 stappen zijn. Dat is 4x RoundTripTime. Wat Quic doet is alle vier die stappen in een stap stoppen. Dan heb je nog maar 2 pakketjes nodig. En 1x RTT.

Je zult zien dat Quic veel sneller is voor kleine web-objecten. Maar als je grote dingen gaat downloaden via Quic (films, audio, grote files), dan zul je zien dat Quic niet sneller is dan HTTP/TCP.

[Reactie gewijzigd door gryz op 14 november 2018 13:18]

Okay, TCP is niet verouderd, de use-case voor TCP is verouderd (er is een nieuwere bijgekomen). Bedankt voor de uitleg!
Het is vooral de hogere laag die 't 'm doet: doordat het QUIC-protocol meer informatie heeft over wat er verstuurd wordt, kan dat gebruikt worden om de beveiliging op de toepassing aan te passen. Een voorbeeld: waar TCP probeert de pakketjes in volgorde te sturen en af te leveren, is dat bij QUIC niet altijd nodig — zolang de afbeelding maar in elkaar gepuzzeld wordt, maakt het niet uit in welke volgorde de stukjes komen en of de CSS eerder of alter aankomt. Ook heeft QUIC meer ruimte voor verschillende soorten bevestiging van pakketjes — wederom omdat er meer kennis is.

Daarnaast worden er gegevens uitgewisseld bij het maken van een verbinding waardoor de volgende verbinding niet een nieuwe handshake nodig heeft, wat de nieuwe verbinding ook sneller maakt.

Ik zou daarom niet zeggen dat TCP verouderd is, per se. Het is robuust en makkelijk te gebruiken, alleen is webverkeer blijkbaar zo veeleisend geworden dat TCP niet meer voldoet — bij een "ouderwetse" webpagina met wat html, een css-bestand, wat plaatjes en misschien een javascript-scriptje ga je het verschil tussen HTTP/1.0 met TCP en Http/3 met QUIC niet merken. Bij mijn gmail-inbox (290 requests die in de loop van 30 seconden binnen komen druppelen voordat-ie "klaar" is) is dat wel anders.
TCP is niet verouderd maar een set afspraken.
Bij lossy netwerken kan het kwijtraken van een pakket een groot probleem opleveren, zeker als er grote windows gehanteerd worden.
Als een IP pakket kwijtraakt dan zal bij TCP al het verkeer aan de ontvangende kant opgehouden worden in buffers tot de ontbrekende info binnen is. Bij UDP kan de rest evt. wel afgehandeld worden.
Dit is met name als er gemultiplexte streams bestaan.
Web browsers maken met name DAAR gebruik van door bij elke server meerder substreams op te vragen (SPDY aka HTTP/2). Dit is de volgende stap als er gemultiplexte verbindingen zijn dan hoeft stream 20 niet te wachten op een kwijtgeraakt stream 25 bericht dat toevallig eerder was verzonden als alle data die in stream 20 nu aan de ontvangende kant staat te wachten.
Goede uitleg: https://ma.ttias.be/googl...tocol-moving-web-tcp-udp/
Waarom is het dan sneller vraag je je af?
Minder round trips nodig voor connection setup.
Omdat het missen van een pakketje niet de enige reden is dat bij HTTP over TCP meerdere pakketten heen en weer moeten om een verbinding op te zetten.
Omdat er voor http/2 gekozen is om meerdere sessie over 1 tcp verbinding te laten lopen. Dat heeft als voordeel dat maar 1x de verbinding hoeft te worden opgezet, iets wat voor interactieve encrypted https verbindingen lang duurt.

Het nadeel is dan dat als tcp ff stokt, alles stokt. Terwijl er slecht 1 van de gemultiplexte verbindingen hoeft te stoppen(dan laad die ene foto maar wat trager)

http/1 (eh.. traditioneel http) had er ook geen last van, want daar werd voor elk request een nieuwe verbinding opgezet. Dan heb je geen last dat alle verbindingen vastlopen, maar je opzet tijd is lang omdat je voor elk request een nieuwe verbinding opzet.

Ik twijfel er eigenlijk niet aan dat browsers terugvallen over http/2 en http/1 als er geen udp "verbinding" mogelijk is, of als deze instabieler blijkt te zijn.
Ik twijfel er eigenlijk niet aan dat browsers terugvallen over http/2 en http/1 als er geen udp "verbinding" mogelijk is, of als deze instabieler blijkt te zijn.
Ik wel. Eén van de rechtvaardigingen voor TLS 1.3 is dat de laatste jaren duidelijk werd dat TLS1.2 onveilig is wanneer een Man-In-The-Middle aanval zo'n terugval kan forceren.

De onderliggende rechtvaardiging voor fallback is dat een onveilige verbinding beter is dan geen verbinding. Het argument tegen fallback is dat een gekraakte verbinding slechter is dan geen verbinding.
Pak een packet capture van een youtube filmpje naar een android telefoon met ipv6 en zie dat er al quic wordt gebruikt. Constateer dan dat er een bulk aan data verstuurd naar de telefoon en die daarna reageert met waarschijnlijk op laag 7 acknowlegdements of info over missende packets.

In een betrouwbaar netwerk is quic ook daadwerkelijk snel en is de overhead laag, in een onbetrouwbaar netwerk zullen er retransmits moeten worden gedetecteerd en gegenereerd worden. Dan is quic nog altijd sneller dan tcp (die altijd dezelfde overhead heeft) en op applicatie laag kan dan alsnog worden besloten dat dat missende pakketje niet belangrijk was.
Missende pakket-informatie zal niet uit de browser komen, maar uit de QUIC device driver.

Nu is het OSI model met z'n laag-nummering redelijk theoretisch; het beschrijft de OSI stack en we hebben het hier over de TCP stack. Maar het is duidelijk dat de QUIC laag geen presentatie- of applicatie-laag is, dus als je QUIC al een OSI nummer zou wil geven dan is het geen 7.
QUIC driver?... QUIC = HTTP + TLS over UDP.
Waarbij multistream gewerkt wordt (net als HTTP/2) maar de pakketten voor de Streams onanfhanekijk van elkaar verzonden worden waardoor er geen afhankelijkheid tussen streams ontstaat zoals bij TCP het geval is.

Quick is dus alleen voor Browser <-> Webserver van toepassing, dus Browsers en Webservers zullen dit gaan oplossen.

Ik zie wel een issue in het kader van TLS Keygeneratie. Dat is per definitie geen proces dat in een stap gedaan kan worden.
UDP, IP en ethernet doen dat inderdaad niet, dus zal QUIC dat zelf moeten doen.
De basis van het OSI-lagenmodel is dat als een laag het niet doet, een ander laag het moet doen. Als je op laag X een feature verwijdert dan betekent het niet dat je nooit meer die feature kan implementeren, het betekent dat je dat op een andere laag moet gaan implementeren. Worst case doe je vrijwel alles in de applicatielaag, zie bijvoorbeeld bij morse-coding.

[Reactie gewijzigd door Lekkere Kwal op 14 november 2018 10:30]

UDP niet, QUIC wel...
QUIC is UDP met een extra laagje vernis. Waarbij er meer info in het eerste pakket mag worden gestopt. ==> bij de eerste aanvraag het geheel kan worden beoordeeld ipv. allerlei opeenvolgende vragen en antwoorden.
Daarnaast als er niet tijdig een antwoord komt dan kun je altijd een "retransmit" doen net als bij andere protocollen.
in de basis is het toch zo dat udp een pakketje is dat over het netwerk gaat, waarbij niet gevalideerd wordt of het correct is aangekomen, bijv. omdat hersturen geen kwaliteitsverbetering opleverd, bijv. tv beeld wat dan alweer voorbij is,

waarbij juist bij tcp, gecontrolleerd wordt of alles correct is aangekomen en desnoods corrigeert.

waarbij zit bij quick dan nu de werkelijk meerwaarde en hoe kan het instaan voor een beveiligde verbinding als de pakketje niet tweezijdig gevalideerd hoeven te worden
Je moet quic eerder zien als 'TCP 2.0', de hoofdreden dat QUIC over UDP gaat is voor compatibiliteit met zogenaamde middleboxes (denk NAT, firewalls, ...). Die ondersteunen bijna altijd UDP en TCP maar zelden andere protocollen. Dit is ook een van de redenen waarom bv. SCTP nooit is doorgebroken (al zijn daar andere problemen mee ook). Omdat UDP eigenlijk enkel (de-)multiplexing en packet integrity voorziet en niets anders (congestion control, retransmits, ordering, ...) is het goed genoeg om andere protocollen zoals QUIC bovenop te bouwen.

De voorbeelden die jij aanhaalt doen dit ook trouwens, waar een protocol als RTP geen retransmits regelt zal het wel weten of een packet gedropt is en of packets out of order aankomen. Het stript gewoon andere overhead van TCP zoals HOL blocking door retransmits, die niet wensbaar zijn bij real-time streaming. Je hebt eigenlijk zelden een applicatie die rechtstreeks UDP gebruikt zonder een soort extra reliability laag via een tussen protocol of in het applicatie-protocol ingebakken.
is het goed genoeg om andere protocollen zoals QUIC bovenop te bouwen.
Sterker nog, UDP is gewoon de perfecte keuze hiervoor. Multiplexing heb je toch nodig en iets op IP baseren zonder kernel-support wordt waarschijnlijk lastig.
Misschien dat het eerste pakketje een checksum bevat, dus dat de validatie van het aankomen van pakketten alleen client-side gebeurt? Een gefaalde serie pakketjes leidt dan dus wel tot meer requests voor de server.

[Reactie gewijzigd door DwarV op 14 november 2018 10:17]

waarbij zit bij quick dan nu de werkelijk meerwaarde en hoe kan het instaan voor een beveiligde verbinding als de pakketje niet tweezijdig gevalideerd hoeven te worden
Wat ik begrepen heb, willen ze de betrouwbaarheid verhogen, door het zelfde request naar meerdere servers te sturen en het antwoord te accepteren van de snelste.

Neem nu.nl als voorbeeld, https://toolbox.googleapps.com/apps/dig/#A/nu.nl
Deze heeft meerdere A records.
Een browser die Quic ondersteund en de webserver van nu.nl ondersteund het, zal naar al deze records een request sturen, en de snelste gebruiken.
Ik mag hopen dat ze dat toch echt niet doen. Dat gaat een redelijk grote extra belasting opleveren op het internet net omdat we met UDP zitten. Alle servers gaan namelijk ook gewoon antwoorden.
Precies, alle servers gaan antwoorden. En dat antwoord is nu dus één pakketje met de TLS setup. De client kiest vervolgens met welke server die beveiligde verbinding wordt opgezet. De echte overhead zit 'm in het beveiligen van de TLS verbinding, en dat gebeurt dus maar 1 keer.
Dit zijn vaak verbeteringen die alleen een verschil maken voor sites die ongeveer zo groot zijn als Google en Facebook. Ja dan kan zo een kleine optimalisatie al gauw een paar duizend servers schelen, dus de moeite waard voor hun. Echter voor de rest van ons?? Het blijft gek dat optimalisaties die enkel voor een paar hele grote bedrijven een verschil maken in de standaard terecht komen.

[Reactie gewijzigd door ro8in op 14 november 2018 10:11]

Echter voor de rest van ons??
Ook voor kleine sites is het een voordeel. En je hoeft eigenlijk niks te doen om het te gebruiken.. dus er zijn weinig nadelen.

[Reactie gewijzigd door Olaf van der Spek op 14 november 2018 10:11]

je hoeft eigenlijk niks te doen om het te gebruiken
Dus ik kan gewoon in nginx "http3 on;" gebruiken?

Om HTTP/2 deftig te gebruiken moet je bv al je resources al op voorhand meegeven.
Ik hoop dat nginx de defaults verbeterd zodat je alleen nginx maar hoeft te upgraden.
Om HTTP/2 deftig te gebruiken moet je bv al je resources al op voorhand meegeven.
Dat zal met HTTP/3 /3 niet anders zijn natuurlijk, de client heeft geen glazen bol om te weten welke resources die nodig gaat hebben.

[Reactie gewijzigd door Olaf van der Spek op 14 november 2018 10:41]

De vraag is eigenlijk; hoeveel moet ik dan daadwerkelijk gaan configureren? De HTTP/2 push was als voorbeeld dat de "je hoeft helemaal niks te doen" stelling zeer subjectief is.
Ook zonder push hebben http/2 en http/3 voordelen.

De beste performance zonder zelf iets te hoeven doen kun je echter vergeten, maar dat geldt voor http/1 ook.
Dat klopt niet geheel, om http2 te gebruiken hoef je geen server push te voorzien, dat is een feature, niet een vereiste.
Eh, met deftig gebruiken bedoel ik dus wel de features die het van HTTP/1.1 scheiden te benutten. Ik dacht dat dat duidelijk was.
er zijn wel meer verschillen met http 1.1, zoals bijvoorbeeld connection multiplexing, daar hoef je niets voor te doen.
Voor kleinere sites is het verschil van hardware vaak 0 omdat ze toch niet op het maximum van de hardware draaien (server(s) heeft spare power voor nog duizenden connecties extra). Voor het verschil van 0,00002 seconden aan de client side hoef je het ook niet te doen.

[Reactie gewijzigd door ro8in op 14 november 2018 10:27]

Het verschil in latency waar over gesproken wordt, komt niet van een grote of kleine site-inhoud.

Die komt door de verschillende keren heen-en-weer praten die met TCP + TLS wél nodig zijn en bij QUIC níet nodig zijn.

Elk request dat je over een beveiligde verbinding doet zal weer te maken krijgen met diezelfde latency, of niet meer wanneer je QUIC gebruikt :)
Dat klopt, maar aan de client side maakt dit een verschil van microseconden welke verwaarloosbaar zijn. (Je zal hier niets van merken). Aan de server kant maakt dit een verschil van een aantal connecties welke in 99% van de gevallen ook verwaarloosbaar zijn. Alleen voor de hele grote jongens zoals Google en Facebook zou dit een verschil maken. De vraag blijft een beetje dus, moeten we nu optimalisaties in een standaard doorvoeren waarvan eigenlijk alleen maar de hele grote bedrijven van profiteren en voor de rest van ons weinig doet. Ik ben helemaal niet per definitie tegen optimalisaties, maar is het nodig om dit echt onderdeel te maken van een http3 specificatie als het voor 99% van de mensen geen enkel verschil maakt.
De betere latency komt niet door minder verwerking op de client, maar vooral doordat er minder round-trips nodig zijn tussen de client en de server voordat een verbinding tot stand is gekomen. Een round-trip kost enkele tientallen milliseconden, en dat kan oplopen tot meer dan 200 afhankelijk van waar de server staat. Als je voor Quic dus 1 roundtrip nodig hebt (maximaal) ipv 3 voor HTTPS via TCP+TLS, en elke roundtrip is 50 milliseconden, bespaar je 100 milliseconden per verbinding. Dat is een groot verschil met die enkele microseconden waar jij het over hebt.

Vergeet ook vooral niet dat we hier in Nederland heel goede internetverbindingen hebben. In grote delen van de wereld is internet een stuk trager, en ook minder stabiel. Daar kan de overhead van TCP en bijbehorende retransmissions een veel grotere invloed hebben op de gebruikerservaring.
Dat klopt, maar aan de client side maakt dit een verschil van microseconden welke verwaarloosbaar zijn.
Dat is simpelweg niet waar. Nogmaals: Misschien moet je jezelf eens verdiepen in de details..

Als de round trip time 100ms is, en je hebt 4 round trips nodig in plaats van 1 scheelt dat gewoon 300ms.

[Reactie gewijzigd door Olaf van der Spek op 14 november 2018 10:48]

Exact wat je zegt.

Wat is 300ms nou?? Wil je zeggen dat jij het verschil tussen 100 of 300ms merkt? Met je ogen knipperen duurt nog langer.

[Reactie gewijzigd door ro8in op 14 november 2018 10:51]

Tegenwoordig vandaag de dag is round trip misschien 30ms tot 50ms, 4 keer 50ms is 200ms. Wat is 200ms nou??
1. Ongeveer 100.000x zoveel als de microseconden waar jij het over hebt.
2. Round-trip naar de andere kant van de wereld is gewoon geen 50ms.
3. Niet iedereen heeft een snelle internetverbinding. Denk derde wereld landen, maar denk ook iemand met een 8/1 DSL abo en een torrent client..
Wil je zeggen dat jij het verschil tussen 50 of 200ms merkt?
Dat sowieso.. maar onderzoeken tonen gewoon aan dat er meer gekocht wordt op webshops met snelle sites bijvoorbeeld.

[Reactie gewijzigd door Olaf van der Spek op 14 november 2018 10:54]

Elke source die jouw browser van de server af request, krijgt met dezelfde latency te maken.
Dus als we het per request even op die 100ms houden en er al snel 30 sources bij een web pagina geladen worden dan ben je alleen al op verbindingen tot stand brengen 3 secondes aan het wachten.

Dan heb je het nog niet over het renderen van de pagina zelf en ook niet over het ophalen van de source zelf.

Minstens 3 secondes voor niets wachten op een webpagina vind jij denk ik ook wel vervelend. (Tenzij je erg langzaam met je ogen knippert natuurlijk ;) )
De officieuze norm is dat je 4 HTTP connecties tegelijk mag doen, per hostname. Dus zelfs als die 30 resources van dezelfde server afkomen zijn het nog maar 8 request roundtrips. En HTTPS heeft altijd keep-alive dus je hebt voorafgaand aan die 8 requests maar 3 roundtrips nodig voor de TLS setup. Kortom, 1.1 seconden in plaats van 3. En als je een CDN inzet, daardoor een tweede hostname hebt, en 8 parallelle connecties, dan kan dat dus nog verder omlaag
Wat is 300ms nou?? Wil je zeggen dat jij het verschil tussen 100 of 300ms merkt? Met je ogen knipperen duurt nog langer.
Het zal je verbazen hoeveel winst daar te halen valt.

Oud artikel, maar dit geeft het al aan:
https://www.fastcompany.c...t-amazon-16-billion-sales
https://www.cdnetworks.co...k-out-these-15-stats/4312

Zijn heel wat van deze onderzoeken te vinden op het internet.

ms === geld

Kortom; een page load in een website/app moet bijna instant zijn, anders haken mensen gewoonweg af. Wachten in honderden millisecondes is dus wel degelijk merkbaar in je snelheid perceptie volgens deze onderzoeken.

[Reactie gewijzigd door JorzoR op 14 november 2018 14:44]

Voor het verschil van 0,00002 seconden aan de client side hoef je het ook niet te doen.
Misschien moet je jezelf eens verdiepen in de details..
Voor kleine sites heeft het geen voordeel. De servers hebben zat capaciteit om TCP te doen. De grootste delay wordt geïntroduceerd door de toevoeging van ads of het separaat serveren van CSS / JS via CDN's. Iets wat SPDY ook al stroomlijnt, mits sites daardoor niet langer CDN's gebruiken.

Dat het geen nadeel heeft voor kleine sites maakt het niet opeens een voordeel voor kleine sites.

Voor serverparken van Google en Facebook en dergelijke maakt het inderdaad wel uit, elke honderste procent verbetering scheelt al kapitalen daar.
De servers hebben zat capaciteit om TCP te doen.
Het gaat dan ook niet om server-capaciteit maar om de latency van requests en die kan ook voor kleine sites omlaag. Sterker nog, kleine sites hebben waarschijnlijk geen servers overal ter wereld, hebben dus een hogere latency en dus meer voordeel van minder roundtrips.
Mwah. Denk aan TCP offloading wat nu gebeurd op het hele traject. Dat zou voor HTTP(S) verkeer dan niet meer nodig zijn. Sterker nog, de hele definitie van HTTPS gaat dan verdwijnen lijkt me, als SSL al native in http/3 zit.
Ja dan kan zo een kleine optimalisatie al gauw een paar duizend servers schelen, dus de moeite waard.
Ik hoor deze redenering vaak maar snap hem niet. Het is de trand van "als alle vliegtuigmaatschappijen hun klanten verplichten de nagels te knippen voor het boarden scheelt dat op jaarbasis tonnen aan brandstof". Stel dat een klein bedrijf hiermee een paar euro per jaar kan besparen. Niet echt indrukwekkend. Maar Facebook kan hiermee tienduizenden euro's per jaar besparen, omdat ze duizend keer zo groot zijn: denk je dat de aandeelhouders dan opeens onder de indruk zijn? Dat Facebook, met een omzet van meer dan 10 miljard euro nog geen ton heeft weten te besparen op zijn serverkosten?

In de praktijk zijn kleine besparingen individueel niet zoveel waard. Maar als je alle kleine besparingen bij elkaar optelt dan heb je een gigantisch effect. Van de kleinste efficiëntieverbetering in de processoren/memory-controler tot aan het een paar procent efficiënter comprimeren van afbeeldingen, in totaal bespaar je een gigantische hoeveelheid data/geld door ze allemaal toe te passen. Dan heb ik het niet over procenten of zelfs tientallen procenten, ik durf te beweren dat als je alle marginale verbeteringen uit de hele hard- en software stack verwijderd, je meer dan duizend keer zoveel geld uit moet geven om hetzelfde te bereiken. Ook als klein bedrijf.
Ik hoor deze redenering vaak maar snap hem niet.
Waarom niet? ;)
Als Google door optimalisaties die 1 miljoen euro aan arbeid kosten 1% minder servers / minder energie nodig heeft, is dat het waarschijnlijk waard.
Iemand met een simpele website gaat geen 1 miljoen euro spenderen om 1% efficiënter te zijn. Dat is de redenatie. En vergis je niet in hoeveel servers bedrijven als Google en Facebook hebben en hoeveel dat kost.

[Reactie gewijzigd door Olaf van der Spek op 14 november 2018 10:33]

Als je het hebt over de ontwikkeling van een efficiënter protocool dan heb je gelijk: dat geld kan Google investeren en terugverdienen. Als het gaat over de implementatie: ik mag toch hopen dat die geen miljoen euro gaat kosten. Sterker nog, ik verwacht dat een kleine websitebeheerder op termijn een nieuwe versie van zijn softwarestack (e.g. Apache) installeert en dit alles automatisch krijgt: hij heeft dus ook maar een fractie van de kosten te maken.
Neem het nog even verder, als een optimalisatie 1M euro kost, om een besparing te bereiken van 6 ton op jaar basis, dan voert elk potentieel bedrijf die actie uit. Het roi termijn is iets waar meer naar gekeken wordt dan naar de werkelijke efficiëntie, tenzij de efficiëntie een beperkende factor gaat vormen aan de business kant.
Ik begrijp je punt, echter vergeet je het een en ander.

Stel google is 100 keer zo groot in omzet als jou. Wat jou 1 euro dan scheelt, scheelt hun niet 100 euro omdat ze 100 keer zo groot zijn. Hun omzet factor ligt misschien op 50% van het aantal connecties. Je omzet groeit niet automatisch even hard als het traffic volume op je servers. Wat jou misschien 1 euro scheelt, scheelt hun misschien wel 1000 of 10.000 euro, ook al zijn ze omzet wise maar 100 keer zo groot.
Dit heeft weinig met omzet te maken. Heb je weleens naar de broncode van een gemiddelde webpage gekeken tegenwoordig? Elke externe resource heeft een verbinding nodig. Internet Explorer 10 had een limiet van 2 concurrent connections per domein en 6 in totaal. Via de 6 connections probeert de browser zoveel mogelijk resources via keep-alive binnen te halen. Echter op een gegeven moment moet je toch weer een nieuwe connectie opzetten omdat je alle resources van Bootstrap binnen hebt en nu de resources voor Angular moeten worden ingeladen..

Ook vanuit de browser kun je dus wel degelijk een boost merken omdat de download van de resources sneller begint..
Het scheelt latency. Kortom, jouw request naar een webserver met dit enabled wordt sneller beantwoord, dat lijkt me iets waar vooral jij als gebruiker iets aan hebt. Mocht je zelf webservers draaien is het toch ook fijn dat jouw klanten minder lang hoeven te wachten?

Hoe je op 'het scheelt duizenden servers voor de grote jongens' komt is me niet duidelijk, maar volgens mij zeur je om het zeuren.
Los van OP zijn negativiteit: Als alle requests sneller worden afgehandeld, dan kan je toch binnen eenzelfde tijdsframe meer requests per server afhandelen en heb je toch minder servers nodig, niet?
De totale doorlooptijd is korter, dat wil niet zeggen dat de hoeveelheid CPU tijd die het kost minder is. Een thread die staat te wachten op een antwoord kost niet zo veel.
Als je server inderdaad alles sequentieel zou afhandelen wel, maar gelukkig werken bij uitstek servers vaak heel parallel, en worden dit soort zaken (het connectie stuk) toch al los afgehandeld van de voor de server meestal veel zwaardere daadwerkelijke pagina-logica.
Een server staat niet 'te wachten' tot de client weer eens terug komt met een volgende stap, in die tijd is de cpu gewoon andere zaken aan het verwerken voor een andere client. (behalve bij een slow-loris achtige aanval die het aantal beschikbare connecties opvult met traag handelende clients)
Voor de servers zal het niet zoveel uitmaken inderdaad buiten dat ze meer clients kunnen bedienen.
Voor de clients echter: minder overhead => minder cpu belasting => cpu sneller naar idle.
Dat is maar een kleine hoeveelheid per client, maar wereldwijd....

[Reactie gewijzigd door hackerhater op 14 november 2018 12:15]

Klaag je er nu over dat verbeteringen "voor de rest van ons" de standaard niet halen (en welke zijn dat dan), of over dat er verbeteringen worden aangebracht waar je zelf weinig voordeel van hebt?
Ik klaag niet, ik geef alleen aan dat in http wel vaker dingen in de standaard verwerkt worden waar 99% van de wereld weinig aan heeft.

Als je kijkt bij bijvoorbeeld de wifi alliance, dan gaan dingen pas het protocol in als je daar wel degelijk op individuele basis echt wat van merkt.

[Reactie gewijzigd door ro8in op 14 november 2018 10:55]

Maar wat vind je daar dan gek aan? In nieuwe versies van veelgebruikte software zijn vaak bugs opgelost waar 99% van de gebruikers nooit tegenaan zou lopen. Zou dat een reden moeten zijn om die bugs er dan maar in te laten zitten?
Bugs zijn bugs, dat is wat anders dan optimalisaties die alleen toegevoegde waarde hebben bij heel grootschalig gebruik.
Bugs zijn bugs
En verbeteringen zijn verbeteringen.
Het lijkt me dat het verbeteren van latency voor alle eindgebruikers een voordeel is. Als je een slechte mobiele verbinding hebt kun je een efficiënter protocol wel waarderen.
Juist als je een slechte verbinding hebt gaat dit weinig uitmaken. TCP zorgt er inherent voor dat pakketen veilig aankomen. Bij gebruik van UDP zal dit in de applicatielaag ingebouwd moeten worden. De grafiekjes boven laten alleen het best-case-scenario zien. Bij slechte verbindingen met packet loss zal er meer communicatie nodig zijn. Met name voor betrouwbare verbindingen gaat dit voordelen hebben, maar dan vooral aan de serverkant - de clients zullen hier weinig van merken.
Je hebt natuurlijk gelijk. Bij een niet constante verbinding levert dit geen voordeel op, misschien nadeel. Ik doelde op een situatie waar je wel verbinding hebt maar met lage snelheid en hoge latency.
Hoe slechter de verbinding, hoe meer voordeel je hebt van minder packets.
Als de retry mechanismes goed in elkaar steken die in de applicatie zitten. En daar maak ik me wel zorgen over: de TCP mechanismes om robuust te communiceren zijn battletested. In de browser TCP flowcontrol en retry op UDP namaken klinkt niet als een goed plan: alle kinderziektes komen weer langs (wellicht een ping of death naar je browser via server push).
Ja, maar het aantal packets zal toenemen naarmate de packet loss toeneemt. De verloren gegane data zal opnieuw aangevraagd moeten worden en opnieuw verzonden. Net zoals bij TCP gebeurt.
Net zoals bij TCP gebeurt.
Ja, maar omdat QUIC minder packets nodig heeft, heeft het dus een voordeel.
Bij de best case scenario heeft QUIC minder packets nodig. Blijft dat zo als er packet loss optreedt? De ACK van TCP vervalt, maar die wordt dan dus vervangen door een oplossing op een hogere laag. Daarmee wordt die ook een hoger laag-niveau in software afgehandeld en kan dit niet al door de routers geregeld worden. Ik ben benieuwd hoe de performance van TCP vs QUIC is over hele slechte verbindingen met veel packet loss.
Daarmee wordt die ook een hoger laag-niveau in software afgehandeld en kan dit niet al door de routers geregeld worden.
Routers doen geen TCP, die doen IP.
Blijft dat zo als er packet loss optreedt?
Ja. Een packet dat je niet hoeft te versturen kun je ook niet kwijt raken. ;)
Switches doen IP. Routers doen IP, maar ook TCP. En UDP. Packet filtering en meer van dat moois. Ik zit er zeker niet genoeg in om te weten hoe de precieze implementatie van de ACK eruit ziet maar ik zou me kunnen voorstellen dat de routers tussen bron en bestemming hier al een en ander in kunnen optimaliseren, terwijl dat op een hoger niveau sowieso onmogelijk is zonder hiervoor ondersteuning in routers in te gaan bouwen.
Ja. Een packet dat je niet hoeft te versturen kun je ook niet kwijt raken. ;)
Een ACK wordt niet ge-ACK'ed. Als de ACK niet bij de afzender aankomt zal de afzender het pakket opnieuw verzenden. In dit geval lijkt het erop dat de ACK achterwege gelaten wordt, en dat als de ontvanger een pakket mist hij deze opnieuw gaat aanvragen bij de afzender. De ACK heb je dan inderdaad bezuinigd maar je hebt alsnog wel een hoop meer round trips. UDP is gebaseerd op de aanname dat verloren pakketjes verloren kunnen blijven, dus dit zou de performance niet per sé goed moeten doen.

Sowieso gaat het voordeel van QUIC afnemen bij slechtere verbindingen. En betrouwbare verbindingen zijn doorgaans ook snellere verbindingen dus daarmee is het voordeel nog steeds vooral voor de servers. Niets op tegen natuurlijk, maar dan ga ik niet joelend de straat op van enthousiasme ;)

[Reactie gewijzigd door MadEgg op 14 november 2018 11:40]

Je zit een niveau te ver hoor.. Switches doen L2 (dus met mac-adres enzo) Routers doen L3 (dus IP).
Je hebt vast gelijk, maar switches houden toch een ARP-cache bij om te weten welk IP-adres bij welk mac-adres en dus bij welk poortje hoort? Of vertaalt de router het IP-adres naar het mac-adres en gaat de switch daar alleen mee aan het werk?
nee en nee. Switches houden een mac tabel bij, waarinstaat wel mac adres aan welk portje zit. Routers doen helemaal niets met mac adressen.
nee en nee. Switches houden een mac tabel bij, waarinstaat wel mac adres aan welk portje zit. Routers doen helemaal niets met mac adressen.
Ok, weer wat geleerd :) (met wat gedetailleerde info van https://networklessons.co...105/ip-routing-explained/ )
ARP caches zitten aan de computer kant. Dat is precies om ervoor te zorgen dat de switch alleen naar MAC adressen hoeft te kijken.

Managed switches zijn een ander verhaal, dat zijn bijna routers.
Jij bedoeld L3 switches. Je hebt managed L3 switches maar ook managed L2 switches.
Ik zie niet hoe dit nadeel kan zijn. Typische draadloze verbindingen hebben een droprate van ongeveer 10%, als je met TCP 4 keer zoveel data verzend, drop je dus ook veel meer. Een retry voor TCP is immers hetzelfde als een retry van een UDP. pakketje.
Typische draadloze verbindingen hebben een droprate van ongeveer 10%,
Dat wordt lokaal opgelost door het WiFi protocol, toch? Als je dat op TCP niveau hebt, is het echt een ramp.
Daar heb je inderdaad wel een punt!
Minder CO2 uitstoot? En aangezien miljarden mensen de diensten van Facebook en Google gebruiken….
Die optimalisaties zijn voor iedereen goed, niet enkel voor grote bedrijven. De delay die initiele handshakes opleveren zijn wel degelijk merkbaar, op elke website (klein of groot), al zeker over links die wat meer congested/unreliable zijn (denk wireless). Dus dat weghalen helpt iedereen.

Maar daarnaast is het ook zo dat een groot gedeelte van de switches/routers/... simpelweg niet aan line-rate kunnen werken bij kleine paketten want je bottleneck is al gauw je processing per pakket ipv je IO. Waaruit bestaan al die handshakes? Juist ja, vrij kleine paketten. Elke stap die kleine overhead paketten zoals TCP SYN en (pure) TCP Ack verwijdert zal ook zorgen dat deze machines efficienter draaien, zonder dat daar enige software/hardware update voor nodig is. Dat zorgt ervoor dat er weer op wat andere (nuttigere) zaken kan gefocust worden en er wat minder elketriciteit verbruikt wordt om die paketten te forwarden.
Helemaal niet, minder heen en weer praten zal een "groot" verschil maken voor iedereen. Voornamelijk high-latency lijnen, zoals satellite lijnen.
Kleine sites zijn vaak net minder geoptimaliseerd dan grote spelers en halen hier dus een grotere winst uit. Het gaat dan niet zozeer om servercapaciteit, maar om latency van de requests. Het aantal requests dat een huis-tuin-keuken website doet zal flink meer zijn dan wanneer jij google.com laadt. Alles dat helpt om die roundtrips te vermeiden, helpt.

Als het verschil effectief 200ms is (en niet enkele microseconden zoals jij vermoedt), ga je dat als bezoeker echt wel merken.
Een aantal zaken
1) Alles schuift met een rotvaart naar cloudcomputing, dus zelfs de tandarts op de hoek draait zijn site (en zijn afsprakenmanagementsysteem en zijn rontgenanalyse-applicatie, en zijn, etc.) op een omgeving waar een heel kleine optimalisatie heel veel verschil maakt in het groter geheel.

2) Als gebruiker is 200ms verschil in laadtijd (net) merkbaar. Vraag maar aan gamers of ze liever een 'ping' van 50 of 250ms hebben.

3) Toegenomen veiligheid van het net (TLS 1.3) is voor iedereen voordelig. Security by default is een ontwerppatroon wat cybercrime lastiger maakt en daarmee hopelijk ook minder aantrekkelijk.
Wat dan weer wel zo is is dat het hoe dan ook gunstig is voor de rest van het internet. Als netflix voor iedere 10 MB 100KB kan besparen dan levert dat netto 1% minder verkeer op. En dan heb je op globale schaal 1% van 50% bespaard. Netflix is in landen als de USA en NL veelal goed voor meer dan de helft van het totale netwerk verkeer.
Nee hoor. Ik werk bij een internetbureau dat een 200-tal kleine tot middelgrote sites bouwt en host. Het overstappen naar HTTP/2 verbeterde voor een groot deel van de sites al merkbaar de snelheid. Ik verwacht dat zero-rtt ook nog merkbaar gaat schelen, vooral omdat alle sites op HTTPS draaien en de TLS handshake niet te verwaarlozen is.
Ben erg benieuwd, hoe sneller de pagina's laden hoe beter. :)
Zijn er al webservers die quic ondersteunen?

Het is mooi dat we veel aan Google en andere grootmachten te danken hebben, alleen toont het wel weer aan hoe afhankelijk we van deze partijen zijn geworden en hoeveel goede mensen zij in dienst hebben.
Als je in chrome naar youtube gaat bijv. Dan gebruikt het in principe al een implementatie van quic op http/2.
Ik hoop dat er goed is nagedacht over (het voorkomen van) UDP amplification aanvallen. Heb me verder niet verdiept in QUIC, maar was het eerste wat in me opkwam bij het gebruik van UDP.

Zal vast over nagedacht zijn...
Het enige raakpunt is UDP in dit verhaal, voor de rest heeft dit er niets mee te maken.
SYN floods bestaan in het TCP protocol, dat wil niet zeggen dat HTTP slecht is.
Niet helemaal waar, denk ik... Stel ik stuur een QUIC request voor een download van 1GB, dan zou het toch leuk zijn als deze data niet onbedoeld bij een slachtoffer terecht komt (iets wat met TCP niet het geval kan zijn). Vergelijk het met DNS via UDP wat ook eenvoudig misbruikt wordt.

Hoe QUIC dit afhandelt lijkt me daarom wel degelijk van belang. Ik heb me verder niet verdiept in QUIC, hoop alleen dat er over nagedacht is ;)

Edit: Ik lees in de reacties van @GertMenkel dat QUIC inderdaad een handshake uitvoert, probleem opgelost dus... En nee, UDP is dus niet het enigste raakvlak O-)

[Reactie gewijzigd door pietermx op 16 november 2018 08:21]

Wat wel zeer onrustmakend is, is het "Enterprise TLS" (eTLS) verhaal: https://www.etsi.org/news...nd-data-centre-management

"TLS 1.3 removes support for certain key exchange methods, which prevents passive decryption of TLS 1.3 sessions at any scale."

Misschien dat Tweakers dit best ook wel vermeld. Er bestaat dus geen Perfect Forward Secrecy meer in TLS versie 1.3, iedereen met de key kan alles lezen.
Dit is een implementatievariant van TLS 1.3, niet de spec.

[Reactie gewijzigd door Nindustries op 14 november 2018 11:05]

De zin die je quote zegt juist het tegenovergestelde. Doordat TLS 1.3 alleen maar exchanges ondersteunt met perfect forward secrecy is het juist NIET mogelijk om versleuteld verkeer achteraf de ontsleutelen.

Dit is een probleem voor sommige bedrijven (vooral in Amerika) die een kopie van al het ontsleutelde verkeer moeten bewaren vanwege compliancy requirements. Dit werd gedaan door TLS zo te configureren door middel van zogeheten middleboxes en software dat de sleutels altijd hetzelfde waren zodat decryptie kon worden gedaan wanneer vereist. Hiervoor was speciaal ondersteuning toegevoegd aan TLS. Deze ondersteuning is nu verwijderd.

Bron: Cisco
Zet dit niet de deuren open voor ip spoofing?

edit; gezien het eenweg verkeer.
Er bestaat evenveel kans op IP spoofing als met TCP. QUIC implementeert zelf een TCP-achtige handshake waardoor spoofing alsnog lastig is.

Afhankelijk van de grootte van het eerste pakketje dat QUIC terugstuurt kan dit wel een DDoS-vector zijn. Ik heb niet veel kennis van QUIC maar als ik mijn traces in Wireshark zo bekijk, is de eerste response van de server even groot als het request. Ik weet echter niet of er retries van de serverkant worden gestuurd. Als dat niet gebeurt, maakt dit QUIC ook voor DDoS niet bijzonder bruikbaar.
Ik bedoel meer te zeggen dat je je voordoet als ip x.

Je stuurt uit naam van als ip x, een QUIC request, die weet ik het, een youtube stream.
QUIC stuurt antwoord naar ip x, niet naar jou. Relatief veel data

Echter in het klassieke TCP, zijn er wat SYC's en ACK's, en bij TLS, is er een handshake. Dus je moet iets met het antwoord wat je krijgt van QUIC, aka je kan je niet voordoen als IP x. Maar goed, QUIC zou daar vast wat slims op bedacht hebben.
Dat is waar en QUIC heeft daar ook wat op bedacht. Ze voeren zelf een soort handshake uit binnen het uitwisselen van UDP-pakketjes.
The IP address spoofing problem is handled by issuing the client, on demand, a “source-address token”. This is an opaque byte string from the client's point of view. From the server's point of view it's an authenticated-encryption block (e.g. AES-GCM) that contains, at least, the client's IP address and a timestamp by the server. The server will only send a source address token for a given IP to that IP. Receipt of the token by the client is taken as proof of ownership of the IP address in the same way that receipt of a TCP sequence number is.

Clients can include the source address token in future requests in order to demonstrate ownership of their source IP address. If the client has moved IP addresses, the token is too old, or the client doesn’t have a token, then the server may reject the connection and return a fresh token to the client. But if the client has remained on the same IP address then it can reuse a source-address token to avoid the round trip needed to obtain a fresh one.
Er zijn meer mechanismes om spoofing te voorkomen. Als je hier meer over wilt weten kun je het whitepaper over QUIC hier vinden: https://docs.google.com/d...45IblHd_L2f5LTaDUDwvZ5L6g
Als Quic UDP gebruikt, dan zal het zelf moeten zorgen voor een mechanisme voor het opnieuw aanvragen van niet ontvangen pakketten. Bij Streaming is het bijvoorbeeld niet zo erg dat een pakket verloren gaat, maar bij het renderen van webpagina's kan dat natuurlijk niet.
Het zit hem toch letterlijk in de benaming? quic word als transport layer gebruikt, http loopt daar over heen? Of zie ik dit verkeerd?
Nu deze kogel door de kerk is, dan zullen de bekende web servers als Nginx en Apache ook kunnen beginnen met implementeren.

Hoe gebeurt de handshake eigenlijk? Voordat je weet dat je als browser via Quic kunt, zul je eerst moeten weten of dit mogelijk is. Met TLS wordt eerst een handshake gedaan om een veilige verbinding op te zetten. Ik vermoed dat dit aangeven gaat worden in de TLS handshake.
A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and suggested compression methods. If the client is attempting to perform a resumed handshake, it may send a session ID. If the client can use Application-Layer Protocol Negotiation, it may include a list of supported application protocols, such as HTTP/2.
Lijkt me dat de client in een algemene handshake de connectie opend en afhankelijk van het antwoord HTTP1, HTTP2 of HTTP3 gebruikt.
Dat gaat natuurlijk niet lukken; het eerste pakketje is óf UDP óf TCP. Er is niet zoiets als een algemene handshake. Voor HTTP 1.x heb je TCP nodig en voor HTTP 3 heb je UDP nodig.

Wat wel kan is een HTTP 1.1 verbinding openen, via een HTTP Upgrade header upgraden naar HTTP 3, en dan later HSTS gebuiken om op HTTP3 te blijven.

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank, Intermediair en Independer de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2019 Hosting door True