Google heeft een netwerkprotocol ontwikkeld om verbindingen tussen browsers en webservers te versnellen: QUIC. Dat doet het protocol onder andere door het onderliggende protocol tcp te vervangen door udp. PCM legt uit hoe dat precies zit.

Het hele web is gebaseerd op http (hypertext transfer protocol), het applicatieprotocol dat afspreekt hoe een browser en webserver met elkaar communiceren. Maar dit is maar één protocol in een hele laag. Onder http werkt traditioneel het transportprotocol tcp (transmission control protocol). Dit is bekend om zijn betrouwbaarheid: het protocol garandeert dat gegevens aankomen. 

Bij het opzetten van een tcp-verbinding gebeurt er al een ‘3-way-handshake’: de zender stuurt een pakket naar de ontvanger, die stuurt een bevestiging terug, en daarna stuurt de zender daarop een bevestiging. En als de zender een pakketje stuurt en geen bevestiging terugkrijgt, stuurt hij het opnieuw.

Al die pakketjes die over en weer gaan, voegen extra vertraging aan elke verbinding toe. Bovendien voegt tls (transport layer security), de opvolger van ssl (secure sockets layer), ook nog eens een uitgebreide handshake toe om sessiesleutels en certificaten uit te wisselen. Zeker als je een versleutelde verbinding opzet, zit je dus talloze pakketjes over en weer te sturen nog voor je maar iets nuttigs kunt doen.

Verschil tcp en udp

Naast tcp is er nog een ander transportprotocol: udp (user datagram protocol). In tegenstelling tot tcp garandeert dat niet dat gegevens daadwerkelijk aankomen. Dit ‘onbetrouwbare’ protocol wordt veel ingezet in toepassingen waar het belangrijker is dat gegevens zo snel mogelijk overgedragen worden en het niet zo erg is dat een deel van de gegevens verloren gaat.

We merken lang niet altijd dat pakketjes verloren gaan

Denk daarbij aan videoconferencing of voip: we merken het waarschijnlijk niet eens als er wat pakketjes verloren gaan. Bij gebruik van tcp zou een verloren pakketje daarentegen opnieuw verstuurd worden en zou het beeld of geluid eventjes haperen door die vertraging.

Als een applicatieprotocol van udp gebruikmaakt en toch wil dat gegevens gegarandeerd aankomen, moet dat protocol zelf een methode daarvoor implementeren. In feite herimplementeert het zo een deel van de functionaliteit van tcp.

Zo werkt QUIC

Wat als je nu op het web tcp inruilt voor udp? Dan zouden de verbindingen al heel wat sneller opgezet worden. En dat is wat Google heeft gedaan: met het protocol QUIC (Quick Udp Internet Connections) neemt het opstarten van een verbinding én het afspreken van tls-parameters samen slechts één of twee pakketjes in. Het resultaat? Je kunt veel sneller een webpagina downloaden.

QUIC draait in de internetprotocolsuite dus boven udp, maar vervangt ook tls. Bovendien vervangt het nieuwe protocol een deel van http/2. Het hele verbindingsbeheer implementeert QUIC immers, en een stuk efficiënter dan het klassieke http. Wat overblijft van http/2 wordt in een http/2-api gestoken, die gebruikmaakt van QUIC.

©PXimport

Waarom udp?

Recentelijk zijn er allerlei inspanningen geleverd om het web te versnellen. In http/2 (zie kader) gebeurt dat bijvoorbeeld met multiplexing: als je een webpagina bezoekt, verlopen alle verbindingen tussen je browser en de webserver over één tcp-verbinding. Dus je browser hoeft niet meer voor elke afbeelding, css-bestand of javascript-bestand een nieuwe tcp-verbinding op te zetten met de bijbehorende vertraging.

Als alles goed gaat, werkt http/2 sneller dan zijn voorganger http/1.1. Maar omdat elk bezoek aan een webserver nu over één tcp-verbinding verloopt, vormt die verbinding een bottleneck. Tcp verwerkt immers alle pakketjes in dezelfde volgorde als ze verzonden zijn. Als de verzending van een pakketje mislukt, verstuurt de zender het pakketje opnieuw.

Udp is een 'onbetrouwbaar' protocol

De ontvanger wacht met het verwerken van de andere pakketjes tot het verloren pakketje arriveert. En hoe meer bestanden je over één tcp-verbinding downloadt, hoe groter de kans dat er ergens wel eens een pakketje verloren raakt en de verbinding dus tijdelijk blokkeert. Kortom: in goede omstandigheden is http/2 sneller dan http/1.1, maar in slechte omstandigheden trager.

Udp heeft dat probleem niet, omdat het een ‘onbetrouwbaar’ protocol is: het garandeert niet dat alle pakketjes aankomen. Als je QUIC boven udp gebruikt, legt een verloren pakketje dus niet de hele verbinding lam, maar heeft het alleen impact op het bestand waartoe het pakketje behoort.

Betrouwbaarheid QUIC

QUIC heeft dus de voordelen van http/2 zonder de bottleneck die tcp bij multiplexing introduceert. Maar geven we door het gebruik van udp nu niet te veel op? Je bent immers niet zeker of je gegevens correct worden overgedragen.

Dat klopt, en daarom implementeert QUIC zelf zijn eigen methode om te garanderen dat gegevens aankomen: forward error correction. Het is te vergelijken met raid5 voor opslag, maar dan voor netwerkpakketjes. Elk verzonden pakketje krijgt dus wat gegevens van andere pakketjes mee. Raakt er een pakketje verloren, dan kan QUIC de inhoud reconstrueren op basis van de andere pakketjes die wel zijn gearriveerd. Zo hoeft het pakketje niet opnieuw verzonden te worden.

De overhead van forward error correction is ongeveer 10 procent. Dat betekent dat QUIC voor elke 10 pakketjes die het verzendt, voldoende informatie meezendt om één verloren pakketje te reconstrueren. Dat lijkt inefficiënt, want je moet 10 procent extra pakketjes verzenden, wat ook extra tijd vraagt. Maar toch is dat nog altijd veel sneller dan verloren pakketjes opnieuw moeten sturen en wachten tot alle pakketjes binnen zijn.

QUIC is versleuteld

Een ander interessant aspect van QUIC is dat de verbinding altijd is versleuteld. QUIC herimplementeert immers de functionaliteit van tls. Zo implementeert het perfect forward secrecy (pfs). Dankzij die eigenschap is je eerdere communicatie nog altijd veilig als er een sessiesleutel uit een QUIC-verbinding wordt gecompromitteerd. Dat wil zeggen: uit een sessiesleutel kun je nooit de voorgaande sleutels afleiden.

QUIC beschermt ook tegen ip-spoofing

QUIC beschermt ook tegen ip spoofing, het vervalsen van het ip-adres van de zender. Daarvoor reikt de server aan de client een ‘source address token’ uit. De server versleutelt het ip-adres van de client en een timestamp van de server en bezorgt de client dat token. De server zendt dat token alleen aan het ip-adres dat in dat token zit. De server gaat ervan uit dat wie het token ontvangt, eigenaar is van het bijbehorende ip-adres. Op elk moment kan de server aan de client vragen om het token te sturen om te bewijzen dat het ip-adres van hem is.

De cryptografie in QUIC is overigens slechts een tussenoplossing. De ontwikkelaars hadden functionaliteit nodig die momenteel niet in tls aanwezig is. Op termijn zal de cryptografie worden vervangen door tls 1.3, waarin de benodigde zaken worden geïmplementeerd.

Goed, zo werkt QUIC dus. Het leuke is dat je er zelf al van kunt profiteren, althans als je de Chrome-browser gebruikt. Lees verder: QUIC inschakelen in Chrome om sneller te browsen. Ook nadelen komen aan bod.

Een wasbaar dekbed klinkt ideaal: nooit meer worstelen met een overtrek, gewoon alles in één keer in de wasmachine. Maar hoe vaak moet dat eigenlijk gebeuren? Elke week, of is dat overdreven? Het antwoord hangt af van een aantal factoren. In dit artikel lees je er meer over.

Lees ook: Wasbaar dekbed: handig of juist niet?

Bij een traditioneel dekbed vangt de losse hoes het meeste zweet en andere viezigheid op, maar bij een wasbaar dekbed vormt de buitenlaag (de tijk) samen met de vulling één geheel. Daardoor kan vuil dat normaal in de overtrek blijft sneller in het dekbed zelf trekken, wat regelmatig wassen extra belangrijk maakt.

Tegelijk is dat precies waarom zo’n dekbed in de praktijk vaak juist hygiënischer is: je doet telkens het hele dekbed, inclusief vulling, in de was. Heb je een traditioneel dekbed met een aparte hoes, dan was je die dekbedhoes waarschijnlijk eens per week of twee weken. Het dekbed zelf was je waarschijnlijk een stuk minder vaak. Dus per saldo is een dekbed zonder overtrek dus hygiënischer. Mits je het dus regelmatig wast…

Hoe vaak is regelmatig wassen?

Voor de meeste mensen volstaat het om dit dekbed eens in de één à twee weken in de wasmachine te stoppen. Slaap je in je eentje en zweet je weinig, dan kun je die twee weken aanhouden. Heb je het snel warm, deel je het bed met iemand (of een huisdier) of heb je last van allergieën, dan is wekelijks wassen beter. Zo blijft niet alleen de buitenkant schoon, maar ook de binnenkant van het dekbed.

Het is wel belangrijk dat je dat wassen op de juiste manier doet. Wasbare dekbedden kunnen best wat hebben, maar te veel draaien in de trommel kan de vezels beschadigen. Gebruik daarom een mild vloeibaar wasmiddel en sla de wasverzachter over. Zorg ook dat het dekbed genoeg ruimte heeft in de machine. Wanneer je echt moet proppen om hem erin te krijgen, schuurt de stof tegen de trommelwand en slijt het sneller.

©ID.nl

Wanneer moet je een dekbed zonder losse hoes vaker wassen?

Soms is een extra wasbeurt nodig. Ben je ziek geweest of heb je koorts gehad? Na ziekte of koorts is het verstandig het dekbed meteen te wassen op minimaal 40 graden. Kijk op het etiket om te zien of je misschien zelfs op 60 graden kunt wassen. Eet je weleens in bed en mors je koffie, thee of iets anders? Of heb je een bloedneus of een wondje? Ook dan is een extra wasbeurt geen overbodige luxe. Tot slot is het voor jezelf prettig om het dekbed in de zomer echt minimaal 1x per week te wassen. Je zweet dan nu eenmaal meer, en de nachten kunnen broeierig zijn.

Wasbaar dekbed drogen

Wil je een traditioneel dekbed drogen, dan duurt dat vaak uren. Maar omdat de vulling van wasbare dekbedden bestaat uit synthetische holle vezels, is de droogtijd een stuk korter. Kijk wel goed op het wasetiket hoe heet de droger mag staan; je kunt een iets langer programma kiezen op een lagere temperatuur dan een superkort programma dat eigenlijk te heet staat. Dat is voor een synthetische vulling niet goed.

Wasbaar dekbed? 1x per week of twee weken in de was!

Zoals je ziet valt het onderhoud eigenlijk reuze mee. Door een wasbaar dekbed wekelijks of om de week te wassen en goed te laten drogen, blijft je bed schoon en fris. Vaker is alleen in een enkel uitzonderingsgeval nodig. Al met al is het dus niet zo veel werk als je misschien denkt!

De werknemers van Sandfall Interactive, de ontwikkelaar van de vorig jaar uitgekomen game Clair Obscur: Expedition 33, zijn geridderd in Frankrijk.

De 28 Franse ontwikkelaars hebben afgelopen week de hoogst mogelijk culturele onderscheiding in Frankrijk ontvangen. Het gaat om de Orde van Kunst en Letteren. Dit vanwege hun werk aan Clair Obscur: Expedition 33.

De Franse minister van Cultuur, Rachida Dati, ridderde de werknemers. In Frankrijk worden elk jaar maximaal tweehonderd mensen geridderd voor de Orde van Kunst en Letteren. Mensen die geridderd worden moeten een significante bijdrage hebben geleverd aan de verrijking van de culturele erfgoed van het land. Eerdere mensen uit de game-industrie die ook zijn geridderd in Frankrijk, zijn Rayman-bedenker Michel Ancel en Mario-bedenker Shigeru Miyamoto.

Over Clair Obscur: Expedition 33

Clair Obscur: Expedition 33 kwam afgelopen voorjaar uit voor PlayStation 5, Xbox Series-consoles en pc. De game van Sandfall Interactive combineert traditionele turn-based rpg-gameplay met een flitsende, moderne presentatie.

In de game leeft de mensheid in een maatschappij waarin een entiteit genaamd de Paintress elk jaar de wereld opnieuw schildert. Daarbij plaatst ze een vervloekt cijfer, waardoor iedereen die de leeftijd heeft gelijk aan dat cijfer verdwijnt. In de game is het de beurt aan drieëndertigjarigen, maar een team geleid door Gustave probeert dit tegen te gaan.

Clair Obscur: Expedition 33 bleek een groot succes: het spel werd miljoenen keren verkocht en won de award voor game van het jaar tijdens The Game Awards eind vorig jaar. Dat is des te indrukwekkender wetende dat het om de debuutgame van Sandfall Interactive gaat.