Throughput-Probleme: Warum “Bandbreite” nicht gleich Performance ist

Throughput-Probleme gehören zu den häufigsten und zugleich missverständlichsten Störungsmustern in IT-Netzwerken. Wenn Nutzer sagen „die Leitung ist langsam“, wird reflexartig nach mehr Bandbreite gerufen – obwohl die physische Linkrate in vielen Fällen gar nicht der limitierende Faktor ist. Genau hier liegt der Kern: Bandbreite ist eine Kapazitätsangabe (z. B. 1 Gbit/s), Performance beschreibt dagegen, wie schnell Anwendungen tatsächlich Daten übertragen und Antworten erhalten. Ein 1-Gbit/s-Link kann sich „langsam“ anfühlen, wenn Latenz hoch ist, Paketverlust auftritt, TCP-Fenster nicht wachsen, QoS falsch greift, eine Firewall policed oder ein Endsystem CPU-seitig limitiert. Umgekehrt kann eine schmalere Leitung stabil „schnell“ wirken, wenn Verzögerung und Loss niedrig sind und die Endpunkte effizient arbeiten. In diesem Artikel lernen Sie, Throughput-Probleme systematisch zu analysieren: welche Faktoren Goodput (nutzbare Datenrate) reduzieren, warum Speedtests oft irreführen, wie Sie Netzwerk- und Endsystemgrenzen sauber trennen und wie Sie mit evidenzbasiertem Troubleshooting die echte Ursache finden – statt nur Bandbreite zu kaufen.

Begriffe sauber trennen: Bandbreite, Throughput, Goodput und „gefühlte“ Geschwindigkeit

Viele Diskussionen scheitern an Begriffen. Wer Throughput-Probleme lösen will, muss unterscheiden, was gemessen wird.

• Bandbreite (Capacity): maximale Bitrate eines Links unter idealen Bedingungen (z. B. 100 Mbit/s, 1 Gbit/s).
• Throughput: tatsächlich übertragene Datenrate inkl. Protokolloverhead, Retransmits und ggf. Verschlüsselung.
• Goodput: nutzbare Datenrate auf Anwendungsebene (ohne Retransmits/Overhead) – das, was Nutzer „spüren“.
• Responsiveness: gefühlte Geschwindigkeit, stark beeinflusst durch Latenz und Server-Antwortzeiten.

Praxisrelevant: Eine Anwendung kann „langsam“ sein, obwohl der Link kaum ausgelastet ist. Häufig ist dann nicht Bandbreite knapp, sondern der Datenfluss wird durch andere Faktoren gebremst.

Die große Wahrheit: Latenz und Verlust bestimmen Throughput stärker als viele denken

Gerade bei TCP-basiertem Traffic (Web, APIs, Filesharing, viele VPNs) hängt erreichbarer Throughput stark von RTT (Round Trip Time) und Paketverlust ab. TCP muss Bestätigungen (ACKs) abwarten und passt seine Sendeleistung an. Je höher die RTT, desto länger dauert es, bis das Sendefenster wächst. Schon geringe Loss-Raten können den Durchsatz massiv einbrechen lassen, weil Retransmits und Congestion Control greifen.

Bandbreiten-Verzögerungs-Produkt als intuitive Erklärung

Um eine Leitung vollständig auszulasten, muss genug „Daten im Flug“ sein. Dieses Prinzip wird oft als Bandwidth-Delay Product (BDP) beschrieben. Vereinfacht: benötigtes Window ≈ Bandbreite × RTT.

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

Beispielgedanke: Auf einer Verbindung mit hoher RTT reicht ein kleines TCP-Fenster nicht, um hohe Bandbreite zu nutzen – selbst wenn der Link leer ist. Für die technische Basis von TCP-Verhalten (Congestion Control, Retransmits, Windowing) ist RFC 9293 (TCP) eine belastbare Referenz.

Warum Speedtests oft die falsche Frage beantworten

Speedtests messen meistens „maximalen Durchsatz“ zu einem ausgewählten Ziel mit mehreren parallelen Streams. Das kann nützlich sein, sagt aber wenig über konkrete Anwendungsperformance aus. Viele Business-Anwendungen arbeiten nicht mit 16 parallelen TCP-Streams, sondern mit wenigen Sessions, kurzen Transfers oder Latenz-sensitiven Requests.

• Mehrere Streams kaschieren Probleme: Ein einzelner Stream ist langsam, viele Streams füllen die Leitung trotzdem.
• Testziel ist nicht Ihre Anwendung: Peering und Pfad zum Speedtest-Server können besser sein als zum echten Service.
• Traffic-Klassen unterscheiden sich: QoS kann Speedtest bevorzugen oder benachteiligen.
• Server-/Client-Limits bleiben unsichtbar: CPU, Storage und TLS können limitieren, ohne dass der Link voll wird.

Typische Ursachen von Throughput-Problemen entlang des Pfads

Throughput ist end-to-end. Deshalb entstehen Engpässe an sehr unterschiedlichen Stellen. Die folgenden Ursachen sind in der Praxis besonders häufig.

Queueing, Microbursts und Congestion

• Mechanismus: Kurzzeitige Lastspitzen füllen Queues; Delay steigt, Drops entstehen, TCP bremst.
• Signale: Queue Drops, steigende RTT/Jitter, TCP Retransmits; oft trotz moderater Durchschnittsauslastung.
• Ursachen: Oversubscription, fehlendes Shaping, falsche QoS-Klassifikation, Burst-Workloads.

Policing und Shaping (Provider oder intern)

• Mechanismus: Policer verwerfen Bursts oder begrenzen Rate; Shaping glättet, kann aber Delay erhöhen.
• Signale: Policer Hits, class-based drops, Throughput-Caps „wie festgenagelt“.
• Ursachen: CIR unterschritten/überschritten, falsche Burst-Parameter, Policy-Fehler.

MTU/PMTUD und Fragmentation als versteckter Durchsatzkiller

• Mechanismus: Große Pakete hängen oder werden verworfen, Retransmits steigen, Sessions stagnieren.
• Signale: kleine Requests ok, große Transfers langsam oder hängen; auffällige Retransmits bei großen Payloads.
• Ursachen: Tunnel-Overhead, ICMP blockiert, fehlendes MSS-Clamping.

Für IP-Grundlagen und Fragmentation ist RFC 791 (Internet Protocol) eine solide Referenz.

ECMP/Load Balancing: „Nur manche Flows sind langsam“

• Mechanismus: Hashing lenkt einen Teil der Flows auf einen schlechteren Pfad/Member.
• Signale: einzelne Nutzer/Flows langsam, andere schnell; scheinbar zufällig, aber reproduzierbar pro Flow.
• Ursachen: fehlerhafter Link, asymmetrischer Pfad, Member mit Errors oder Congestion.

Security-Middleboxes: Firewall, Proxy, TLS Inspection

• Mechanismus: CPU/Session-Pressure, Deep Packet Inspection oder NAT-Limits begrenzen Throughput.
• Signale: Throughput bricht unter Last ein, CPU hoch, Drops/Timeouts, Session-Table-Pressure.
• Ursachen: zu aggressive Policies, Ressourcenlimits, unzureichende Kapazität, Asymmetrie bei Stateful Geräten.

Endsysteme: Der Engpass ist oft nicht das Netzwerk

• Mechanismus: Client/Server limitieren durch CPU, Disk I/O, Treiber, Offloading, TLS, Single-Thread-Performance.
• Signale: Link nicht ausgelastet, aber Transfer langsam; CPU- oder I/O-Spikes; TLS Handshake/Encryption kostet Zeit.
• Ursachen: kleine TCP-Receive-Windows, veraltete NIC-Treiber, Storage-Backpressure, schlecht konfigurierte VPN-Clients.

Diagnose mit System: Hypothesengetrieben zur echten Ursache

Throughput-Probleme lassen sich schnell lösen, wenn Sie nicht „Bandbreite“ messen, sondern Hypothesen testen: Welche Komponente begrenzt den Goodput? Dazu brauchen Sie Messungen, die Ursachenfamilien sauber trennen.

Schritt 1: Problem präzisieren (welcher Flow, welcher Pfad, welche Richtung?)

• Quelle/Ziel, Ports/Protokoll, Zeitpunkt, betroffene Standorte/Segmente
• Upload vs. Download (asymmetrische Limits sind häufig)
• Einzelner Stream oder viele parallele Streams?

Schritt 2: Latenz, Loss und Retransmits korrelieren

• RTT steigt bei Last? Hinweis auf Queueing oder Shaping
• Loss/Drops sichtbar? Hinweis auf Congestion, Policing oder physikalische Fehler
• TCP Retransmits? starker Indikator für Loss/Delay im Pfad

Schritt 3: Messpunkte entlang des Pfads prüfen

• Access: WLAN Retries, Port Errors, lokale Congestion
• Core: Queue Drops, Output Drops, ECMP Member Counters
• WAN/Edge: Tunnel SLA, Provider-Interface Drops, Policer Hits
• Security: Policy Drops, Session/NAT Pressure, CPU/Queueing
• Service/Server: CPU, Disk, NIC Drops, TLS/Load Balancer Health

Schritt 4: Trennmessungen einsetzen

• 1 Stream vs. N Streams: Wenn nur 1 Stream langsam ist, sind RTT/Windowing/Serverlimits verdächtig.
• Alternativer Pfad: zweiter Tunnel/ISP – wenn es besser wird, liegt der Engpass im Pfad, nicht im Endsystem.
• Klein vs. groß: große Transfers hängen → MTU/MSS/PMTUD Kandidat.
• Client/Server tauschen: anderer Client oder anderes Zielsystem, um Endsystemlimits zu entlarven.

Paketanalyse: Wenn Sie Goodput wirklich belegen müssen

Wenn Metriken nicht reichen oder Sie beweisen müssen, warum ein Flow langsam ist, liefert PCAP harte Evidence. Sie sehen Window Growth, Retransmits, SACK, RTOs, Zero Window und Timing. Damit können Sie z. B. unterscheiden, ob ein Server nicht schnell genug liest (Receiver Window klein) oder ob das Netzwerk delayt/dropt.

• TCP Windowing: wächst das Fenster oder bleibt es klein?
• Retransmits/SACK: Indikator für Loss oder starke Delay-Spikes
• Zero Window: Empfänger kann nicht aufnehmen (Endsystem-/App-Backpressure)
• Handshake/RTT: Baseline für die Verbindung, wichtig für BDP

Für Analyseworkflows sind die Wireshark-Dokumentation und die tcpdump-Manpage gute, herstellerunabhängige Grundlagen.

QoS und Performance: Warum Priorisierung Throughput „verschieben“ kann

In vielen Netzen ist QoS der richtige Ansatz, um Echtzeitverkehr zu schützen. Aber QoS kann Throughput-Probleme auch verursachen, wenn Klassifikation falsch ist oder Policers zu eng sind. Deshalb gehört zur Throughput-Analyse immer die Frage: In welcher Klasse läuft der Traffic, und welche Behandlung erfährt diese Klasse?

• Classification: ist der Flow korrekt markiert (DSCP/CoS) und wird er korrekt gemappt?
• Policer: wird der Traffic gedrosselt oder gedroppt?
• Shaping: wird geglättet und erzeugt dadurch zusätzliche Verzögerung?
• Queue Drops: steigt die Drop-Rate in Best Effort während Peaks?

Operational Excellence: Baselines und High-Signal Telemetrie für Throughput

Ohne Normalzustand ist Throughput-Troubleshooting ein Streit über subjektive Wahrnehmung. Mit Baselines können Sie objektiv sagen, ob ein Throughput-Einbruch real ist und wo er entsteht. Für Throughput sind besonders hilfreich:

• Perzentile von RTT/Jitter: P95/P99 zeigen Stau-/Delay-Spitzen
• Queue Drops/Policer Hits: direkte Signale für Congestion/Policy-Limits
• Flow-Daten: Top Talker und Traffic-Shifts als Ursachenindikator
• Endsystem-Metriken: CPU/I/O/Socket-Queues, um Nicht-Netzwerk-Bottlenecks sichtbar zu machen
• Vorher/Nachher-Verifikation: gleiche Messpunkte, gleiche Tests, Rückkehr zur Baseline

Praktische Muster: Schnelle Zuordnung in der Triage

• Link nicht ausgelastet, aber Transfer langsam: RTT/Windowing/Endsystemlimit/Policer prüfen
• Viele Retransmits + steigende RTT: Congestion/Queueing/Microbursts wahrscheinlich
• Nur große Transfers betroffen: MTU/MSS/PMTUD Verdacht
• Nur manche Flows betroffen: ECMP/Member/Load Balancer Pool prüfen
• Throughput „gedeckelt“ auf festen Wert: Policing/Shaping oder Serverlimit wahrscheinlich

Weiterführende Quellen für Standards und Analysepraxis

• RFC 9293 (TCP) für Windowing, Retransmits und Congestion Control als Grundlage für Throughput-Verständnis
• RFC 791 (Internet Protocol) für IP-Grundlagen, MTU und Fragmentation
• Wireshark Dokumentation für PCAP-Analyse zu Window Growth, Retransmits und Timing
• tcpdump Manpage für performantes Capturing und BPF-Filter
• RFC Editor als Primärquelle für Netzwerkstandards und Protokollverhalten

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.