TCP/IP

Het OSI-model is een leermodel. Wat het internet in de praktijk gebruikt, is de TCP/IP-stack: vier lagen, genoemd naar de twee protocollen die het meeste werk doen.

Laag	Taak	Protocollen
Applicatie	Wat je wil bereiken	HTTP, DNS, SMTP, SSH, TLS
Transport	Hoe de gegevens aankomen	TCP, UDP
Internet	Waar de gegevens heen moeten	IP
Netwerktoegang	Hoe ze fysiek vertrekken	Ethernet, Wi-Fi

Op deze pagina staat de transportlaag centraal: de keuze tussen TCP en UDP. Die keuze bepaalt of je verbinding betrouwbaar is of snel, en ze verklaart waarom een bestand nooit half aankomt terwijl een videogesprek wel eens hapert.

IP levert af, maar belooft niets

De internetlaag doet één ding: een pakket met een bestemmingsadres van router naar router duwen. Meer niet. IP garandeert niet dat een pakket aankomt, niet dat pakketten in volgorde aankomen, en niet dat er geen dubbels zijn.

Dat klinkt onbetrouwbaar, en dat is het ook. Bewust: hoe eenvoudiger de tussenliggende routers, hoe sneller en robuuster het netwerk. Wie garanties wil, regelt die aan de uiteinden. Precies daarvoor bestaat de transportlaag.

TCP: betrouwbaar en geordend

TCP (Transmission Control Protocol) bouwt bovenop dat onbetrouwbare IP een verbinding waarop je kan rekenen.

De verbinding opzetten

Voor er data verstuurd wordt, spreken beide kanten af dat ze verbonden zijn. Dat gebeurt met de drieweg-handdruk:

client                                server
  │  ──────────── SYN ─────────────►    │   "ik wil een verbinding"
  │  ◄────────── SYN, ACK ──────────    │   "goed, en ik ook"
  │  ──────────── ACK ─────────────►    │   "afgesproken"
  │                                     │
  │  ═══════ verbinding staat ══════    │

Deze drie pakketten zijn wat je in Wireshark terugvindt met het filter tcp.flags.syn == 1, en wat in DevTools als de fase Initial connection verschijnt.

Het volledige leven van een verbinding, van de eerste SYN tot de laatste ACK:

De handdruk in amber is het deel dat je in deze les moet kennen. Het afsluiten verloopt in twee richtingen: elke kant stuurt een eigen FIN en krijgt daar een ACK op, want een verbinding kan in de ene richting al dicht zijn terwijl de andere nog data stuurt.

Wat TCP daarna garandeert

Garantie	Hoe TCP dat doet
Alles komt aan	De ontvanger bevestigt elk stuk met een ACK. Blijft die uit, dan stuurt de zender opnieuw
In de juiste volgorde	Elk segment krijgt een sequentienummer; de ontvanger legt ze in de juiste volgorde terug
Zonder dubbels	Dubbel ontvangen segmenten herkent de ontvanger aan datzelfde nummer
Zonder de ontvanger te overspoelen	Met flow control zegt de ontvanger hoeveel hij nog aankan
Zonder het netwerk te verstikken	Met congestion control vertraagt de zender zodra er pakketten verloren gaan

Op het einde wordt de verbinding netjes afgesloten met FIN-pakketten, zodat beide kanten weten dat er niets meer volgt.

Die zekerheid kost tijd: een handdruk vooraf, bevestigingen onderweg, en wachten op wat ontbreekt. Voor een bestand, een pagina of een mail is dat de juiste afweging.

UDP: snel en zonder beloftes

UDP (User Datagram Protocol) doet nauwelijks meer dan IP: het voegt poortnummers en een controlegetal toe, en verstuurt.

Geen handdruk, geen bevestigingen, geen volgorde, geen hertransmissie. Een pakket vertrekt en de zender kijkt niet om.

Dat is geen gebrek maar een keuze. Bij een videogesprek is een beeldje dat 200 ms te laat aankomt waardeloos: je wil niet dat het opnieuw verstuurd wordt, je wil het volgende beeldje. Wat bij een download een fout is, is bij live verkeer de beste optie.

TCP of UDP?

	TCP	UDP
Verbinding	Ja, met handdruk	Nee
Aankomst gegarandeerd	Ja	Nee
Volgorde gegarandeerd	Ja	Nee
Snelheid	Trager door de garanties	Sneller, minder overhead
Headergrootte	20 bytes of meer	8 bytes
Typisch gebruik	Web, mail, SSH, bestandsoverdracht, databanken	DNS, videogesprekken, games, streaming

Eén vraag beslist het meestal

Is een ontbrekend stukje erg genoeg om erop te wachten? Ja: TCP. Nee, want tegen dat het er is, is het al achterhaald: UDP.

HTTP/3 breekt met de gewoonte

HTTP/1.1 en HTTP/2 draaien op TCP. HTTP/3 gebruikt QUIC, dat bovenop UDP gebouwd is en de betrouwbaarheid zelf regelt. Zo vermijdt het een nadeel van TCP: bij één verloren pakket blokkeert daar de hele stroom, ook voor gegevens die eigenlijk al binnen zijn.

Test jezelf: TCP of UDP?

1.Een installatiebestand van 2 GB downloaden

2.Een videogesprek in Teams of Discord

3.Inloggen op een server met SSH

4.Een DNS-opzoeking van één domeinnaam

5.Positie-updates in een online game

6.Een webpagina opvragen met HTTPS over HTTP/2

7.Een e-mail versturen via SMTP

8.Een livestream waarbij een gemist beeldje niet erg is

Dit zelf zien in Wireshark

Alles op deze pagina is zichtbaar in een opname van enkele seconden:

Filter	Wat je te zien krijgt
tcp.flags.syn == 1	Elke handdruk in je opname: SYN van de client, SYN, ACK van de server
tcp	De volledige stroom, met sequentienummers en ACK's per pakket
udp	Verkeer zonder handdruk, meestal DNS en streaming
dns	De naamsvertalingen, doorgaans één vraag- en één antwoordpakket over UDP

Klik een TCP-pakket aan en klap het open: je ziet het Ethernet-frame, daarin het IP-pakket, daarin het TCP-segment, en daarin pas je HTTP-bericht. Dat is encapsulatie zoals ze echt over de lijn gaat.

Onthoud

• IP levert pakketten af zonder garanties; de transportlaag voegt toe wat je nodig hebt.
• TCP zet eerst een verbinding op met de drieweg-handdruk (SYN, SYN-ACK, ACK) en garandeert daarna aankomst, volgorde en het uitblijven van dubbels.
• UDP verstuurt zonder handdruk en zonder garanties: minder overhead, minder vertraging.
• Kies TCP wanneer volledigheid telt, UDP wanneer actualiteit telt.
• HTTP/3 is de uitzondering: dat draait via QUIC over UDP.