Bandwidth Limits: Warum der Throughput nicht zur Erwartung passt

„Bandwidth Limits“ sind einer der häufigsten Gründe, warum der Throughput in der Praxis nicht zur Erwartung passt – selbst dann, wenn auf dem Papier eine hohe Bandbreite zugesichert ist. Viele Teams planen mit „bis zu X Gbit/s“, messen dann aber nur einen Bruchteil und vermuten sofort einen Fehler im Netzwerk. In Wirklichkeit entsteht die Abweichung oft aus mehreren, gleichzeitig wirkenden Grenzen: Instanz- oder VM-Limits, Limits der Netzwerkkarte, Paketverarbeitung pro Sekunde, CPU-Engpässe, Verschlüsselung, Storage-I/O, TCP-Mechanismen und nicht zuletzt Messmethoden, die Äpfel mit Birnen vergleichen. Entscheidend ist, dass „Bandbreite“ (theoretische Kapazität) nicht identisch ist mit „Throughput“ (tatsächlich erreichbarer Datendurchsatz auf Anwendungsebene). Wer Bandwidth Limits korrekt einordnet, kann Engpässe systematisch isolieren, Messungen reproduzierbar gestalten und realistische SLOs ableiten – ohne sich von Marketingangaben oder falsch konfigurierten Benchmarks in die Irre führen zu lassen.

Bandbreite, Throughput und Goodput: Drei Begriffe, die oft vermischt werden

Wenn Erwartungen nicht erfüllt werden, liegt es häufig daran, dass unterschiedliche Ebenen verglichen werden. Bandbreite beschreibt die maximale Übertragungskapazität eines Links oder einer Instanz. Throughput ist der tatsächlich gemessene Datendurchsatz, meist auf Transport- oder Anwendungsebene. Goodput ist der Anteil der Nutzdaten, der ohne Protokoll-Overhead und Retransmits ankommt. In der Praxis sinkt der Goodput, sobald Overhead, Verluste oder Wiederholungen steigen.

• Bandbreite: theoretische Obergrenze (z. B. „10 Gbit/s“)
• Throughput: gemessener Durchsatz (z. B. via iperf, Downloads, Replikation)
• Goodput: Nutzdatenrate, die der Anwendung effektiv zur Verfügung steht

Zusätzliche Verwirrung entsteht durch Einheiten: Netzwerkkapazitäten werden meist in bit/s angegeben, Dateitransfers in Byte/s. 1 Gbit/s entspricht rechnerisch maximal 125 MB/s – und das nur ohne Overhead. Sobald Protokoll-Header, TLS, Tunneling oder Retransmits hinzukommen, wird die Netto-Rate geringer.

Warum „bis zu“ fast nie „konstant“ bedeutet

Viele Plattformen und Provider formulieren Bandbreiten als „bis zu“. Das kann bedeuten, dass die Maximalrate an Bedingungen geknüpft ist: Instanzgröße, Netzwerkmodus, Placement, Lastprofil, Burst-Verhalten oder die Tatsache, dass Ressourcen geteilt werden. Selbst bei dedizierten Umgebungen sind Limits oft nicht als harte „Leitung“, sondern als Kombination aus Policies und technischen Grenzen implementiert (Traffic Shaping, Token-Bucket, PPS-Limits, Queueing).

• Burstable Netzwerkraten: Kurzzeitig hohe Rate, danach Drosselung
• Shared Infrastructure: Nachbarschaftseffekte in geteilten Segmenten
• Richtungsabhängige Limits: Ingress vs. Egress unterschiedlich
• Region-/Zonenabhängigkeit: Kapazitäts- und Pfadunterschiede

Die häufigsten technischen Ursachen, wenn der Throughput „zu niedrig“ ist

Instanz- und NIC-Limits: Die Obergrenze ist oft kleiner als gedacht

In Cloud-Umgebungen ist der verfügbare Netzwerkdurchsatz stark von der Instanz-/VM-Größe abhängig. Zusätzlich gibt es Limits für die virtuelle Netzwerkkarte, Anzahl der Queues, Offloads (TSO/GSO/GRO), Treiber und die Fähigkeit des Betriebssystems, Pakete schnell genug zu verarbeiten. Ein einzelner Engpass an dieser Stelle kann den Throughput drastisch reduzieren, auch wenn die Gegenstelle mehr könnte.

• Limit pro VM/Instanz (max. Gbit/s und oft auch max. PPS)
• Limit pro Netzwerk-Interface oder pro Attachment
• Treiber-/Kernel-Unterstützung für Offloads und Multi-Queue
• Zu kleine MTU oder Fragmentierung durch Tunnels

Für offizielle Richtwerte und Konzepte sind die Provider-Dokumentationen hilfreich, z. B. zu Netzwerklimits von Instanzen bei EC2 Networking, zu VM-Netzwerkfunktionen in Azure Virtual Network Bandwidth oder zu Leistungsmerkmalen bei Google Cloud Compute Networking.

Paket pro Sekunde (PPS): Der „unsichtbare“ Flaschenhals

Ein System kann bandbreitenstark sein und trotzdem bei vielen kleinen Paketen einbrechen. Dann ist nicht die Bitrate das Problem, sondern die Paketverarbeitung pro Sekunde. Kleine Pakete erzeugen mehr Interrupts, mehr Kontextwechsel und mehr Header-Overhead. Das zeigt sich besonders bei Workloads wie DNS, VoIP, Telemetrie, Microservices mit vielen kleinen Requests oder UDP-lastigen Streams.

• Kleine Pakete erhöhen PPS und CPU-Last
• Zu wenige Receive/Transmit-Queues begrenzen Parallelität
• Interrupt-Steering und CPU-Pinning beeinflussen Performance

CPU und Verschlüsselung: TLS, VPN und Service Mesh kosten Durchsatz

Throughput ist selten „nur Netzwerk“. TLS-Termination, mTLS im Service Mesh, IPsec, WireGuard oder Benutzerraum-Proxies belasten CPU und können den Durchsatz limitieren, bevor das Netzwerk überhaupt am Limit ist. Das gilt besonders bei hoher Parallelität, kleinen Records oder wenn Kryptobeschleunigung nicht verfügbar oder nicht aktiv ist.

• TLS/mTLS erhöht CPU-Last und Latenz pro Request
• VPN-/Tunnel-Overhead reduziert Goodput und kann MTU-Probleme verursachen
• Proxy-Chains (Ingress, Sidecar, Gateway) addieren Overhead

Storage und Applikation: Die „Quelle“ ist zu langsam

Viele Benchmarks messen nicht die Netzwerkkapazität, sondern die langsamste Komponente im Datenpfad. Wenn eine Anwendung Daten aus einer langsamen Platte liest, ein Single-Thread-Server nicht skaliert oder ein Objekt-Store-Client zu wenig parallelisiert, bleibt der Durchsatz niedrig – unabhängig von Bandwidth Limits.

• Disk/SSD-Limit (IOPS/Throughput) bremst Transfers
• Single-Thread-Anwendungen saturieren CPU, nicht Netzwerk
• Zu wenig Parallelität bei Downloads/Uploads (zu wenige Streams)
• Serielles Request-Handling statt Pipelining/Batching

TCP als Durchsatzbremse: RTT, Window Size und Bandwidth-Delay-Product

Gerade bei weiten Strecken (Cross-Region, On-Prem zu Cloud, internationale Nutzer) wird TCP zum limitierenden Faktor. Der maximal erreichbare Throughput pro Flow hängt stark von der Round-Trip-Time (RTT) und der effektiven Window Size ab. Wenn das TCP-Fenster zu klein ist, kann die Leitung nicht „gefüllt“ werden. Als grobe Orientierung dient das Bandwidth-Delay-Product (BDP): Es beschreibt, wie viele Bytes „in Flight“ sein müssen, um eine bestimmte Bandbreite bei gegebener RTT auszunutzen.

$\mathrm{BDP}=\mathrm{Bandwidth}\times \mathrm{RTT}$

Beispielhafte Einordnung: Bei 1 Gbit/s und 50 ms RTT braucht es ein BDP von rund 6,25 MB. Wenn Sender oder Empfänger nur ein deutlich kleineres TCP-Fenster erlauben, ist der maximale Throughput pro Verbindung begrenzt, selbst wenn Bandwidth Limits höher liegen.

Single Stream vs. Multi Stream: Warum ein iperf-Test „zu schlecht“ aussieht

Ein häufiger Messfehler ist, mit einer einzigen TCP-Verbindung zu testen und daraus abzuleiten, die Leitung sei „langsam“. In vielen realen Szenarien nutzen Anwendungen mehrere parallele Verbindungen, Requests oder Streams. Eine einzelne Verbindung kann durch Congestion Control, Window Scaling oder CPU limitiert sein. Deshalb ist es wichtig, Single-Stream und Multi-Stream getrennt zu bewerten.

• Single Stream: zeigt TCP-Limitierung durch RTT/Window/CPU
• Multi Stream: nähert sich eher dem realen Maximum an (wenn die Anwendung parallelisiert)
• UDP-Tests: können Maximalrate zeigen, aber verschleiern Paketverluste

Overhead, MTU und Fragmentierung: Wenn „zu viele Bits“ nicht ankommen

Auch bei idealer Leitung geht ein Teil der Kapazität für Protokoll-Header drauf: Ethernet, IP, TCP/UDP, ggf. VLAN, GRE/VXLAN, TLS, HTTP/2 oder QUIC. Zusätzlich kann eine ungünstige MTU (Maximum Transmission Unit) zu Fragmentierung führen, was Retransmits erhöht und den Goodput senkt. Besonders kritisch ist das bei Tunneln (VPN, Overlay-Netze, Service Mesh), wenn die Path MTU nicht sauber ermittelt wird.

• Jumbo Frames können helfen, wenn End-to-End unterstützt
• Tunnel reduzieren effektive MTU; falsche MTU führt zu Drops
• Fragmentierung erhöht CPU und senkt Throughput

Traffic Shaping, Policing und „stille“ Drosselungen

Bandwidth Limits werden oft über Shaping-Mechanismen umgesetzt. Das ist nicht immer als „Fehler“ sichtbar, sondern zeigt sich als konstante Obergrenze oder als periodisches Sägen (Burst und Drossel). Ein Token-Bucket-Mechanismus erlaubt kurzfristig hohe Raten, solange Tokens vorhanden sind; danach wird die Rate geglättet. In Monitoring sieht das dann aus wie: „Am Anfang schnell, danach konstant niedriger.“

• Shaping: Pakete werden verzögert (Queueing), Latenz steigt
• Policing: Pakete werden verworfen, Retransmits steigen
• Fair Queuing: mehrere Flows teilen sich Kapazität, je nach Policy

Messmethodik: So vermeiden Sie falsche Schlüsse

Viele Throughput-Diskussionen scheitern nicht an der Technik, sondern an unklarer Messmethodik. Ein sauberer Test definiert: Messpunkt, Protokoll, Paketgröße, Parallelität, Laufzeit, Warm-up, CPU-Last und die Frage, ob Sie Goodput oder Rohdurchsatz messen. Außerdem sollten Sie sicherstellen, dass beide Enden leistungsfähig genug sind (Client und Server), sonst benchmarken Sie nur die schwächere Seite.

Checkliste für belastbare Throughput-Tests

• Testdauer: lang genug, um Burst-Phasen zu überstehen (mehrere Minuten)
• Parallelität: Single-Stream und Multi-Stream getrennt messen
• Paketgröße: realistische MSS/MTU berücksichtigen
• CPU-Profile: CPU-Auslastung und SoftIRQ/Interrupts beobachten
• Pfadkonstanz: gleiche Zone/Region vs. Cross-Region unterscheiden
• Symmetrie: Ingress/Egress separat prüfen

Erwartungen korrekt berechnen: Von Gbit/s zur realistischen Nutzdatenrate

Wer „10 Gbit/s“ liest, erwartet oft „1,25 GB/s“. Das ist als Maximalwert ohne Overhead bereits die Umrechnung von bit zu Byte. In der Praxis ist die Nutzdatenrate niedriger, weil Header und ggf. Verschlüsselung Platz verbrauchen. Für eine grobe Erwartung können Sie zunächst die bit/Byte-Umrechnung nutzen und dann konservativ einen Overhead-Puffer einplanen.

$\mathrm{MBps}=\frac{\mathrm{Gbitps}\times 1000}{8}$

Diese Näherung hilft für schnelle Plausibilitätschecks. Wenn Sie deutlich unter diesem Wert liegen, ist es sinnvoll, die Ursachen in Schichten zu prüfen: zuerst Instanz-/NIC-Limits und CPU, dann TCP/RTT/Window, dann Overhead/MTU, dann Applikation und Storage.

Typische Symptome und was sie wahrscheinlich bedeuten

• Am Anfang schnell, dann dauerhaft langsamer: Burst-Limit oder Token-Bucket-Shaping
• Durchsatz steigt mit mehr parallelen Verbindungen: TCP-Window/RTT-Limit pro Flow oder Single-Thread-Engpass
• Hohe CPU bei niedrigem Throughput: Verschlüsselung, Proxying, PPS-Limit, fehlende Offloads
• Viele Retransmits, schwankender Throughput: Paketverluste, Policing, MTU/Fragmentierung, überlastete Queues
• Gute Werte in einer Richtung, schlechte in der anderen: Egress-Limit, asymmetrischer Pfad, Policy-Unterschiede

Praxisleitfaden: Systematisch zum echten Engpass

Ein pragmatischer Ansatz ist, in klaren Schritten zu isolieren, welcher Layer den Throughput begrenzt. Damit vermeiden Sie „Trial and Error“ und können Änderungen gezielt testen.

Schritt 1: Limits und Leistungsmerkmale verifizieren

• Welche Bandwidth Limits gelten für die konkrete Instanz/VM-Größe?
• Gibt es separate Limits für PPS oder pro Interface?
• Ist die Netzwerkkonfiguration (Treiber, Offloads, MTU) sauber?

Schritt 2: CPU, Interrupts und Queueing prüfen

• CPU-Auslastung unter Last messen (User, System, SoftIRQ)
• Netzwerk-Queues und Multi-Queue aktiv?
• Verschlüsselung/Proxies als mögliche CPU-Bremse identifizieren

Schritt 3: TCP/RTT-Mechanik bewerten

• RTT messen (z. B. Ping als Anhaltspunkt, besser Applikations-RTT)
• Single- vs. Multi-Stream vergleichen
• Retransmits und Congestion Events beobachten

Schritt 4: MTU, Overhead und Drops ausschließen

• Path MTU prüfen, besonders bei Tunneln
• Fragmentierung und ICMP-Blockaden vermeiden
• Packet Loss und Queue Drops auf beiden Seiten betrachten

Weiterführende Quellen zur Einordnung von Throughput und Bandbreite

• AWS EC2 Networking: Konzepte, Limits und Optimierung
• Microsoft Learn: Bandwidth und Performance in Azure Virtual Networks
• Google Cloud: Compute Engine Networking und Performance-Aspekte
• TCP-Spezifikation (RFC 9293) für Grundlagen zu Window und Congestion Control

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.