Traffic Shaping

In der Fritz!Box: "Echtzeitanwendungen priorisieren". In Linux (tc - Traffic Control):

tc qdisc add dev eth0 root tbf rate 1mbit burst 32kbit latency 400ms

Web-Entwickler nutzen das in den Chrome DevTools ("Throttling: Slow 3G"), um zu testen, wie ihre Seite in der U-Bahn lädt.

1. Leaky Bucket vs. Token Bucket

Wie entscheidet man, wer warten muss?

• Leaky Bucket: Ein Eimer mit Loch unten. Wasser (Daten) fließt oben rein (schnell, unregelmäßig). Unten kommt es konstant raus (z. B. 10 MBit/s). Wenn der Eimer voll ist, läuft er über (Paketverlust). Glättet den Traffic perfekt zu einer Linie.
• Token Bucket: Du sammelst Tokens (Erlaubnis zu senden). Wenn du lange geschwiegen hast, hast du viele Tokens und darfst einen kurzen "Burst" (100 MBit/s) senden, bis die Tokens alle sind. Erlaubt kurzzeitige Spitzen. (Besser für Web-Browsing).

2. QoS (Quality of Service)

Shaping ist Teil von QoS. Man markiert Pakete im IP-Header (DSCP / ToS Bits).

• EF (Expedited Forwarding): Voice/Video. Sofort weiterleiten!
• BE (Best Effort): Email/Web. Egal wann. Switches und Router lesen diese Bits und haben separate Warteschlangen (Queues).

3. Policing

Shaping vs. Policing.

• Shaping: Verzögert Pakete (Puffern), um die Rate einzuhalten. "Warte kurz." (Gutmütig).
• Policing: Wirft Pakete sofort weg, wenn das Limit überschritten ist. "Zu schnell -> Müll." (Hart). TCP mag Shaping lieber (Retransmissions vermeiden). Policing führt zu "TCP Sägezahn" (Geschwindigkeit schwankt extrem).

BBR & Der TCP Sägezahn (Congestion Control)

Traffic Shaping beeinflusst TCP massiv. TCP baut seine Fenstergröße (Window Size) stetig aus, um herauszufinden, wie viel Bandbreite da ist, bis ein Paket dropt – dann halbiert TCP sofort die Geschwindigkeit. Das ergibt auf dem Traffic-Graphen das berühmte "Sägezahn-Muster". Wenn Traffic Shaping nicht sauber puffert, kollabieren High-Speed Downloads. Moderne Linux-Systeme nutzen eBPF basierte BBR (Bottleneck Bandwidth and Round-trip propagation time) Algorithmen von Google. BBR schert sich nicht mehr primär um Packet-Loss, sondern berechnet ein Modell der Link-Kapazität. Es passt die Senderate exakt an den Shaping-Bottleneck an, wodurch der Sägezahn verschwindet und die Verbindung geglätteter, konstanter und (bei schlechtem WiFi) bis zu 100x schneller wird.

HTB (Hierarchical Token Bucket) in Linux tc

In Linux Ops ist tc (Traffic Control) berüchtigt. Der komplexeste und mächtigste Queueing Discipline (qdisc) Algorithmus ist HTB. HTB erlaubt das absolute Mikromanagement durch Hierarchie-Bäume. Prio 1 (Voice) bekommt ein reserviertes Limit. Prio 2 (Downloads) kriegt ein anderes. Der Clou: Wenn Voice gerade nicht sendet, kann Download temporär die Bandbreite von Voice "borgen" (Ceil-Parameter). Sobald der CEO ein Zoom-Call startet, entzieht HTB dem Download sofort dynamisch das Leih-Token. So verhindert man Ressourcenverschwendung bei harten Policing-Kappungen und erreicht maximale Link-Utilization.

Bufferbloat und fq_codel (Active Queue Management)

Das schwerste Problem der letzten 10 Jahre Heim-Internet war Bufferbloat. Router-Hersteller rüsteten gigantische RAM-Chips als Puffer ein, um Paketverlust ("Drops") bei Bursts zu verhindern. Das Resultat: Ein Steam-Download läuft. Der Router puffert brav alles ab. Versuchst du parallel CS:GO zu spielen, reiht sich dein winziges VoIP/Game-Paket hinter 40 Megabyte Steam-Download im RAM des Routers ein. Der Router tröpfelt ihn raus. Dein Ping im Spiel crasht auf 4.000ms. Die Rettung ist fq_codel (Fair Queue Controlled Delay). Dieser Algorithmus killt unbarmherzig Pakete von gierigen "Elefantenströmen" (Downloads), wenn sie zu lange im Puffer ruhen (z.B. > 5ms Delay). Dadurch zwingt es TCP zum Verkleinern des Fensters ohne den Puffer zu fluten, und isoliert parallele "Mäuse-Ströme" (Games/DNS), die auf Fast-Tracks sofort ausgeteilt werden.