TCP, UDP en poorten

Een poortnummer is 16 bits en loopt van 0 tot 65535. HTTPS-webservers luisteren op poort 443.

Eerst twee raadsels. Bij een videogesprek raakt onderweg een klein stukje stem van je vriend kwijt. Moet de app het opnieuw vragen? Nu download je een huiswerkbestand en raakt één stukje kwijt. Dezelfde vraag. Beslis over beide voordat je verder leest.

Twee ontbrekende stukjes, twee verschillende antwoorden

Zei je nee bij het gesprek en ja bij het bestand, dan heb je al tussen de twee transporten gekozen. Geluid dat een halve seconde te laat komt is nutteloos. Het gesprek is verder, dus je slaat dat stukje liever over en speelt het volgende. Een bestand met een ontbrekend stukje is kapot en daarop wachten loont. Internet heeft een transport voor elk geval: TCP wacht en verzendt opnieuw; UDP verzendt en gaat verder. Maar eerst moet een pakket het juiste programma bereiken.

Welk programma krijgt het pakket: poorten

Een IP-adres brengt een pakket naar de juiste computer. Daar draaien veel programma's tegelijk: een browser met tabs, chat, muziek. Zowel TCP als UDP bevat bron- en doelpoorten, elk een getal van 16 bits van 0 tot 65535. De poort noemt het bedoelde programma. Een server luistert op een afgesproken poort: 80 voor gewone HTTP, 443 voor HTTPS, 53 voor DNS, 25 voor mail tussen servers. RFC 6335 verdeelt ze in systeempoorten 0 tot 1023, gebruikerspoorten 1024 tot 49151 en dynamische poorten 49152 tot 65535. Je computer kiest per gesprek een tijdelijke bronpoort, vaak uit het dynamische bereik. Adres en poort samen, zoals 198.51.100.20:443, noemen één gesprekseindpunt precies.

TCP vinkt elke byte af

TCP (RFC 9293) maakt van onbetrouwbare pakketten iets als een telefoonlijn voor bytes. Eerst zetten de partijen een verbinding op met een drieweg-handshake: client stuurt SYN, server antwoordt SYN-ACK, client antwoordt ACK. Daarna krijgt elke byte een volgnummer. De ontvanger stuurt bevestigingen (ACK's) van de voortgang en zet verkeerd geordende stukken terug. Zonder ACK binnen de wachttijd stuurt de afzender gegevens opnieuw. RFC 6298 stelt de eerste wachttijd op 1 seconde en past die daarna aan de gemeten heen-en-terugreistijd aan. TCP vertraagt ook bij verlies, zodat één drukke verbinding niet wordt overspoeld.

UDP verzendt en gaat verder

UDP (RFC 768, 1980) doet veel minder. De header is maar 8 bytes: twee poorten, lengte en controlesom. Er is geen handshake, volgnummer of hertransmissie. Voor het videogesprek uit het raadsel is dat precies goed. Korte DNS-vragen gebruiken ook UDP: één vraag en antwoord gaan sneller zonder handshake. QUIC, het transport onder HTTP/3, werkt via UDP en bouwt er eigen hertransmissie bovenop.

Vier getallen houden twee tabs uit elkaar

Vier getallen identificeren één TCP-verbinding: bronadres, bronpoort, doeladres en doelpoort. Zo praat een server op poort 443 met duizenden browsers tegelijk zonder verwarring en houdt je laptop twee tabs op dezelfde site apart doordat elke verbinding een andere bronpoort gebruikt. Tik op een pakket en lees de header. Vóór de thuisrouter is de bron 192.168.0.12 poort 51000. Daarna heeft NAT beide veranderd en de router onthoudt de wissel, zodat antwoorden bij de juiste tab komen.