Op deze website gebruiken we cookies om content en advertenties te personaliseren, om functies voor social media te bieden en om ons websiteverkeer te analyseren. Ook delen we informatie over uw gebruik van onze site met onze partners voor social media, adverteren en analyse. Deze partners kunnen deze gegevens combineren met andere informatie die u aan ze heeft verstrekt of die ze hebben verzameld op basis van uw gebruik van hun services. Meer informatie.

Akkoord
abonneren

Ipv6, TCP-UDP, http/2: Zo werken netwerkprotocollen

Computers communiceren met elkaar aan de hand van protocollen, zoals ipv6 (en nog steeds ipv4), TCP/UDP en http/2. In dit artikel gaan we dieper in op de werking ervan.

Verschil TCP en UDP

Wanneer je het vereenvoudigde osi-model bekijkt (links in bovenstaande afbeelding), merk je dat er heel wat vertrouwde protocollen in de applicatielaag actief zijn. De meeste ervan gebruiken (ook) tcp voor het datatransport oftewel de communicatie tussen applicaties op de verschillende computers. Dat geldt bijvoorbeeld voor ftp, smtp, pop3, imap, irc, http(s), enz.

Een minderheid van de applicatieprotocollen zet vooral in op udp, met name tools voor mediastreaming en voor lokale broadcastmechanismen als dhcp. Dat is uiteraard niet toevallig zo. Terwijl tcp (transmission control protocol) er vooral is op gericht om data op een zo betrouwbaar mogelijke manier naar de bestemming te krijgen, gaat het bij udp vooral om snelheid en dus zo weinig mogelijk overhead.

Tcp bevat daarom diverse controlemechanismen die aan een meer solide dataoverdracht bijdragen, waaronder foutdetectie en -correctie (met behulp van checksums), ontvangstcontrole (via (n)ack-responses; acknowledgement = bevestiging) en flowcontrole (om buffer overruns/underruns te vermijden wanneer er meer/minder data worden verstuurd dan de databuffer aan de ontvangstzijde kan bevatten).

Enkele van deze tcp-parameters worden zichtbaar wanneer je bijvoorbeeld op een Windows-computer een tcp-query uitvoert met netsh interface tcp show global. Op het internet vind je weliswaar heel wat zogezegd ‘ultieme tips’ om precies deze en dergelijke tcp-parameters te finetunen voor een snellere datatransfer, maar in de meeste gevallen kun je er rustig van uitgaan dat het besturingssysteem die al optimaal heeft ingesteld.

TCP Optimizer

Speedguide.net biedt sinds jaar en dag een portable Windows-optimalisatietool aan voor het tcp-protocol: TCP Optimizer. Terwijl dat bij oudere Windows-versies vaak erg zinvol was, met name in combinatie met snelle internetverbindingen, is dat nu veel minder het geval. Toch blijft het een gebruiksvriendelijke tool voor wie toch aan de tcp-parameters wilt sleutelen.

Een veilige tool ook, althans als je via File, Backup current settings eerst je actuele instellingen in een bestand vastlegt, zodat je altijd nog terug kunt via de optie Restore backed up settings. Verder is de online documentatie bij de tool niet alleen zeer nuttig als leidraad bij je optimalisatiepogingen, maar tevens als achtergrondinformatie.

Verschil ipv4 en ipv6

Na de transportlaag belanden datapakketjes aan afzenderkant in de netwerk- of internetlaag. Die zorgt er in eerste instantie voor dat er datatransfer mogelijk is tussen twee computers in een wan en het is op deze laag dat het ip-protocol opereert. Dit protocol, verantwoordelijk voor het correct adresseren van de pakketjes, tracht de optimale route te vinden van bron naar bestemming. In de afbeelding zie je de inhoud van een willekeurige ip-header, afkomstig van een Wireshark-sessie en die geeft heel goed de typische opbouw van zo’n header weer.

Merk op dat het in ons voorbeeld om een ipv4-variant gaat (version 4) en zo’n adres bevat slechts 32-bit. Dat laat een theoretische adresruimte van 232 of circa 4,3 miljard adressen toe, maar om historische redenen zijn er in de praktijk lang niet zoveel adressen beschikbaar. Mede dankzij private adresbereiken (10/8,172.16/12, 192.168/16), flexibele cidr-notaties (die de grootte van een netwerk/subnet beter bij de behoefte laten aansluiten) en de nat-technologie heeft men dit groeiende gebrek aan ip-adressen lange tijd kunnen maskeren.

Intussen is echter de behoefte aan meer adressen steeds urgenter geworden en daar zijn ontwikkelingen als IoT (internet of things) natuurlijk debet aan. Gelukkig biedt ipv6, met een adresruimte van maar liefst 2128 (zegt 340 undeciljoen je iets?), een uitweg. Daarbij komt dat ipv6 ook in gegevensbeveiliging tijdens het transport voorziet, terwijl ipv4 daar nog aparte protocollen voor nodig heeft, zoals vpn, ssh en https.

In Nederlands was XS4ALL de eerste grote provider die ipv6 ‘native’ aanbood (naast ipv4 en zonder tunnelingprotocol), maar intussen zit ook bij de meeste anderen ipv6 in het aanbod. Veel providers bieden weliswaar native ipv6 aan inclusief ipv6-router, maar er zijn ook nog behoorlijk wat providers waarbij geïnteresseerde gebruikers zelf een tunnel moeten opzetten op basis van een publiek ipv4-adres, bijvoorbeeld via Hurricane Electric.

Wil je zelf nagaan of je over een publiek ipv6-adres beschikt en in hoeverre je ipv6-verbinding functioneert, dan kun je dat doen op test-ipv6.com. Let wel, meldt de test dat je niet over een ipv6-adres blijkt te beschikken, ga dan toch ook even na in de webinterface van je router of ipv6 daar niet is uitgeschakeld. Verder kun je op https://ip6.nl controleren in hoeverre jouw internetdomein – of dat van een ander – klaar is voor ipv6.

Http/2 en spdy

De tcp/ip-stack en alle netwerkprotocollen errond zijn dus absoluut geen statisch gegeven. Er wordt voortdurend aan bestaande protocollen gesleuteld en er worden ook nieuwe protocollen toegevoegd. Al deze wijzigingen toelichten zou echter veel meer dan een artikel, of zelfs een lijvig boek, vereisen. We beperken ons daarom tot één exemplarische ontwikkeling, met name van een applicatieprotocol dat je zelf ook dagelijks tig keren gebruikt: http.

Het http-protocol bestaat al meer dan twintig jaar en intussen is het web van een statische, tekst-gebaseerde database uitgegroeid tot een interactieve, dynamische omgeving, wat maakt dat het oude protocol niet meer voldoende presteert.

Google ontwikkelde daarom spdy (ook wel speedy genoemd), een alternatief openbron-netwerkprotocol voor het versturen van web-inhoud. Spdy leverde veelal een hogere transmissiesnelheid op dan http (1.1), met name door data te comprimeren, te prioriteren en te multiplexen (meerdere datastromen mogelijk over een enkele tcp-verbinding).

Intussen werd de volgende versie van http geratificeerd, http/2 (rfc 7540), die deels op spdy is gebaseerd en vergelijkbare of betere prestaties neerzet – zozeer zelfs dat Google spdy niet langer officieel ondersteunt. Uitgebreide achtergrondinformatie vind je hier.

Nagenoeg alle browsers ondersteunen intussen ook http/2, zij het meestal alleen over tls (transport layer security) – wat de facto encryptie afdwingt. Het is dus ook niet zo vreemd dat Google gewone http-sites in het vizier heeft: minder goede zoekresultaten en binnenkort een waarschuwing in Chrome dat je je in dat geval met een onveilige pagina verbindt als die ook privacygevoelige informatie opvraagt. Veiligheid voor alles, toch?

De meeste browsers ondersteunen dus http/2 (over tls), maar aan de zijde van de websites is dat vooralsnog beperkt. Wil je nagaan in hoeverre een bezochte website ondersteuning biedt voor spdy of http/2, dan kun je Firefox gebruiken in combinatie met de add-on HTTP/2 and SPDY indicator. Een pictogram maakt dan duidelijk via welk protocol je browser met de site is verbonden. Sites als Google en Facebook ondersteunen http/2 op tld-niveau (top level domain).

Tekst: Toon van Daele

Geschreven door: Redactie PCM op

Category: Nieuws

Tags: netwerk, internet, Ipv6, Ipv4, udp, tcp, http2

Nieuws headlines

Laatste reactie