TCP/IP: wat is het, protocolstack en gegevensoverdracht

Wat is TCP/IP?

TCP/IP (Transmission Control Protocol / Internet Protocol) is een protocolstack ontwikkeld in de jaren 1970 voor ARPANET, die de facto standaard is geworden voor het wereldwijde internet. Het bepaalt hoe gegevens worden opgedeeld in pakketten, geadresseerd, verzonden en samengesteld aan de kant van de ontvanger.

De architectuur van TCP/IP is gebaseerd op een gelaagd principe, waarbij elke laag specifieke functies abstraheert. De toepassingslaag werkt met applicatiegegevens, de transportlaag zorgt voor betrouwbaarheid, de netwerklaag verzorgt routering en de linklaag verzorgt transmissie via het fysieke medium. Modulariteit maakt het mogelijk om protocollen binnen een laag te vervangen zonder aangrenzende lagen te wijzigen.

In mobiele ontwikkeling wordt TCP/IP gebruikt door elke applicatie die netwerkverzoeken uitvoert. De bibliotheken URLSession, OkHttp, AFNetworking en Alamofire werken bovenop deze stack en verbergen de details van pakketverpakking en routering voor de ontwikkelaar. Het begrijpen van TCP/IP is echter noodzakelijk voor prestatie-optimalisatie: het configureren van TCP-parameters via URLSessionConfiguration maakt het mogelijk om time-outs te beheren, HTTP Persistent Connections te onderhouden en proxy's in te stellen voor bedrijfsomgevingen.

Begrip van TCP/IP is noodzakelijk voor het diagnosticeren van netwerkproblemen: als een applicatie geen verbinding kan maken met de server, kan het probleem op elke laag van de stack liggen — van het fysieke kanaal tot het toepassingsprotocol. Hulpmiddelen zoals tcpdump, Wireshark en Charles Proxy maken het mogelijk om verkeer op elke laag te analyseren en knelpunten te vinden. Voor mobiele ontwikkelaars biedt Xcode een Network Debug Dashboard en Android Studio een Network Inspector voor realtime analyse van TCP-verbindingen.

Lagen van het TCP/IP-model

Het TCP/IP-model omvat vier lagen, die elk strikt gedefinieerde functies vervullen bij gegevensoverdracht. Begrip van deze hiërarchie is noodzakelijk voor het diagnosticeren van netwerkproblemen en het optimaliseren van applicaties.

Toepassingslaag

Op de toepassingslaag werken protocollen waarmee applicaties direct interageren: HTTP, HTTPS, FTP, SMTP, DNS, WebSocket. Deze laag vormt gegevens in een formaat dat begrijpelijk is voor de applicatie en geeft ze door aan de transportlaag. Ontwikkelaars van mobiele applicaties werken op deze laag via netwerkbibliotheken.

Transportlaag

De transportlaag zorgt voor gegevensoverdracht tussen applicaties op verschillende apparaten. Belangrijkste protocollen: TCP (betrouwbare overdracht met bevestiging) en UDP (snelle overdracht zonder garanties). TCP voegt aan gegevens de poort van verzender en ontvanger toe, beheert de pakketvolgorde en controleert netwerkcongestie.

Netwerklaag en linklaag

De netwerklaag wordt geïmplementeerd door het IP-protocol, dat adressering (IPv4, IPv6) en pakketroutering bepaalt. Elk pakket bevat het IP-adres van verzender en ontvanger, en routers op het transmissiepad beslissen over het volgende knooppunt op basis van routeringstabellen. IPv4 gebruikt 32-bits adressen (ongeveer 4,3 miljard), en IPv6 gebruikt 128-bits adressen, wat het probleem van adresuitputting oplost.

De linklaag werkt met het fysieke transmissiemedium: Ethernet, Wi-Fi, Bluetooth. Deze laag zet pakketten om in signalen en omgekeerd, beheert de toegang tot het transmissiemedium via MAC-adressen en detecteert fouten op fysiek niveau met behulp van framecontrolesommen (FCS).

Op de linklaag werken protocollen zoals ARP (Address Resolution Protocol), dat IP-adressen omzet in MAC-adressen van apparaten in het lokale netwerk, en PPP (Point-to-Point Protocol), gebruikt in VPN-verbindingen en mobiele datanetwerken.

Hoe werkt het TCP-protocol

TCP (Transmission Control Protocol) is een van de belangrijkste protocollen van de transportlaag. Het zorgt voor betrouwbare, geordende en op fouten controleerbare levering van een bytestroom tussen applicaties. Vóór gegevensoverdracht brengt TCP een verbinding tot stand via een three-way handshake.

De three-way handshake begint met het verzenden van een SYN-pakket door de client. De server antwoordt met een SYN-ACK-pakket, waarmee de ontvangst wordt bevestigd. De client voltooit de handshake met een ACK-pakket, waarna de gegevensoverdracht begint. Dit proces garandeert dat beide partijen klaar zijn voor uitwisseling en gesynchroniseerd zijn wat betreft volgnummers.

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(('example.com', 80))
sock.send(b'GET / HTTP/1.1\r\nHost: example.com\r\n\r\n')
response = sock.recv(4096)
print(response.decode())
sock.close()

In het voorbeeld wordt een TCP-socket van het type SOCK_STREAM gemaakt, die bij het aanroepen van connect automatisch de three-way handshake uitvoert. De methode send verzendt een HTTP-verzoek, recv ontvangt het antwoord. Na voltooiing stuurt close een FIN-pakket voor het correct sluiten van de verbinding.

TCP-server met clientverwerking

Laten we een voorbeeld bekijken van een TCP-server in Python die meerdere clients via threads accepteert. Elke verbinding wordt in een aparte thread verwerkt, waardoor meerdere clients gelijktijdig kunnen worden bediend zonder de hoofdloop te blokkeren.

import socket
import threading

def handle_client(conn, addr):
    print(f'Client verbonden: {addr}')
    with conn:
        while True:
            data = conn.recv(1024)
            if not data:
                break
            conn.sendall(data.upper())
    print(f'Client {addr} verbroken')

server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind(('0.0.0.0', 9090))
server.listen(5)
print('TCP-server gestart op poort 9090')

while True:
    conn, addr = server.accept()
    thread = threading.Thread(target=handle_client, args=(conn, addr))
    thread.start()

De TCP-server verwerkt elke verbinding in een aparte thread door accept in een oneindige lus aan te roepen. De functie handle_client ontvangt gegevens, converteert ze naar hoofdletters en stuurt ze terug via sendall. Wanneer de recv-lus eindigt (wanneer de client de verbinding heeft gesloten), eindigt de thread en wordt de socket automatisch gesloten. In mobiele applicaties wordt dergelijk laag-niveau werk met sockets niet direct gebruikt — mobiele HTTP-bibliotheken beheren verbindingen via threadpools en hergebruiken automatisch TCP-verbindingen.

Verschillen tussen TCP en UDP

De keuze tussen TCP en UDP is een van de belangrijkste beslissingen bij het ontwerpen van netwerkcommunicatie. TCP garandeert levering, volgorde en integriteit van gegevens ten koste van extra vertraging. UDP offert betrouwbaarheid op voor minimale vertraging en minder belasting van het kanaal.

Voor mobiele applicaties hangt de protocolkeuze af van het scenario: REST-API en gegevensdownload vereisen TCP, terwijl videogesprekken en online games profiteren van de snelheid van UDP. Sommige applicaties combineren beide protocollen — TCP voor beheer en UDP voor mediastreaming. Het moderne QUIC-protocol, dat bovenop UDP werkt en wordt gebruikt in HTTP/3, combineert de voordelen van beide benaderingen en wordt al standaard ondersteund op iOS en Android via URLSession.

TCP/IP-codevoorbeelden

Laten we een voorbeeld bekijken van een TCP-client in Python met foutafhandeling en time-out. Deze benadering wordt gebruikt in mobiele applicaties voor een betrouwbare verbinding met de server.

import socket
import sys

def tcp_client(host, port):
    try:
        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        sock.settimeout(10)
        sock.connect((host, port))
        print(f'Verbonden met {host}:{port}')
        return sock
    except socket.error as err:
        print(f'Verbindingsfout: {err}')
        sys.exit(1)

sock = tcp_client('api.example.com', 443)
sock.close()

De functie tcp_client ontvangt een host en poort, maakt een socket met een time-out van 10 seconden en probeert verbinding te maken. Bij een verbindingsfout — bijvoorbeeld server onbereikbaar of firewallblokkade — wordt een uitzondering gegenereerd met een beschrijving van het probleem. In mobiele applicaties is de verbindingstime-out cruciaal: te kort leidt tot valse fouten op langzame netwerken, te lang tot het vastlopen van de interface. De aanbevolen waarde voor mobiele netwerken is 10–15 seconden voor timeoutIntervalForRequest en 30–60 seconden voor timeoutIntervalForResource in de URLSession-configuratie.