TCP/IP-Grundlagen: Wie Daten durchs Netz kommen

Jede Website, jede E-Mail, jeder SSH-Zugriff läuft über TCP/IP – den fundamentalen Protokoll-Stack des Internets. Wer versteht, wie die Schichten zusammenarbeiten, kann Netzwerkprobleme gezielt eingrenzen und Infrastruktur sauber planen. Dieser Artikel erklärt das Modell, die wichtigsten Protokolle und die typischen Fehlerbilder.

Das Schichtenmodell: Das Internet ist ein Stapelkuchen

TCP/IP wird meist in vier Schichten beschrieben:

Netzzugang (Link Layer): Ethernet, WLAN, Glasfaser – überträgt Frames zwischen direkt verbundenen Geräten. Hier arbeitet die MAC-Adresse.
Internet (Internet Layer): IP (IPv4/IPv6) – kümmert sich um Adressierung und Routing zwischen Netzen. ICMP (ping, traceroute) lebt hier.
Transport (Transport Layer): TCP und UDP – bringen Daten zu den richtigen Prozessen (Ports) und regeln Zuverlässigkeit.
Anwendung (Application Layer): HTTP, DNS, SMTP, SSH – die Protokolle, die Anwendungen direkt nutzen.

Jede Schicht kapselt die darüberliegende: Der Browser schickt einen HTTP-Request (Schicht 4+), der in TCP-Segmente, dann IP-Pakete, dann Ethernet-Frames verpackt wird – und am Ziel in umgekehrter Reihenfolge wieder ausgepackt.

IP: Adressierung und Routing

Jedes Gerät hat eine IP-Adresse (siehe Subnetting verstehen). Router verbinden Netze: Sie schauen sich das Ziel-IP-Präfix an und leiten das Paket zum nächsten Hop weiter – so entsteht der Weg durchs Internet. Zwei Spezialfälle:

Private Adressen (RFC 1918): 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 – nicht im Internet routbar, werden per NAT übersetzt.
Loopback: 127.0.0.1 – das eigene Gerät („localhost").

NAT (Network Address Translation): Der Router ersetzt private Quelladressen durch seine öffentliche Adresse und merkt sich die Zuordnung. So können hunderte Geräte hinter einer einzigen öffentlichen IP ins Internet. Nachteil: Eingehende Verbindungen brauchen Port-Forwarding – relevant für Server und VPNs.

TCP: Zuverlässige Verbindungen

TCP stellt sicher, dass Daten vollständig und in Reihenfolge ankommen. Der Drei-Wege-Handshake etabliert eine Verbindung:

Client → SYN          (ich möchte verbinden)
Server → SYN-ACK      (ok, ich bin bereit)
Client → ACK          (Verbindung steht)

Danach läuft ein Bestätigungs- und Wiederholungsmechanismus: Jedes Segment wird mit einer Sequenznummer versehen, Empfänger bestätigen mit ACK, Verlorenes wird erneut gesendet. Der Verbindungsaufbau ist die Erklärung für „langsames erstes Laden" und für viele Firewall-Logs.

Wichtige TCP-Ports (Auszug):

Port	Dienst
22	SSH
25/587	SMTP (Mail-Versand)
80/443	HTTP/HTTPS
53	DNS
3306	MySQL/MariaDB

UDP: Schnell und ohne Garantie

UDP hat keinen Handshake, keine Bestätigung, keine Reihenfolge-Garantie – dafür minimale Latenz. Ideal für: DNS-Abfragen (eine Frage, eine Antwort), Video-/VoIP-Streams, Gaming, DHCP. Wer ein Echtzeit-Problem hat, prüft zuerst, ob UDP-Pakete die Firewall passieren – das ist die häufigste Fehlerquelle bei VPNs (WireGuard/OpenVPN) und Sprachanwendungen.

ICMP: Der Netzwerk-Selbsttest

ICMP ist kein Transport für Nutzdaten, sondern für Statusmeldungen. Die bekanntesten Werkzeuge:

ping 8.8.8.8 – prüft Erreichbarkeit und Latenz (Echo Request/Reply).
traceroute 8.8.8.8 – zeigt jeden Hop mit Latenz (TTL-Erhöhung).
Fehlermeldungen wie „Destination Host Unreachable" oder „TTL expired".

Viele Firewalls blockieren ICMP – dann schlägt ping fehl, obwohl der Dienst läuft. Umgekehrt: Wenn ping durchgeht, aber HTTPS nicht, liegt das Problem meist auf Port 443, nicht am Netz (siehe HTTP/HTTPS-Grundlagen).

Ports und Dienste gezielt prüfen

Ping sagt nur „Host erreichbar". Ob der Dienst wirklich läuft, prüft man am Port:

# Verbindung zu Port 443 testen (3 Sekunden Timeout)
nc -zv -w 3 hanse-computing.de 443

# Offene Ports des eigenen Rechners
ss -tulpn | head -30

# Alle Verbindungen zu einem Dienst
ss -tn state established '( sport = :22 )'

ss ist der moderne Ersatz für das veraltete netstat. Damit sieht man sofort, ob ein Dienst lauscht (LISTEN) und welche Verbindungen aktiv sind. Für die Fern-Diagnose: curl -v https://ziel.de zeigt jeden Schritt des TLS-Handshakes – die Antwort „Connection refused" bedeutet: Port zu, Dienst aus oder Firewall blockiert. Mehr zur Absicherung: Firewall-Grundlagen.

Latenz und Paketverlust messen

„Das Netz ist langsam" ist die häufigste vage Beschreibung. Zahlen schaffen Klarheit:

# 20 Pings, Statistiken am Ende
ping -c 20 8.8.8.8

# MTR: kombiniert traceroute und Ping-Statistik pro Hop
mtr -r -c 20 8.8.8.8

mtr zeigt pro Zwischenstation Verlust und Latenz – so sieht man, ob der Flaschenhals beim eigenen Provider, im Transit oder am Ziel liegt. Einzelne verlorene Pakete sind normal (Netzwerk-Kongestion), aber konstanter Verlust über 5 % an einem Hop deutet auf ein echtes Problem hin.

Typische Fehlerbilder und Diagnose-Reihenfolge

# 1. Lokale Konfiguration prüfen
ip addr
ip route

# 2. Erreichbarkeit des Gateways
ping -c4 192.168.1.1

# 3. Öffentliche Erreichbarkeit
ping -c4 8.8.8.8

# 4. DNS auflösen
nslookup hanse-computing.de

# 5. Port prüfen
nc -zv hanse-computing.de 443

Diese Kette grenzt das Problem sauber ein: lokale Config → Gateway → Internet → DNS → Dienst. So vermeidet man stundenlanges Suchen an der falschen Stelle.

IPv6 in der Praxis

IPv6 bringt größere Adressräume (128 Bit), eingebaute Sicherheit (IPsec optional), und kein NAT-Zwang – jedes Gerät kann eine öffentliche Adresse bekommen. Deutsche Provider und Hosting-Anbieter stellen IPv6 inzwischen flächendeckend bereit. Wer Server betreibt, sollte IPv6 früh testen: curl -6 https://hanse-computing.de – und Firewalls nicht nur für IPv4 konfigurieren (iptables/nftables vs. ip6tables). Mehr in Subnetting verstehen.

Fazit

TCP/IP zu verstehen heißt: wissen, welche Schicht welches Problem verursacht. „Internet ist langsam" kann an WLAN (Schicht 1), DNS (Schicht 4), TCP-Fenstern (Schicht 3) oder einem überlasteten Server liegen. Mit der Diagnose-Kette oben finden Sie die Ursache in Minuten statt Stunden. Praktische Absicherung nach außen behandelt der Artikel Firewall-Grundlagen.

Verwandte Artikel: Subnetting verstehen · DNS-Grundlagen · Systemadministration