Die Kurzantwort:

Goodput beschreibt die tatsächlich nutzbare Datenrate auf Anwendungsebene. Im Unterschied zu Bandbreite oder technischem Durchsatz berücksichtigt Goodput nur die Nutzdaten, die erfolgreich bei der Anwendung ankommen. Protokoll-Overhead, verlorene Pakete, erneut übertragene Daten, TCP-Retransmissions und andere nicht nutzbare Datenanteile reduzieren den Goodput. Deshalb ist Goodput eine besonders praxisnahe Messgröße, wenn bewertet werden soll, wie viel Leistung eine Anwendung wirklich erhält.

Goodput zeigt,was bei der Anwendung wirklich ankommt

In Netzwerken wird häufig über Bandbreite und Durchsatz gesprochen. Eine Verbindung hat zum Beispiel 1 Gbit/s Bandbreite. Eine Messung zeigt vielleicht 600 Mbit/s Durchsatz. Trotzdem kann die Anwendung deutlich weniger nutzbare Datenleistung erhalten.

Genau hier kommt Goodput ins Spiel.

Goodput beschreibt nicht die theoretische Kapazität einer Verbindung und auch nicht jede technisch übertragene Datenmenge. Goodput betrachtet die Nutzdaten, die tatsächlich erfolgreich bei der Anwendung ankommen und dort verwendet werden können.

Damit ist Goodput näher an der Anwender- und Anwendungserfahrung als viele klassische Netzwerkkennzahlen. Für eine Anwendung ist nicht entscheidend, wie viele Bits insgesamt über eine Leitung bewegt wurden. Entscheidend ist, wie viele verwertbare Nutzdaten stabil und rechtzeitig ankommen.

Ein Netzwerk kann also hohe Bandbreite und scheinbar guten Durchsatz haben, aber trotzdem niedrigen Goodput liefern, wenn viele Daten erneut übertragen werden müssen oder durch Overhead, Verluste und Protokolleffekte keine nutzbare Anwendungsleistung entsteht.

Was bedeutet Goodput im Netzwerk?

Goodput ist die tatsächlich nutzbare Datenrate einer Anwendung. Er beschreibt die Menge an erfolgreichen Nutzdaten pro Zeiteinheit.

Vereinfacht gesagt: Bandbreite beschreibt, was theoretisch möglich ist. Durchsatz beschreibt, was technisch übertragen wird. Goodput beschreibt, was davon als nutzbare Anwendungsdaten ankommt.

Ein Beispiel: Eine Verbindung hat 1 Gbit/s Bandbreite. Während einer Datenübertragung werden technisch 700 Mbit/s übertragen. Davon entfallen jedoch Teile auf Protokoll-Overhead, Wiederholungen, Retransmissions und nicht nutzbare Datenanteile. Bei der Anwendung kommen effektiv nur 520 Mbit/s Nutzdaten an.

In diesem Fall wäre der Goodput niedriger als der gemessene technische Durchsatz.

Goodput ist deshalb besonders interessant, wenn die tatsächliche Leistungsfähigkeit einer Anwendung bewertet werden soll.

Unterschied zwischen Bandbreite, Durchsatz und Goodput

Bandbreite, Durchsatz und Goodput werden in der Praxis häufig vermischt. Für eine saubere Analyse müssen sie getrennt betrachtet werden.

Bandbreite

Bandbreite beschreibt die theoretisch verfügbare Kapazität einer Verbindung. Eine Straße hat vier Spuren. Das entspricht der Bandbreite.

Durchsatz

Durchsatz beschreibt die tatsächlich übertragene Datenmenge pro Zeiteinheit. Die Anzahl aller Fahrzeuge, die über die Straße fahren, entspricht dem Durchsatz.

Goodput

Goodput beschreibt die erfolgreich nutzbaren Anwendungsdaten pro Zeiteinheit. Die Anzahl der Fahrzeuge, die pünktlich und ohne Umweg am richtigen Ziel ankommen, entspricht dem Goodput.

Für Anwendungen ist Goodput besonders wichtig, weil er die nutzbare Leistung beschreibt. Eine hohe Bandbreite hilft wenig, wenn Paketverlust, Retransmissions, Overhead oder Engpässe dazu führen, dass wenig verwertbare Nutzdaten ankommen.

Warum ist Goodput wichtig?

Goodput ist wichtig, weil viele Performance-Probleme erst auf Anwendungsebene sichtbar werden. Technische Messwerte können auf den ersten Blick gut aussehen, während Anwendungen trotzdem langsam reagieren.

In solchen Fällen reicht es nicht aus, nur Bandbreite oder Interface-Auslastung zu betrachten. Entscheidend ist, wie viel nutzbare Leistung bei der Anwendung wirklich ankommt.

Goodput hilft, diese Perspektive sichtbar zu machen.

Typische Situationen sind:

  • Dateiübertragungen dauern länger als erwartet
  • Backups erreichen nicht die geplante Geschwindigkeit
  • Replikationen laufen in zu enge Zeitfenster
  • Cloud-Migrationen sind langsamer als geplant
  • Datenbankabfragen übertragen weniger Nutzdaten als erwartet
  • zentrale Fachanwendungen wirken träge
  • Storage-Zugriffe über WAN sind langsam
  • VPN-Verbindungen erreichen nicht die erwartete Leistung
  • API-Kommunikation ist instabil oder verzögert
  • große Downloads oder Uploads schwanken stark

Warum Goodput niedriger als Durchsatz sein kann

Goodput ist häufig niedriger als der technische Durchsatz. Das liegt daran, dass nicht jede übertragene Datenmenge auch nutzbare Anwendungsinformation ist.

Das bedeutet: Eine Verbindung kann viel Datenverkehr transportieren, aber ein Teil davon trägt nicht zur eigentlichen Anwendungsleistung bei.

Besonders bei TCP-basierten Anwendungen können Paketverlust und Retransmissions den Goodput deutlich reduzieren. Daten werden erneut übertragen, aber aus Anwendungssicht entsteht dadurch keine zusätzliche Nutzleistung. Es wird lediglich ein vorheriger Verlust korrigiert.

Goodput kann reduziert werden durch:

  • Protokoll-Overhead (TCP-, IP-Header)
  • Verschlüsselungs-, VPN- und TLS-Overhead
  • Paketverlust
  • TCP-Retransmissions
  • Duplikate
  • fehlerhafte oder verworfene Pakete
  • Fragmentierung
  • Paket-Reordering
  • Verzögerungen durch Firewalls
  • Proxy- oder Security-Inspection-Systeme
  • Microbursts
  • Queue Drops und Interface Drops
  • hohe RTT
  • kleine TCP-Fenster
  • Applikationsverhalten

Goodput und die anderen Kennzahlen

TCP-Retransmissions

TCP-Retransmissions sind einer der wichtigsten Gründe für niedrigen Goodput. Wenn TCP Daten erneut übertragen muss, wird Bandbreite verbraucht, ohne dass neue Nutzdaten bei der Anwendung ankommen.

Ein Beispiel: Eine Anwendung überträgt eine Datei. Aufgrund von Paketverlust gehen einige TCP-Segmente verloren. TCP sendet diese Segmente erneut. Die Leitung transportiert dadurch zusätzliche Daten, aber die Anwendung erhält nicht mehr neue Nutzdaten. Sie erhält nur die fehlenden Daten ein zweites Mal.

Der technische Durchsatz kann dadurch noch relativ hoch wirken. Der Goodput sinkt jedoch, weil ein Teil der übertragenen Daten aus Wiederholungen besteht.

Das erklärt, warum Anwender manchmal langsame Übertragungen erleben, obwohl Monitoring-Systeme zeigen, dass Datenverkehr stattfindet. Entscheidend ist nicht nur, dass Daten übertragen werden, sondern ob es neue, verwertbare Nutzdaten sind.

Paketverlust

Paketverlust reduziert Goodput direkt oder indirekt. Wenn Pakete verloren gehen, kommen Nutzdaten nicht beim Ziel an. Bei TCP müssen diese Daten erneut übertragen werden. Bei UDP-basierten Anwendungen können verlorene Pakete möglicherweise gar nicht nachgeliefert werden.

Bei TCP führt Paketverlust häufig zu: TCP-Retransmissions, reduzierter Senderate, längeren Antwortzeiten, sinkendem Durchsatz und niedrigerem Goodput.

Besonders kritisch ist gebündelter Paketverlust. Kurze Phasen mit mehreren verlorenen Paketen können TCP deutlich ausbremsen und den Goodput stark reduzieren. Solche Ereignisse können durch Microbursts, Queue Drops oder überlastete Komponenten entstehen.

Im Durchschnitt kann der Paketverlust niedrig wirken. Für eine konkrete Übertragung kann ein kurzer Verlustmoment trotzdem erhebliche Auswirkungen haben.

RTT

Round Trip Time beeinflusst Goodput vor allem bei TCP-basierten Anwendungen. TCP ist auf Bestätigungen angewiesen. Je länger Rückmeldungen dauern, desto stärker kann sich die Verzögerung auf die Übertragungsleistung auswirken.

Bei hoher RTT dauert es länger, bis TCP erkennt, ob Daten angekommen sind oder erneut übertragen werden müssen. In Kombination mit Paketverlust können sich die Effekte verstärken.

Eine WAN-Verbindung mit hoher Bandbreite kann deshalb trotzdem niedrigen Goodput liefern, wenn RTT und Paketverlust ungünstig zusammenwirken.

Das ist besonders relevant bei: Standortvernetzung, VPN-Verbindungen, Cloud-Anbindungen, internationalen Verbindungen, Rechenzentrumsverbindungen, Datenbankzugriffen über WAN, Storage- oder Backup-Verbindungen sowie Dateiübertragungen über weite Distanzen.

Goodput zeigt dann besser als Bandbreite, welche Leistung die Anwendung wirklich erhält.

Microbursts

Microbursts können Goodput deutlich reduzieren. Während eines Microbursts entstehen kurzfristige Lastspitzen. Wenn Queues überlaufen oder Pakete verworfen werden, entstehen Paketverlust und TCP-Retransmissions.

Dadurch sinkt der Goodput.

Das Problem ist, dass Microbursts in Durchschnittswerten oft nicht sichtbar sind. Eine Verbindung kann im Fünf-Minuten-Durchschnitt nur zu 40 Prozent ausgelastet sein. Trotzdem können kurze Lastspitzen entstehen, die Pakete verwerfen und TCP ausbremsen.

Aus Anwendungssicht zeigt sich das als schwankende Übertragungsleistung. Eine Dateiübertragung startet schnell, bricht dann ein, erholt sich wieder und schwankt erneut. Die theoretische Bandbreite bleibt unverändert. Der Goodput ist aber nicht stabil.

Eine kontinuierliche Messung hilft, solche Zusammenhänge sichtbar zu machen.

Goodput und Protokoll-Overhead

Nicht alle übertragenen Daten sind Nutzdaten. Jedes Netzwerkprotokoll benötigt Header, Steuerinformationen und Verwaltungsdaten. Diese Anteile sind notwendig, zählen aber nicht als Nutzdaten der Anwendung.

Beispiele für Overhead sind: Ethernet-Header, IP-Header, TCP- oder UDP-Header, TLS-Overhead, VPN-Kapselung, Tunnel-Overhead, Verschlüsselungsinformationen, Protokollbestätigungen, Steuerpakete, Keepalives und Session-Management.

Je nach Protokoll, Paketgröße und Architektur kann dieser Overhead unterschiedlich stark ins Gewicht fallen.

Bei großen Datenübertragungen ist der relative Overhead oft geringer. Bei vielen kleinen Transaktionen kann der Overhead dagegen stärker auffallen. Deshalb können Anwendungen mit vielen kleinen Anfragen trotz ausreichender Bandbreite einen niedrigeren Goodput erzielen als erwartet.

Goodput bei Anwendungen mit vielen kleinen Transaktionen

Goodput ist nicht nur bei großen Dateiübertragungen relevant. Auch transaktionsbasierte Anwendungen können betroffen sein.

Viele Fachanwendungen, Datenbanksysteme oder APIs arbeiten mit vielen kleinen Anfragen und Antworten. Jede einzelne Übertragung enthält nicht nur Nutzdaten, sondern auch Protokollinformationen, Bestätigungen und mögliche Wartezeiten.

Wenn zusätzlich RTT, Paketverlust oder TCP-Retransmissions auftreten, sinkt die nutzbare Anwendungsleistung.

Das kann dazu führen, dass eine Anwendung langsam wirkt, obwohl keine großen Datenmengen übertragen werden. Die Bandbreite ist dann nicht der Engpass. Die tatsächliche Nutzdatenleistung wird durch Verzögerungen, Protokollverhalten und Wiederholungen begrenzt.

Goodput hilft, diese Perspektive besser zu verstehen.

Goodput bei VPN, Cloud und Security Inspection

VPNs, Cloud-Verbindungen und Sicherheitskomponenten können Goodput beeinflussen. Sie fügen häufig zusätzliche Verarbeitungsschritte und Overhead hinzu.

Beispiele: VPN-Kapselung vergrößert Pakete. Verschlüsselung benötigt Rechenleistung. Firewalls prüfen Datenverkehr. Proxys terminieren oder inspizieren Verbindungen. Security Inspection analysiert Inhalte. Cloud-Gateways leiten Verkehr über zusätzliche Pfade. Tunnel können MTU- oder Fragmentierungsprobleme verursachen. SSL/TLS-Inspection kann zusätzliche Verzögerungen erzeugen.

Diese Faktoren müssen nicht automatisch problematisch sein. Sie sind oft notwendig und sinnvoll. Für die Performance-Analyse ist jedoch wichtig zu verstehen, dass sie die nutzbare Datenleistung beeinflussen können.

Eine Verbindung kann also technisch erreichbar sein und ausreichend Bandbreite bieten, aber durch VPN, Security Inspection oder Cloud-Pfade niedrigeren Goodput liefern.

Warum Goodput für Anwender entscheidend ist

Anwender interessiert selten, welche Bandbreite vertraglich bereitgestellt wird oder wie hoch ein Interface ausgelastet ist. Entscheidend ist, ob die Anwendung funktioniert.

Goodput liegt näher an diesen Fragen als Bandbreite oder reine Auslastung. Er beschreibt die nutzbare Anwendungsleistung und damit die Qualität, die für Prozesse tatsächlich relevant ist.

Aus Anwendersicht zählen Fragen wie:

  • Lädt die Datei schnell genug?
  • Antwortet die Anwendung zügig?
  • Läuft die Replikation im geplanten Zeitfenster?
  • Ist der Datenbankzugriff stabil?
  • Funktioniert der Cloud-Zugriff ohne Verzögerung?
  • Bleibt die VPN-Verbindung performant?
  • Sind große Uploads und Downloads zuverlässig?
  • Werden Geschäftsprozesse rechtzeitig abgeschlossen?

Warum Durchschnittswerte beim Goodput täuschen können

Auch Goodput sollte nicht nur als Durchschnittswert betrachtet werden. Eine Übertragung kann im Mittel akzeptabel wirken, aber während bestimmter Zeitfenster stark einbrechen.

Ein Beispiel: Über eine Stunde liegt der durchschnittliche Goodput bei 400 Mbit/s. Während mehrerer kurzer Zeitfenster fällt er jedoch auf 80 Mbit/s ab. Genau in diesen Zeitfenstern laufen kritische Datenbank- oder Replikationsprozesse. Die Anwendung erlebt also ein echtes Problem, obwohl der Durchschnittswert noch akzeptabel aussieht.

Wichtig sind daher: Minimalwerte, Maximalwerte, Zeitverlauf, Schwankungen, Einbrüche, betroffene Anwendungen, betroffene Strecken, gleichzeitige Paketverluste, TCP-Retransmissions, RTT-Spitzen, Microbursts, Drops und Anwendungsereignisse.

Goodput muss immer im zeitlichen Kontext bewertet werden.

Wie misst man Goodput?

Goodput kann auf verschiedene Weise gemessen oder abgeleitet werden. Entscheidend ist, dass die Messung die tatsächlich nutzbaren Anwendungsdaten betrachtet.

Aktive Messungen

Aktive Messungen erzeugen gezielt Testverkehr. Dadurch lassen sich Datenraten kontrolliert messen. Wichtig ist, die Ergebnisse nicht nur als Rohdurchsatz zu interpretieren, sondern Overhead, Paketverlust und Wiederholungen zu berücksichtigen.

Passive Analysen

Passive Analysen untersuchen vorhandenen Datenverkehr. Das kann helfen, TCP-Retransmissions, Overhead, Paketverlust und tatsächliche Nutzdatenraten zu erkennen.

Anwendungsnahe Messungen

Anwendungsnahe Messungen betrachten, welche Nutzdatenmenge eine Anwendung tatsächlich erfolgreich überträgt. Das kann zum Beispiel bei Dateiübertragungen, Backups, Replikationen oder API-Kommunikation erfolgen.

Kontinuierliche Ende-zu-Ende-Messung

Eine kontinuierliche Ende-zu-Ende-Messung hilft, Goodput-Einbrüche mit anderen Kennzahlen zu verbinden. Besonders wertvoll ist der Zusammenhang mit RTT, Paketverlust, TCP-Retransmissions, Microbursts, Queue Drops und Durchsatz.

Goodput und Durchsatzmessungen

Durchsatzmessungen zeigen, wie viele Daten technisch übertragen werden. Goodput geht einen Schritt weiter und betrachtet die nutzbaren Anwendungsdaten.

Bei einer einfachen Durchsatzmessung kann ein Wert gut aussehen, obwohl ein Teil der übertragenen Daten aus Overhead oder Wiederholungen besteht. Für die Anwendung zählt jedoch nur, was erfolgreich als Nutzdaten ankommt. Deshalb sollten Durchsatzmessungen möglichst anwendungsnah interpretiert werden.

Wichtige Fragen sind: Welche Datenmenge ist wirklich Nutzdaten? Wie viel Overhead entsteht durch Protokolle? Gibt es TCP-Retransmissions? Werden Pakete verloren? Gibt es Duplikate? Wird VPN- oder Tunnel-Overhead berücksichtigt? Gibt es Security Inspection? Ist die Anwendung transaktionsbasiert oder datenstrombasiert? Wird die Messung durch Server, Storage oder Client begrenzt?

Goodput ist besonders wertvoll, wenn technische Netzwerkdaten mit der tatsächlichen Anwendungsleistung abgeglichen werden sollen.

Goodput und Ende-zu-Ende-Messung

Goodput ist besonders wertvoll, wenn er im Ende-zu-Ende-Kontext betrachtet wird. Eine Anwendung erlebt die gesamte Kommunikationsstrecke, nicht nur ein einzelnes Interface.

Damit wird Goodput zu einer praxisnahen Kennzahl für tatsächliche Anwendungsperformance.

Eine Ende-zu-Ende-Betrachtung beantwortet Fragen wie:

  • Wie viel nutzbare Datenleistung kommt zwischen Standort und Rechenzentrum an?
  • Sinkt der Goodput zu bestimmten Zeiten?
  • Gibt es Unterschiede zwischen Richtungen?
  • Sind WAN, VPN, Cloud oder Firewall beteiligt?
  • Treten gleichzeitig RTT-Spitzen auf?
  • Gibt es Paketverlust oder TCP-Retransmissions?
  • Fallen Goodput-Einbrüche mit Microbursts oder Queue Drops zusammen?
  • Sind bestimmte Anwendungen oder Standorte betroffen?
  • Gibt es Zusammenhänge mit Backups, Replikationen oder Synchronisationen?

Welche Goodput-Werte sind akzeptabel?

Es gibt keinen universellen Goodput-Grenzwert, der für alle Netzwerke gilt. Ob ein Wert gut oder schlecht ist, hängt vom Anwendungsfall ab.

Eine Backup-Strecke kann andere Anforderungen haben als eine interaktive Fachanwendung. Eine Cloud-Migration hat andere Anforderungen als eine API-Kommunikation. Deshalb muss Goodput immer im Kontext der Anwendung bewertet werden.

Wichtige Fragen sind:

  • Welche Anwendung wird betrachtet?
  • Welche Datenmenge muss übertragen werden?
  • Gibt es feste Zeitfenster?
  • Welche Bandbreite steht theoretisch zur Verfügung?
  • Welche Baseline gilt im Normalbetrieb?
  • Wie stark schwankt der Goodput?
  • Gibt es Paketverlust oder Retransmissions?
  • Wird über WAN, VPN oder Cloud übertragen?
  • Gibt es Service-Level-Anforderungen?
  • Welche Auswirkungen hat ein niedriger Goodput auf Geschäftsprozesse?
Praxisbeispiel

Langsame Backups trotz 1 Gbit/s Bandbreite

Ein Unternehmen betreibt eine zentrale Datei- und Backup-Infrastruktur. Die Standorte sind über WAN-Verbindungen mit 1 Gbit/s angebunden. Die Bandbreite scheint ausreichend. Trotzdem laufen Backups regelmäßig länger als geplant, und Dateiübertragungen schwanken stark.

Das klassische Monitoring zeigt keine dauerhaft hohe Auslastung. Ping-Werte sind meist unauffällig. Auch der technische Durchsatz wirkt zeitweise akzeptabel.

Eine genauere Ende-zu-Ende-Analyse zeigt jedoch, dass während bestimmter Zeitfenster TCP-Retransmissions und Paketverlust auftreten. Gleichzeitig sinkt der Goodput deutlich. Ein Teil der übertragenen Daten besteht aus erneuten TCP-Übertragungen. Zusätzlich verursachen VPN-Kapselung und Security Inspection Overhead.

Die Anwendung erhält dadurch deutlich weniger nutzbare Datenrate als erwartet.

Nach einer Anpassung der Übertragungszeiten, einer Prüfung der Firewall-Verarbeitung und einer Optimierung der Priorisierung sinken Paketverlust und Retransmissions. Der Goodput steigt, und die Backups laufen stabiler im vorgesehenen Zeitfenster.

Das Beispiel zeigt: Bandbreite und technischer Durchsatz reichen nicht aus, wenn bewertet werden soll, was bei der Anwendung wirklich nutzbar ankommt.

Best Practicesim Umgang mit Goodput

Besonders wichtig ist, Goodput nicht als isolierte Zahl zu betrachten. Erst der Zusammenhang mit Paketverlust, RTT, Retransmissions, Durchsatz und Anwendung macht die Kennzahl aussagekräftig.

Für eine sinnvolle Bewertung von Goodput haben sich folgende Maßnahmen bewährt:

  • Goodput von Bandbreite und Durchsatz unterscheiden
  • Nutzdatenleistung anwendungsnah betrachten
  • Protokoll-Overhead berücksichtigen
  • TCP-Retransmissions analysieren
  • Paketverlust und Drops prüfen
  • RTT und One-Way Delay einbeziehen
  • Microbursts als mögliche Ursache berücksichtigen
  • VPN-, Tunnel- und Security-Overhead beachten
  • Zeitverlauf statt nur Durchschnittswerte auswerten
  • betroffene Anwendungen und Kommunikationsstrecken identifizieren
  • Baselines für normalen Betrieb definieren
  • Messwerte mit Anwender- und Prozesszeiten abgleichen
  • Ende-zu-Ende-Messungen für kritische Strecken einsetzen
  • Server, Storage, Clients und Anwendungen als mögliche Begrenzung einbeziehen
  • Änderungen an Firewalls, VPNs, Providern oder Cloud-Zugängen gezielt überwachen

Zusammengefasst

Goodput beschreibt die tatsächlich nutzbare Datenrate auf Anwendungsebene. Er unterscheidet sich von Bandbreite und technischem Durchsatz, weil er nur die erfolgreich verwertbaren Nutzdaten betrachtet.

Damit ist Goodput eine besonders praxisnahe Messgröße für Netzwerk-Performance. Er zeigt, wie viel Leistung eine Anwendung wirklich erhält. Protokoll-Overhead, VPN-Kapselung, Security Inspection, Paketverlust, TCP-Retransmissions, Microbursts und Drops können den Goodput deutlich reduzieren.

Ein Netzwerk kann daher ausreichend Bandbreite haben und trotzdem niedrigen Goodput liefern. Für Anwender und Geschäftsprozesse ist genau diese nutzbare Leistung entscheidend.

Eine kontinuierliche Ende-zu-Ende-Messung hilft, Goodput-Einbrüche sichtbar zu machen und mit Ursachen wie Paketverlust, RTT-Spitzen, TCP-Retransmissions, Queue Drops oder Microbursts zu verbinden. So entsteht eine belastbare Grundlage, um tatsächliche Anwendungsperformance statt nur theoretischer Leitungskapazität zu bewerten.

Häufig gestellte Fragen zu Goodput

Goodput beschreibt die tatsächlich nutzbare Datenrate einer Anwendung. Er zeigt, wie viele verwertbare Nutzdaten erfolgreich ankommen.

Durchsatz beschreibt die technisch übertragene Datenmenge. Goodput betrachtet nur die erfolgreich nutzbaren Anwendungsdaten und zieht Overhead, Verluste oder Wiederholungen gedanklich ab.

Weil Protokoll-Overhead, TCP-Retransmissions, Paketverlust, VPN-Kapselung, Security Inspection oder Duplikate Daten übertragen, die nicht als neue Nutzdaten bei der Anwendung ankommen.

Weil Anwendungen nicht von theoretischer Bandbreite profitieren, sondern von nutzbarer Datenleistung. Goodput zeigt, was tatsächlich verwertbar ankommt.

Ja. Paketverlust, hohe RTT, TCP-Retransmissions, Microbursts, Drops, VPN-Overhead oder überlastete Sicherheitskomponenten können den Goodput reduzieren.

Goodput lässt sich durch anwendungsnahe Messungen, aktive Tests, passive Traffic-Analysen oder kontinuierliche Ende-zu-Ende-Messungen bewerten. Wichtig ist der Zusammenhang mit Paketverlust, RTT, Retransmissions und Durchsatz.

Tipp von NETCOR

Bewerten Sie bei Performance-Problemen nicht nur Bandbreite oder technischen Durchsatz. Entscheidend ist, wie viel nutzbare Datenleistung bei der Anwendung wirklich ankommt. Wenn Goodput sinkt, obwohl Bandbreite verfügbar ist, sollten Paketverlust, TCP-Retransmissions, RTT-Spitzen, Microbursts, Queue Drops, VPN-Overhead und Security Inspection gemeinsam betrachtet werden. Eine kontinuierliche 24/7-Ende-zu-Ende-Messung macht sichtbar, ob die Anwendung tatsächlich die Leistung erhält, die das Netzwerk theoretisch bereitstellen sollte.

Live erleben

GeNiEnd2End Kennenlernen

Nutzbare Leistung sichtbar machen, statt Bandbreite zu raten: In unserer Live-Demo zeigen wir Ihnen, wie GeNiEnd2End Goodput, Durchsatz, Paketverlust und Retransmissions auf Ihren Kommunikationsstrecken kontinuierlich erfasst und nachvollziehbar macht.

Demo buchen

Weitere Grundlagen-Artikel

Was ist Durchsatz?

Bedeutung, Ursachen und Messung von Durchsatz – was im Netzwerk wirklich ankommt.

Zum Artikel

Bandbreite vs. Durchsatz

Der Unterschied einfach erklärt – und warum hohe Bandbreite keinen hohen Durchsatz garantiert.

Zum Artikel

Was sind TCP-Retransmissions?

Warum TCP Daten erneut überträgt – und wie Retransmissions den Durchsatz beeinflussen.

Zum Artikel