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.

Met de introductie van een nieuwe Home-architectuur heeft Apple de ondersteuning voor de iPad als centrale woninghub stopgezet. Gebruikers moeten nu overstappen op een Apple TV of HomePod om hun slimme apparaten op afstand te bedienen en automatiseringen uit te voeren.

Het idee was altijd zo handig: die oude tablet die toch maar in de kast lag te verstoffen kreeg een tweede leven als het brein van je woning. Je plakte hem tegen de muur of zette hem op een standaard in de keuken, en plotseling kon je overal ter wereld je lampen bedienen. Toch merkten veel gebruikers dat de betrouwbaarheid vaak te wensen overliet, met apparaten die niet reageerden of automatiseringen die simpelweg weigerden te starten. Apple heeft nu de knoop doorgehakt en de tablet officieel uit de lijst van ondersteunde hubs geschrapt. In dit artikel leggen we uit waarom deze besluitvorming logisch is en wat dat voor jouw huidige opstelling betekent.

Overstap naar een stabiele architectuur

De reden dat de tablet niet langer als hub fungeert, ligt diep in de softwarematige fundering van de Woning-app verborgen. Met de komst van de nieuwe architectuur in iOS 16.2 heeft Apple de manier waarop apparaten met elkaar communiceren volledig herzien. Waar de iPad voorheen als een soort tussenstation fungeerde dat af en toe signalen doorgaf, vereist het nieuwe systeem een apparaat dat altijd aan de stroom hangt en een constante, bekabelde of zeer stabiele draadloze verbinding heeft.

We hebben in onze tests gemerkt dat een iPad die in de slaapstand gaat of waarvan de batterij net onder een bepaald percentage zakt, de communicatie met de rest van het huis direct verstoort. Bovendien ontbreekt in de iPad de hardware voor Thread, een netwerkprotocol dat zorgt dat apparaten razendsnel en zonder vertraging op elkaar reageren. Wanneer je nu op een knop drukt, hoor je bij een moderne hub direct de klik van de schakelaar, terwijl de iPad daar voorheen merkbare seconden over kon doen.

©PHILIPPE RAMAKERS

Soms werkte het wel...

In een heel specifieke context kon de iPad nog wel dienstdoen, mits je geen behoefte had aan de nieuwste snufjes. Voor een simpel huishouden met slechts een paar lampen die alleen via bluetooth of een eigen bridge werkten, was de tablet een prima interface. Het gaf toch een gevoel van controle om een visueel overzicht te hebben op een groot scherm in de woonkamer. Je kon de iPad inzetten als een soort veredelde afstandsbediening die ook toevallig de automatiseringen draaide wanneer je zelf niet thuis was.

Dit werkte vooral goed in kleine appartementen waar de afstand tussen de tablet en de slimme verlichting minimaal was, waardoor de bluetooth-verbinding stabiel bleef. De koopintentie voor een iPad was in die tijd vaak gebaseerd op deze multifunctionaliteit, maar die vlieger gaat met de huidige eisen voor een modern slim huis niet meer op.

Mobiliteit is niet goed voor een hub

Een centraal zenuwstelsel van een woning hoort niet verplaatsbaar te zijn, en dat is precies waar het in de praktijk misging met de iPad. Zodra iemand de tablet van de lader haalde om even op de bank een video te kijken, liep de verbinding met de beveiligingscamera buiten gevaar. We zien vaak dat een hub die op wifi werkt in plaats van via een ethernetkabel, kwetsbaar is voor storingen van andere apparaten in de buurt.

De iPad is ontworpen als een persoonlijk apparaat dat energie bespaart zodra het scherm uitgaat, wat natuurlijk haaks staat op de rol van een server die 24 uur per dag paraat moet staan. In grotere woningen merkten we bovendien dat de iPad simpelweg het bereik niet had om apparaten op de bovenverdieping aan te sturen, iets wat een systeem met meerdere verdeelde hubs veel beter oplost.

©IHAR ULASHCHYK

Signalen om over te stappen

Er zijn een paar duidelijke situaties waarin je de iPad als hub direct moet vervangen door een volwaardige slimme speaker of mediaspeler. Als je van plan bent om apparaten aan te schaffen die met de Matter-standaard werken, heb je eigenlijk geen keuze meer, aangezien de iPad dit protocol niet ondersteunt als hub. Ook wanneer je merkt dat je automatiseringen vaker niet dan wel werken zodra je de voordeur achter je dichttrekt, is dat een teken dat de iPad de verbinding niet stabiel kan houden.

Een ander breekpunt is de behoefte aan beveiligde video-opslag in iCloud. Voor het streamen en analyseren van beelden van je deurbel is simpelweg meer rekenkracht en een constantere verbinding nodig dan een (vaak oudere) tablet kan bieden. Tot slot is het onmogelijk om de woning te upgraden naar de nieuwste softwareversies zonder een ondersteunde hub, waardoor je bijvoorbeeld nieuwe functies en beveiligingsupdates misloopt.

De juiste opvolger kiezen

Het toetsen van je eigen woonsituatie begint bij de vraag hoeveel apparaten je wilt aansturen en of je ook behoefte hebt aan een fysieke interface. Voor de meeste mensen is een mediaspeler zoals de Apple TV de beste keuze, omdat deze (de duurdere versies in elk geval) met een kabel aan je router verbonden kan worden voor de meest betrouwbare verbinding.

Heb je echter geen televisie in de buurt van je slimme apparaten, dan is een compacte speaker die ook als hub fungeert een slimmer alternatief. Je plaatst deze eenvoudig op een centrale plek in huis waar de microfoons ook je stemcommando's kunnen opvangen. Kijk hierbij goed naar de ruimte die je hebt; een kleine speaker past op elk nachtkastje, terwijl een volwaardige mediaspeler vaak een vaste plek in het tv-meubel vereist.

Nee, de iPad is definitief geen woninghub meer

De iPad kan officieel niet meer als hub worden ingesteld in de vernieuwde Woning-app van Apple omdat de hardware niet voldoet aan de eisen van de nieuwe woningarchitectuur. Voor het bedienen van je huis op afstand en het configureren van automatiseringen heb je nu minimaal een HomePod of een Apple TV nodig (mocht je wel bij Apple willen blijven). Deze apparaten bieden ondersteuning voor Thread en Matter, wat zorgt voor een snellere en betrouwbaardere communicatie tussen je slimme apparaten. Hoewel de iPad een handig bedieningspaneel blijft voor op de muur, vinden de processen achter de schermen nu plaats op hardware die altijd met het stroomnetwerk en internet is verbonden.

We hebben een bom-volle aflevering met de review van Mario Tennis Fever en Dwayne's previews van Pokémon Pokopia, Resident Evil Requiem, Pragmata en de Super Mario Bros. Wonder-dlc!

Kom bij onze Discord. Via ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠deze link⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠kan je met ons en andere luisteraars kletsen over games, deals, nieuws en meer.

Wil je zelf ook een vraag insturen of heb je iets leuks om te melden? Dat kan! Stuur een mailtje naar bonuslevelcast@gmail.com (of bonuslevelkast@gmail.com of bonuslevelqast@gmail.com) en wellicht hoor je jezelf terug in de volgende aflevering!