Schichtenmodell und TCP/IP

Warum Schichten?

Ein Brief im Umschlag: Du schreibst den Inhalt, steckst ihn in einen Umschlag mit Adresse, die Post legt ihn in einen Sack für das Zielverteilzentrum, der Sack kommt auf einen Lastwagen. Der Lastwagenfahrer kennt den Brief nicht, der Briefschreiber nicht die Route. Jede Ebene kümmert sich um ihren Teil und packt den Inhalt der Ebene darüber unbesehen ein. Genau so arbeitet ein Netzwerk – das Prinzip heißt Kapselung.

Der Vorteil: Jede Schicht ist austauschbar. HTTP funktioniert über WLAN, Kabel oder Mobilfunk gleich, weil es von der Funktechnik nichts weiß. Und ein neues Anwendungsprotokoll braucht keine neuen Router.

Das OSI-Modell mit seinen sieben Schichten aus den späten 1970er-Jahren ist das Lehrbuchmodell – man hört Sätze wie „ein Layer-7-Loadbalancer“. Gesiegt hat in der Praxis aber das schlankere TCP/IP-Modell, auf dem das Internet läuft.

IP: Adressen und Wege

Jedes Gerät im Internet braucht eine IP-Adresse. Die klassische Form, IPv4, hat 32 Bit – geschrieben als vier Zahlen wie 203.0.113.20. Das sind gut 4,3 Milliarden Adressen, und die sind seit Jahren praktisch vergeben. Zwei Auswege:

• NAT: Zu Hause haben alle Geräte private Adressen (192.168.x.x, 10.x.x.x oder 172.16–31.x.x), die im Internet nicht vorkommen. Der Router tritt nach außen mit einer einzigen öffentlichen Adresse auf und merkt sich, welche Antwort zu welchem Gerät gehört.
• IPv6: 128 Bit, also so viele Adressen, dass jedes Gerät eine eigene, weltweit eindeutige bekommen kann. Geschrieben in Hex, etwa 2001:db8::1. Ein großer Teil des Verkehrs läuft heute schon darüber – Umstieg seit über zwanzig Jahren.

Den Weg findet IP Schritt für Schritt. Jeder Router schaut auf die Zieladresse, sucht in seiner Tabelle den besten nächsten Nachbarn und schickt das Paket weiter. Kein Router kennt den ganzen Weg. Jedes Paket wird einzeln behandelt – zwei Pakete derselben Nachricht können verschiedene Wege nehmen. Damit kein Paket ewig im Kreis läuft, trägt es einen Zähler (TTL), den jeder Router um eins verringert; bei null wird es verworfen. Das Werkzeug traceroute nutzt genau das, um die Stationen eines Weges sichtbar zu machen.

TCP: Zuverlässigkeit auf unzuverlässigem Grund

TCP macht aus verlorenen, doppelten und vertauschten Paketen einen sauberen, geordneten Datenstrom. Die Tricks dahinter:

Dazu kommen zwei Regelkreise, die man selten sieht, aber ständig nutzt. Die Flusskontrolle sorgt dafür, dass ein schneller Sender einen langsamen Empfänger nicht überflutet: Der Empfänger meldet, wie viel Platz sein Puffer noch hat. Die Überlastkontrolle schützt das Netz selbst: TCP beginnt vorsichtig, steigert das Tempo, solange alles ankommt, und bremst deutlich, sobald Pakete verloren gehen – denn Verluste bedeuten meist volle Router. Dass Millionen TCP-Verbindungen sich so freiwillig zurücknehmen, hält das Internet seit den 1980er-Jahren am Laufen.

Der Handshake – und was er kostet

Bevor TCP Daten überträgt, tauschen beide Seiten drei Pakete aus: SYN, SYN-ACK, ACK. Dabei vereinbaren sie ihre Startnummern. Das kostet eine volle Rundreise (RTT, round-trip time) – und für eine verschlüsselte Verbindung kommt noch der TLS-Handshake dazu. Bei weiten Wegen merkt man das deutlich:

Genau deshalb wurde QUIC entwickelt, die Grundlage von HTTP/3. Es läuft über UDP und baut Zuverlässigkeit und Verschlüsselung selbst ein – Verbindungsaufbau und Schlüsselaustausch in einem Schritt. Ein weiterer Vorteil: Geht bei TCP ein Paket verloren, warten alle Daten dahinter, auch die anderer Dateien auf derselben Verbindung. QUIC verwaltet mehrere unabhängige Datenströme, ein Verlust bremst nur seinen eigenen.

Ports, Sockets und UDP

Eine IP-Adresse bringt ein Paket zum richtigen Rechner. Welches Programm es bekommt, entscheidet die Portnummer, eine Zahl von 0 bis 65 535. Server lauschen auf bekannten Ports: 443 für HTTPS, 80 für HTTP, 22 für SSH, 53 für DNS, 5432 für PostgreSQL. Der Client bekommt vom Betriebssystem einen zufälligen hohen Port. Eine TCP-Verbindung ist eindeutig bestimmt durch vier Werte: Quell-Adresse, Quell-Port, Ziel-Adresse, Ziel-Port. Das Ende einer Verbindung im Programm heißt Socket.

UDP verzichtet auf all die TCP-Mechanik: kein Handshake, keine Bestätigung, keine Reihenfolge. Ein Paket, ein Versuch. Das klingt schlechter, ist aber oft genau richtig: Bei einem Videoanruf ist ein verlorenes Bild von vor einer halben Sekunde wertlos – eine Neuübertragung käme zu spät. Auch DNS-Anfragen, Online-Spiele und QUIC laufen über UDP.

Ganz unten: das lokale Netz

Innerhalb eines lokalen Netzes zählt eine andere Adresse: die MAC-Adresse der Netzwerkkarte. Will ein Rechner ein Paket an eine IP im selben Netz schicken, fragt er per ARP in die Runde: „Wer hat 192.168.1.20?“ – und bekommt die MAC-Adresse zurück. Ein Switch verteilt Pakete innerhalb eines Netzes anhand der MAC-Adressen, ein Router verbindet verschiedene Netze anhand der IP-Adressen. Der Router zu Hause ist meist beides, dazu WLAN-Zugangspunkt und NAT-Übersetzer.

Für Entwickler übersetzt

// Ein Echo-Server: schickt alles zurück, was er bekommt
try (var server = new ServerSocket(5000);
     var exec = Executors.newVirtualThreadPerTaskExecutor()) {
    while (true) {
        Socket s = server.accept();               // kehrt nach dem TCP-Handshake zurück
        exec.submit(() -> {
            try (s; var in = s.getInputStream(); var out = s.getOutputStream()) {
                in.transferTo(out);               // ein Datenstrom, keine Nachrichten
            }
            return null;
        });
    }
}

Die Fehlermeldungen von Java verraten, auf welcher Schicht es hakt:

Zwei Ratschläge aus der Praxis: Immer beide Timeouts setzen – beim HttpClient mit connectTimeout und pro Anfrage mit timeout, bei Sockets mit connect(addr, ms) und setSoTimeout. Ohne Timeout wartet ein Thread im Zweifel ewig. Und Verbindungen wiederverwenden statt jedes Mal neu aufzubauen – Connection-Pools sparen genau die Handshakes aus dem Widget oben.

Häufige Irrtümer

Verwandte Begriffe