# Network Performance Deep Dive: TCP Tuning & BPF Power

TL;DR / Management Summary Linux ist out-of-the-box für “durchschnittliche” Workloads konfiguriert. In 10GbE+ Umgebungen, bei High-Concurrency Webservern oder Database-Clustern werden die Standard-Buffer zum Flaschenhals. Dieses Modul zeigt, wie wir die TCP Window Scaling, Congestion Control Algorithms (wie BBR) und Kernel-Warteschlangen optimieren. Zusätzlich nutzen wir BPF (Berkeley Packet Filter), um Performance-Einbrüche ohne Paket-Capturing in Echtzeit zu finden.

# 1. Einführung & Architektur

Der Weg zur Millisekunde.

Netzwerk-Performance hängt von drei Faktoren ab: Bandbreite, Latenz und Paketverlust. Während Bandbreite meist durch Hardware limitiert ist, ist Latenz oft ein Software-Konfigurations-Thema.

# Der Bottleneck: TCP Buffer

Der TCP-Stack reserviert RAM für jede Verbindung (Send/Receive Buffer). Wenn diese zu klein sind, kann TCP die Bandbreite nicht voll ausschöpfen (BDP - Bandwidth Delay Product).

# Architektur-Übersicht (Mermaid)

graph TD
    APP[Application / User Space] -->|1. write()| SOCK[Socket Buffer]
    SOCK -->|2. TCP Segment| STACK[TCP/IP Kernel Stack]
    STACK -->|3. qdisc| QUEUE[Queueing Discipline]
    QUEUE -->|4. Driver| NIC[Network Interface Card]
    
    subgraph "Tuning Areas"
    SOCK
    STACK
    QUEUE
    end

# 2. TCP Core Tuning

Das Getriebe ölen.

# TCP Window Scaling & Buffers

Auf Long-Fat-Pipes (LFP) brauchen wir große Fenster.

# Maximale Buffer-Größen erhöhen (Einheiten in Bytes)
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216

# TCP-spezifische Memory-Limits (Min, Default, Max)
sysctl -w net.ipv4.tcp_rmem='4096 87380 16777216'
sysctl -w net.ipv4.tcp_wmem='4096 65536 16777216'

# TCP BBR (Bottleneck Bandwidth and RTT)

Google’s BBR Algorithmus reagiert viel intelligenter auf Paketverlust als das klassische CUBIC. Er ist ideal für Internet-Traffic und Cloud-Backups.

# BBR aktivieren (erfordert Kernel > 4.9)
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr

# 3. Deep Dive: BPF für Performance-Analyse

Messen ohne zu Bremsen.

Klassisches Paket-Tracing (tcpdump) hat hohen Overhead. BPF (eBPF) erlaubt es uns, Programme direkt in den Kernel zu laden, die Statistiken sammeln, ohne jedes Paket in den User-Space zu kopieren.

# TCP Retransmissions finden

Retransmits sind der Killer für Latenz. Finden wir heraus, wer sie verursacht:

# Mit tcpretrans (Teil der bcc-tools / bpftrace)
tcpretrans
# Output zeigt: L-ADDR:PORT -> R-ADDR:PORT (State)

# TCP Connect Latency

Wie lange dauert der 3-Way-Handshake?

tcpconnlat
# Misst die Zeit von SYN bis ACK in Millisekunden.

# 4. Day-2 Operations: High Traffic Scenarios

Wenn 10.000 User gleichzeitig klopfen.

# TIME_WAIT Buckets

Bei vielen kurzlebigen Verbindungen (Microservices) laufen die Ports voll.

# Anzahl der erlaubten TIME_WAIT Sockets erhöhen
sysctl -w net.ipv4.tcp_max_tw_buckets=2000000
# TCP Fast Open erlauben
sysctl -w net.ipv4.tcp_fastopen=3

# Queueing Disciplines (qdisc)

Verwalten Sie den Traffic-Fluss zum Treiber.

• fq_codel: Standard für Desktop/Router (verhindert Bufferbloat).
• fq: Erforderlich für BBR, sorgt für gleichmäßiges Pacing.

# 5. Troubleshooting & “War Stories”

Wenn die Leitung ‘atmet’.

# Top 3 Fehlerbilder

1. Symptom: 10G Link liefert nur 1G Durchsatz bei einer einzelnen TCP-Verbindung.

   • Ursache: TCP Window Scaling deaktiviert oder Single-Core Bottleneck.
   • Lösung: net.ipv4.tcp_window_scaling=1 prüfen und Interrupt Affinity (RSS) checken.

2. Symptom: Sporadische Verbindungsabbrüche bei SSL-Handshakes.

   • Analyse: tcpdrop (BPF Tool) zeigt, ob der Kernel Pakete aufgrund von vollen Queues verwirft.
   • Lösung: net.core.netdev_max_backlog erhöhen.

3. Symptom: Hohe Latenz bei kleinen Paketen (RPC).

   • Lösung: TCP_NODELAY in der Applikation oder ethtool -C eth0 adaptive-rx off (Interrupt Coalescing Tuning).

# “War Story”: Der 100ms-Glitch

Ein Backup-Job über eine Standleitung brach ein, sobald der Tunnel 0.1% Paketverlust hatte. CUBIC halbierte sofort das Fenster. Durch den Wechsel auf BBR und die Erhöhung der TCP Buffers konnten wir den Durchsatz von 450 Mbit/s auf 980 Mbit/s stabilisieren, da BBR Verlust von Congestion unterscheiden kann.

# 6. Monitoring & Alerting

Die Leitung vermessen.

# Wichtige KPIs

• TCP Retransmits: node_netstat_Tcp_RetransSegs.
• Active Opens / Passive Opens: Rate der Verbindungsaufbauten.
• BPF Metrics: Histogramme über Connect-Latenzen (via eBPF Exporter).

# Prometheus Alert

- alert: HighTCPRetransmissions
  expr: rate(node_netstat_Tcp_RetransSegs[5m]) > 100
  for: 5m
  labels:
    severity: warning

# 7. Fazit & Empfehlung

Standard-Linux ist gut, aber nicht perfekt.

• Empfehlung: Nutzen Sie BBR überall dort, wo Latenz eine Rolle spielt. Es ist der größte “Free Win” im modernen Linux-Netzwerk.
• Warnung: Ändern Sie net.ipv4.tcp_tw_reuse nur, wenn Sie genau wissen, was Sie tun (Gefahr von Sequence Number Overlap).

# Anhang: Cheatsheet

# Referenzen

• Brendan Gregg: BPF Performance Tools
• Kernel.org: IP Sysctl Documentation
• Google: BBR Congestion Control