Transport Layer (OSI Layer 4)

Layer 3 (IP) bringt das Paket zum Computer ("Hauptstraße 5"). Layer 4 (Transport) bringt es zum Programm ("Wohnung 3B - Firefox"). Ohne Layer 4 wüsste dein PC nicht, ob die Daten für Spotify oder Excel sind. Die Adressen hier heißen Ports. Außerdem entscheidet Layer 4 über die Qualität: "Willst du es sicher (TCP) oder schnell (UDP)?" Layer 3 (IP) ist "Best Effort" (Postkarte, kann verloren gehen). Layer 4 (TCP) macht daraus "Einschreiben" (Garantierte Ankunft).

Merksatz: Die vierte Schicht im OSI-Modell, die für die Ende-zu-Ende-Kommunikation ziwschen Anwendungen (Multiplexing via Ports) und optional für Zuverlässigkeit (TCP) oder Geschwindigkeit (UDP) zuständig ist.

Wenn du eine Firewall (AWS Security Group) konfigurierst, arbeitest du oft auf Layer 4. Regel: "Allow TCP Port 80". Ein "Layer 4 Load Balancer" (Network Load Balancer) verteilt Pakete nur basierend auf IP+Port. Er schaut nicht in den Inhalt (URL). Das ist extrem schnell (Millionen Req/s).

1. Multiplexing & Demultiplexing

Das Hauptfeature. Ein Kabel (Layer 1), Eine IP (Layer 3). Aber 50 offene Browser-Tabs, Spotify und Slack gleichzeitig. Layer 4 klebt an jedes Paket einen Port-Aufkleber (Source Port, Dest Port). Der OS-Kernel sortiert eingehende Pakete ("Demultiplexing") in die richtigen Sockets (Puffer) der Anwendungen.

2. Segmentation & Reassembly

Die App sendet 100MB Daten. Layer 4 zerhackt sie in Segmente (MSS - Max Segment Size, oft 1460 Bytes). Jedes Segment bekommt einen Header. Beim Empfänger baut Layer 4 die Segmente wieder zusammen zum 100MB Stream. Die App merkt nichts von der Zerhackung ("Stream Abstraction").

3. Flow Control & Error Correction

Layer 4 ist die "Intelligenz" am Ende der Leitung (Edge). Das Netzwerk selbst (Router) ist dumm. Wenn ein Paket kippt (Bitfehler), merkt Layer 4 das (Checksum) und wirft es weg (UDP) oder fordert es neu an (TCP). Das Internet-Prinzip "Smart Endpoints, Dumb Pipes" wird hier realisiert.

1. Port Exhaustion (Erschöpfung)

Ein Computer hat 65.535 Ports pro IP-Adresse. Das klingt viel, kann aber zum Problem werden. Wenn ein High-Performance Load Balancer tausende Verbindungen pro Sekunde zu einem Backend aufbaut, gehen ihm irgendwann die freien "Source Ports" aus. Jede Verbindung belegt einen Port, und nach dem Schließen bleibt dieser oft noch 2 Minuten im Status TIME_WAIT (um verspätete Pakete abzufangen). In diesem Zustand ist der Port blockiert. Die Folge: Connection refused, obwohl der Server eigentlich nicht überlastet ist. Experten lösen dies durch Tuning des Kernels (tcp_tw_reuse) oder durch das Hinzufügen weiterer virtueller IP-Adressen am Load Balancer.

2. Zero-Copy Networking

Normalerweise müssen Daten im Speicher mehrfach kopiert werden: Von der Festplatte in den Kernel-Puffer, dann in den User-Space (deine App), dann wieder in den Kernel-Puffer für die Netzwerkkarte. Das frisst CPU-Zyklen. Moderne Layer-4 Architekturen nutzen Zero-Copy (Befehle wie sendfile unter Linux). Die Daten werden direkt vom Dateisystem-Puffer in die Netzwerkkarte geschoben, ohne dass die CPU sie jemals "anfassen" muss. Das ist der Grund, warum statische Webserver wie Nginx gigantische Datenmengen mit fast Null CPU-Last ausliefern können.

3. Checksum-Offloading

Die Berechnung der Prüfsumme für jedes Paket (um Bitfehler zu finden) kostet Rechenleistung. Früher hat das der Hauptprozessor (CPU) erledigt. Heute haben fast alle Netzwerkkarten (NICs) eigene kleine Prozessoren für das Checksum Offloading. Die CPU schickt das Paket einfach unberechnet raus, und die Hardware der Netzwerkkarte berechnet die Prüfsumme "im Vorbeifliegen". Wenn du in Wireshark "Bad Checksum" Meldungen siehst, liegt das oft daran, dass Wireshark das Paket sieht, bevor die Hardware die Summe berechnet hat.