Is het OSI-model verkeerd?

Niet verkeerd, maar vooral academisch. Echte implementaties komen beter overeen met het vierlagenmodel van TCP/IP. De sessie- en presentatielagen in OSI verwijzen naar bibliotheekcode binnen applicatieprotocollen in plaats van naar afzonderlijke netwerkcomponenten.

Wat is het verschil tussen TCP en UDP op protocolniveau?

TCP beschikt over verbindingsinstellingen (de drieweghandshake), volgnummers per byte, hertransmissie, stroomcontrole en congestiecontrole. UDP heeft deze niet: het is gewoon "gooi dit datagram naar die IP:poort en hoop dat het aankomt." UDP is sneller, maar de applicatie heeft te maken met verlies.

Waar werken firewalls in dit model?

De meeste firewalls werken op de internet- en transportlagen: ze inspecteren IP-adressen, poortnummers en TCP-vlaggen. "Applicatiefirewalls" (ook wel applicatiegateways genoemd) inspecteren laag-4-payloads om regels af te dwingen op basis van HTTP-methoden, URL's of andere applicatie-inhoud.

Waarom vertraagt een VPN de zaken?

Drie redenen: de extra IP-inkapseling voegt 20-60 bytes per pakket toe, encryptie/decryptie gebruikt CPU en de VPN-exitserver kan fysiek verder van uw bestemming verwijderd zijn dan uw echte ISP-route. Moderne protocollen zoals WireGuard minimaliseren de eerste twee; de routeomweg onvermijdelijk is.

Geldt het TCP/IP-model nog steeds met HTTP/3?

Ja: HTTP/3 loopt via QUIC, dat via UDP op de transportlaag loopt, en dat via IP op de internetlaag loopt. De lagen zijn niet veranderd; alleen de keuze voor het transportlaagprotocol deed dat. QUIC brengt een aantal functionaliteiten (encryptie, congestiecontrole) samen in een strakker pakket.

Het TCP/IP-model uitgelegd: vier lagen, de echte internetstack

Als u slechts één netwerkmodel leert, leer dan TCP/IP. Het zevenlaags OSI-model wordt onderwezen in leerboeken; het vierlaags TCP/IP-model is waar het eigenlijke internet op draait. Begrijpen welke laag wat doet, vormt de basis voor het begrijpen van al het andere: VPN's, proxy's, NAT, firewalls, latentie.

De volledige artikeltekst vindt u hieronder in het Engels.

Het ontwerp van het internet komt uit een artikel uit 1974 van Vint Cerf en Bob Kahn waarin een gelaagde architectuur werd voorgesteld: elke laag doet één taak, praat alleen met de lagen direct erboven en eronder, en wordt onafhankelijk van de andere geïmplementeerd. Het model heeft vier lagen; alles wat je op een draad (of draadloos) aansluit, gaat er doorheen.

Laag 1: Linklaag

De onderste laag is de fysieke link tussen aangrenzende apparaten: Ethernet, Wi-Fi, glasvezel, mobiel. Het is zijn taak om stukjes op het medium te plaatsen en ze er aan de andere kant weer af te halen. Elke linktechnologie heeft zijn eigen framing, zijn eigen adressering (MAC-adressen op Ethernet/Wi-Fi) en zijn eigen foutafhandeling.

Deze laag is de enige die verschilt per fysiek medium. De rest van de stapel is hetzelfde, of u nu een mobiel netwerk, Wi-Fi of glasvezel gebruikt.

Laai 2: internetlaag

De internetlaag is de globale routeringslaag. Het protocol is IP (in v4 of v6), en het is zijn taak om een pakket van elk IP-adres naar elk ander IP-adres te krijgen, mogelijk via vele tussenliggende hops. Elke hop is een router die naar het bestemmingsadres kijkt, de bijbehorende routeringstabel raadpleegt en het pakket via de juiste link doorstuurt.

De internetlaag is het beste van zichzelf: pakketten kunnen worden verwijderd, opnieuw geordend of gedupliceerd. Het wordt niet opnieuw verzonden. Dat is het probleem van de volgende laag.

Laag 3: Transportlaag

De transportlaag verandert de best-effort IP-service in iets dat bruikbaar is voor applicaties. Twee protocollen domineren:

TCP (Transmission Control Protocol) biedt een betrouwbare, geordende bytestroom. Het verzendt verloren pakketten opnieuw, herschikt pakketten die niet in de juiste volgorde staan, controleert congestie en zorgt ervoor dat beide eindpunten ongeveer synchroon blijven. De prijs is latentie: een TCP-handshake duurt één keer heen en terug voordat er gegevensstromen plaatsvinden.
UDP (User Datagram Protocol) biedt datagrammen zonder betrouwbaarheidsgaranties. De applicatie krijgt dezelfde best-effort-service die IP biedt, plus poortnummers voor multiplexstromen. Gebruikt voor DNS, real-time audio/video, gaming, QUIC.

Beide transportlaagprotocollen gebruiken 16-bit poortnummers (0-65535) om veel stromen over één IP-adres te multiplexen.

Laai 4: Applicatielaag

De applicatielaag is alles wat u daadwerkelijk gebruikt: HTTP, HTTPS, SMTP, DNS, SSH, FTP, BitTorrent. Elk protocol definieert zijn eigen berichtformaat, semantiek en gedrag, bovenop TCP of UDP.

Dit is de laag waarin de meeste softwareontwikkelaars hun tijd doorbrengen. Het is ook waar bijna alle moderne applicatiecomplexiteit leeft – TLS, HTTP/3, QUIC, GraphQL, gRPC, WebSocket – ook al zijn de onderste drie lagen in tientallen jaren niet veranderd.

Hoe een pakket eigenlijk is flow

U klikt op een link. Uw browser opent een TCP-verbinding met example.com:443. Hier is de gelaagde uitsplitsing:

Applicatielaag: de browser construeert een HTTPS-verzoek.
Transportlaag:TCP verpakt het in een segment met bron-/bestemmingspoorten, volgnummer, controlesom.
Internet laag: IP omhult het TCP-segment met bron-/bestemmings-IP, TTL, enz.
Link-laag: Ethernet (of Wi-Fi) omhult het IP-pakket met MAC-adressen voor de volgende hop.

Het pakket raakt uw router, die het link-layer-frame verwijdert, naar de IP-header kijkt, beslist waar het naartoe moet worden doorgestuurd, omhult het in een nieuw link-layer-frame voor de volgende hop, en stuurt het door. Dit herhaalt zich op elke router totdat het pakket de server van example.com bereikt, waar de lagen zich in omgekeerde volgorde uitpakken.

TCP/IP versus OSI

Het OSI-model heeft zeven lagen: fysiek, datalink, netwerk, transport, sessie, presentatie, applicatie, en wordt in klaslokalen onderwezen. Het TCP/IP-model vouwt de onderste twee OSI-lagen samen tot één ‘linklaag’ en de bovenste drie OSI-lagen tot één ‘applicatielaag’. Het verschil tussen OSI-sessies en -presentaties bestaat in echte systemen (TLS zit daar ergens in), maar de vierlaagse TCP/IP-weergave komt beter overeen met daadwerkelijke implementaties.

Waarom dit belangrijk is voor VPNs

Een VPN-tunnel werkt door het ene pakket in het andere in te kapselen. Uw HTTP-verzoek op de applicatielaag rijdt op TCP, dat op IP rijdt, dat wordt gecodeerd en in een een ander IP-pakket wordt gestopt dat bestemd is voor de VPN-server. De VPN-server ontkapt en stuurt door. Het binnenste pakket is uw echte verkeer; het buitenste pakket verbergt het voor het lokale netwerk. Begrijpen op welke laag de inkapseling plaatsvindt (meestal IP-in-IP voor IPsec/WireGuard, TCP/UDP-in-TLS voor OpenVPN) is het verschil tussen een werkende VPN en een kapotte VPN.

Veelgestelde vragen

Is het OSI-model verkeerd?: Niet verkeerd, maar vooral academisch. Echte implementaties komen beter overeen met het vierlagenmodel van TCP/IP. De sessie- en presentatielagen in OSI verwijzen naar bibliotheekcode binnen applicatieprotocollen in plaats van naar afzonderlijke netwerkcomponenten.
Wat is het verschil tussen TCP en UDP op protocolniveau?: TCP beschikt over verbindingsinstellingen (de drieweghandshake), volgnummers per byte, hertransmissie, stroomcontrole en congestiecontrole. UDP heeft deze niet: het is gewoon "gooi dit datagram naar die IP:poort en hoop dat het aankomt." UDP is sneller, maar de applicatie heeft te maken met verlies.
Waar werken firewalls in dit model?: De meeste firewalls werken op de internet- en transportlagen: ze inspecteren IP-adressen, poortnummers en TCP-vlaggen. "Applicatiefirewalls" (ook wel applicatiegateways genoemd) inspecteren laag-4-payloads om regels af te dwingen op basis van HTTP-methoden, URL's of andere applicatie-inhoud.
Waarom vertraagt een VPN de zaken?: Drie redenen: de extra IP-inkapseling voegt 20-60 bytes per pakket toe, encryptie/decryptie gebruikt CPU en de VPN-exitserver kan fysiek verder van uw bestemming verwijderd zijn dan uw echte ISP-route. Moderne protocollen zoals WireGuard minimaliseren de eerste twee; de routeomweg onvermijdelijk is.
Geldt het TCP/IP-model nog steeds met HTTP/3?: Ja: HTTP/3 loopt via QUIC, dat via UDP op de transportlaag loopt, en dat via IP op de internetlaag loopt. De lagen zijn niet veranderd; alleen de keuze voor het transportlaagprotocol deed dat. QUIC brengt een aantal functionaliteiten (encryptie, congestiecontrole) samen in een strakker pakket.