BBR (Bottleneck Bandwidth and RTT)

Das Internet hat Staus (Congestion). TCP muss bremsen, wenn das Netz voll ist. Klassisches TCP (CUBIC/Reno) bremst erst, wenn Pakete verloren gehen (Packet Loss). Das ist doof. Denn bevor Pakete verloren gehen, füllen sich erst riesige Warteschlangen in den Routern (Bufferbloat). Das erhöht die Latency massiv. BBR (von Google) guckt nicht auf Verlust. Es guckt auf die Geschwindigkeit (Bandwith) und die Laufzeit (RTT). Es baut ein Modell der Leitung. "Wie viel passt durch?" Es sendet genau so viel, wie die Leitung verträgt, ohne die Puffer zu füllen. Ergebnis: Höherer Durchsatz UND niedrigere Latenz. YouTube läuft flüssiger.

Merksatz: Ein von Google entwickelter Congestion-Control-Algorithmus für TCP/QUIC, der statt auf Paketverlust auf gemessene Bandbreite und Round-Trip-Time reagiert, um den Durchsatz zu maximieren und Bufferbloat zu minimieren.

Als Server-Admin: Aktiviere es in Linux! echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf Das bringt oft 20-30% mehr Speed für User mit schlechtem Netz. YouTube, Spotify und Dropbox nutzen es alle.

1. Model-based

BBR ist "modellbasiert". Es schätzt BtlBw (Bottleneck Bandwidth) und RTprop (Round Trip Propagation Time). Es versucht, den Punkt zu finden, wo "Pipe voll" ist, aber "Buffer leer". (Kleinsche Röhre). Klassisches TCP füllt den Buffer bis zum Platzen.

2. Fairness

BBRv1 war manchmal "zu aggressiv" und hat CUBIC-Streams verdrängt. BBRv2 und BBRv3 (in Entwicklung) sind netter zu klassischem TCP und achten auch etwas auf Packet Loss (ECN), um in Data Centern besser zu funktionieren.

1. Die vier Phasen der BBR-State-Machine

BBR ist ein kontinuierlicher Regelkreis. Es durchläuft ständig vier Zustände:

Startup: Es verdoppelt die Senderate in jedem Schritt, um schnell die Kapazität zu finden (wie Slow Start).
Drain: Wenn das System merkt, dass die Latenz (RTT) steigt, reduziert es den Traffic massiv, um die Puffer, die im Startup gefüllt wurden, wieder zu leeren.
ProbeBW (Der Normalzustand): Es "tippt" die Leitung vorsichtig an: Ein bisschen schneller senden, gucken ob RTT steigt, dann wieder langsamer. So findet es das ideale Gleichgewicht.
ProbeRTT: Einmal alle 10 Sekunden drosselt BBR den Traffic fast auf Null, um die echte, minimale Verzögerung der Leitung (ohne Puffer-Staus) zu messen.

2. BWM (Bandwidth Max) & Minimum RTT

Mathematisch operiert BBR an der Kleinrock’s optimal operating point. Das Ziel ist es, die Datenmenge im Netz exakt beim BDP (Bandwidth-Delay Product) zu halten. $BDP = \text{Bandbreite} \times \text{Latenz}$. Wenn $BDP = 100$ Pakete ist, und du schickst 101 Pakete, dann wartet das 101. Paket im Router. Klassisches TCP schickt oft das 2-fache oder 3-fache des BDP. BBR versucht, bei $1.0$ zu bleiben. Das macht BBR extrem schnell bei großen Dateien über Langstrecken-Verbindungen (USA nach Europa), wo die Latenz hoch ist.

3. BBRv2 und der "Fairness"-Krieg

In der SRE-Welt gab es viel Kritik an BBRv1. Es war so aggressiv darauf programmiert, die Bandbreite zu halten, dass es in kleinen Netzwerken andere TCP-Streams (CUBIC) förmlich "erstickt" hat. BBR hat einfach ignoriert, dass andere Pakete verloren haben. BBRv2 führt deshalb eine "Loss Sensitivity" ein. Wenn es massiven Paketverlust sieht, bremst es nun doch ein bisschen, um ein guter "Netzwerk-Bürger" zu sein. Zudem unterstützt es ECN (Explicit Congestion Notification), wodurch Router dem Server direkt sagen können: "Ich werde gleich voll", bevor das erste Paket gedroppt wird.