# The Network Stack: Die Reise eines Pakets durch den Kernel

TL;DR / Management Summary Ein Netzwerkpaket durchläuft in Linux eine hochkomplexe Pipeline. Vom Eintreffen an der Netzwerkkarte (Layer 2) über die Routing-Entscheidung (Layer 3) bis hin zum Aufbrechen des TCP-Streams (Layer 4) übernimmt der Kernel die volle Kontrolle. Ein Senior Admin muss den Weg der sk_buff Struktur (das Paket im Kernel-RAM) verstehen, um Paketverluste, Latenzen und Durchsatz-Probleme präzise lokalisieren zu können.

# 1. Einführung & Architektur

Die Schichten des Kernels.

Der Linux Netzwerk-Stack folgt dem OSI-Modell, ist aber für maximale Geschwindigkeit optimiert.

# Der Paket-Fluss (Mermaid)

graph TD
    A[Hardware: NIC] -->|Interrupt / NAPI| B[Driver: ring buffer]
    B -->|Convert to sk_buff| C[Layer 2: Ethernet / VLAN]
    C -->|Netfilter: Prerouting| D[Layer 3: IP Layer]
    D -->|Routing Decision| E{Local or Forward?}
    E -->|Local| F[Layer 4: TCP / UDP]
    E -->|Forward| G[Layer 3: Outgoing IP]
    F -->|Socket Queue| H[User Space App]
    subgraph "Kernel Processing"
        C
        D
        E
        F
    end

# 2. Layer 2 & 3: Bridge und Routing

Das Fundament.

# Der SoftIRQ-Mechanismus

Netzwerkkarten produzieren tausende Interrupts. Damit die CPU nicht blockiert, nutzt Linux NAPI (New API).

• Die CPU schaltet vom Interrupt-Modus in den Polling-Modus um, wenn zu viele Pakete ankommen.
• Monitoring: cat /proc/softirqs zeigt, wie viel CPU-Zeit in Netzwerk-Processing fließt.

# 3. Layer 4: TCP & Sockets

Daten für die Applikation.

Der Kernel verwaltet die TCP-Zustände (SYN, ESTABLISHED, FIN).

• Receive Window: Die CPU puffert Daten im Socket-Buffer, bis die Applikation sie via recv() abholt.
• Zero Copy: Moderne Techniken erlauben es der Applikation, Daten direkt aus dem Kernel-Buffer zu lesen, ohne sie zu kopieren (sendfile).

# 4. Day-2 Operations: Stack-Analyse

Den Fluss messen.

Nutzen Sie Werkzeuge, die tief in den Stack blicken:

1. Driver: ethtool -S eth0 (CRC Fehler, Drops in der Hardware).
2. IP/TCP: netstat -s oder nstat (Zähler für Timeouts, Retransmits).
3. App: ss -ti (TCP-Metriken pro Verbindung).

# 5. Troubleshooting & “War Stories”

Wenn der Stack brennt.

# Story 1: “Der hängende SoftIRQ”

Symptom: Ein Server mit 100Gbit Anbindung zeigt 100% CPU-Last auf einem einzelnen Kern (oft Kern 0), während andere Kerne nichts tun. Der Durchsatz ist gering. Ursache: Ein einzelner Kern ist mit der Verarbeitung der Netzwerk-Interrupts (SoftIRQs) überfordert. Lösung: Aktivieren Sie RSS (Receive Side Scaling) auf der Netzwerkkarte oder nutzen Sie RPS (Receive Packet Steering) in der Sysctl-Konfig, um die Last auf alle Kerne zu verteilen.

# Story 2: “Das Buffer-Bloat Problem”

Symptom: Die Bandbreite ist hoch, aber die Latenz (Ping) steigt massiv an, sobald ein großer Download startet. Ursache: Die Kernel-Puffer sind zu groß. Pakete warten ewig in der Warteschlange, anstatt verworfen zu werden, was TCP zur Verlangsamung zwingen würde. Lösung: Nutzen Sie den FQ-CoDel oder BBR Algorithmus (Artikel 367), um die Warteschlangen intelligent zu verwalten.

# 6. Fazit & Empfehlung

• Verständnis: Betrachten Sie den Netzwerk-Stack als eine Kette von Warteschlangen. Ein Stau an einer Stelle beeinflusst das gesamte System.
• Wartung: Überwachen Sie die softnet_stat Metriken via /proc/net/softnet_stat.
• Wahl: Nutzen Sie XDP (eXpress Data Path) für extrem schnelles Paket-Filtering, noch bevor der volle IP-Stack durchlaufen wird.

# Anhang: Cheatsheet für Stack-Admins