Funktionsweise des Netzwerklatenz- und Bandbreitenrechners
Der Netzwerklatenz- und Bandbreitenrechner ermittelt die reale Leistungsobergrenze eines einzelnen TCP-Flows auf Basis der physikalischen Bedingungen eines Netzwerkpfads. Durch die Eingabe von Leitungsgeschwindigkeit, Round-Trip-Time und Datengröße lässt sich sofort bestimmen, welcher Engpass die Verbindung einschränkt. Das Tool zeigt den erwarteten TCP-Durchsatz sowie die geschätzte Gesamtdauer der Übertragung an.
Alle Berechnungen werden lokal im Webbrowser des Nutzers ausgeführt. Es findet keine Übertragung der eingegebenen Daten an externe Server statt.
Eingabeparameter und Grenzwerte
Zur Konfiguration des Netzwerkpfads, der Nutzdaten und der TCP-Parameter stehen folgende Eingabefelder zur Verfügung:
- Leitungsgeschwindigkeit: Der langsamste Hop auf dem Pfad, was häufig der vertraglichen Geschwindigkeit des Tarifs entspricht. Der Wert muss größer als null sein.
- Round-Trip-Time (RTT): Die Ping-Zeit zur Gegenseite, wobei der höchste unter Last zu erwartende Wert eingetragen werden sollte. Der Wert muss größer als null sein.
- Datengröße: Die zu übertragenden Nutzdaten, wie beispielsweise eine Datei, ein Backup oder ein Datensatz. Der Wert muss größer als null sein.
- Empfangsfenster: Die Anzahl an Bytes, die der Empfänger puffern kann. Der Wert muss größer als null sein und darf maximal 1,073,725,440 Bytes betragen. Bleibt dieses Feld leer, wird kein Fensterlimit berücksichtigt.
- MSS (Bytes): Die Nutzdaten-Bytes pro Paket. Dieser Parameter muss eine ganze Zahl von Bytes zwischen 1 und 65,495 sein. Bleibt das Feld leer, werden Protokoll-Overhead und Paketverlust ignoriert.
- Paketverlust (%): Die durchschnittliche Wahrscheinlichkeit für Paketverlust. Der Wert muss zwischen 0 und 100 Prozent liegen. Ein leeres Feld oder der Wert 0 bedeuten, dass kein Verlustlimit angewendet wird.
- Anzeigekommastellen: Steuert die Dezimalpräzision der ausgegebenen Werte.
Über die Schaltfläche Beispiel laden lassen sich die Felder mit Testdaten füllen, während die Schaltfläche Leeren alle Eingaben zurücksetzt.
Berechnete Ergebnisse und Systemhinweise
Die Ergebnisse des Rechners sind in drei Bereiche unterteilt:
Durchsatz und Übertragungszeit
- Erwarteter TCP-Durchsatz: Der berechnete Durchsatz, ergänzt durch die Angabe des aktiven Engpasses in der Form „begrenzt durch
‹constraint›“. Als limitierende Faktoren werden die Leitungskapazität, das Empfangsfenster oder den Paketverlust dynamisch eingesetzt. - Übertragungszeit
- Zeit bis zum ersten Byte (1 RTT)
- Reine Datenübertragungszeit
- Bandbreite-Verzögerungs-Produkt
- Fenster zur Pfadauslastung
- Fensterbegrenzter Durchsatz
- Verlustbegrenzter Durchsatz (Mathis)
- Leitungslimit nach Overhead
- Protokolleffizienz
Dynamische Systemhinweise
Je nach den eingegebenen Werten gibt das Tool spezifische Hinweise aus:
- „Die Auslastung dieses Pfads erfordert ein Fenster von
‹window›— dies liegt über dem unskalierten Maximum von 65,535 Bytes, sodass beide Seiten TCP Window Scaling (RFC 7323) verhandeln müssen.“ - „Die Auslastung dieses Pfads erfordert
‹window›— dies liegt über dem größten Fenster, das TCP verhandeln kann (1,073,725,440 Bytes). Ein einzelner Flow auf diesem Pfad kann‹value›niemals überschreiten.“ - „Eine Erhöhung des Empfangsfensters auf
‹window›würde dieser Übertragung ermöglichen, bis zu‹value›zu erreichen.“ - „Verlust über 1% liegt außerhalb des zuverlässigen Bereichs des Mathis-Modells — betrachten Sie das Verlustlimit als optimistisch.“
Über die Schaltfläche Ergebnis kopieren können die berechneten Daten in die Zwischenablage übernommen werden.
Formeln und mathematische Einsetzung
Unter der Überschrift Formeln und Einsetzung schlüsselt das Tool jeden Berechnungsschritt detailliert auf:
- Hauptformel:
Durchsatz = min(Rate × Effizienz, Fenster ÷ RTT, MSS ÷ RTT ÷ √p) · BDP = Rate × RTT - Protokolleffizienz:
Protokolleffizienz = MSS ÷ (MSS + 78 B) = ‹mss› ÷ ‹frame› = ‹eff› (40 B Paket-Header + 38 B auf der Leitung) - Leitungslimit:
Leitungslimit = Rate × Effizienz = ‹rate› × ‹eff› = ‹value› - BDP:
BDP = Rate × RTT = ‹rate› × ‹rtt› = ‹bdp› = ‹bytes› - Fenster zur Pfadauslastung:
Fenster zur Pfadauslastung = BDP ÷ 8 = ‹bdp› → ‹window› - Fensterlimit:
Fensterlimit = Fenster ÷ RTT = ‹window› ÷ ‹rtt› = ‹value› - Verlustlimit (Mathis):
Verlustlimit (Mathis) = MSS ÷ RTT ÷ √p = ‹mss› ÷ ‹rtt› ÷ √‹p› = ‹value› - Erwarteter Durchsatz:
Erwarteter Durchsatz = das niedrigste dieser Limits = ‹value› → begrenzt durch ‹constraint› - Übertragungszeit:
Übertragungszeit = RTT + 8 × Größe ÷ Durchsatz = ‹rtt› + 8 × ‹size› ÷ ‹throughput› = ‹time›
Berechnungsregeln und Modellgrenzen
- Einheiten-Konventionen: Alle Berechnungen basieren auf dezimalen Einheiten (z. B. 1 kbit = 1.000 Bits, 1 MB = 1.000.000 Bytes). Dateimanager nutzen hingegen meist binäre Einheiten auf 1024er-Basis (wobei eine Datei von „100 MB“ in Wahrheit 100 MiB bzw. rund 104,86 dezimalen Megabytes entspricht).
- Protokoll-Overhead: Der Overhead orientiert sich am Standard-Ethernet und addiert 78 Bytes pro Paket (40 Bytes für TCP/IP-Header sowie 38 Bytes für den physischen Leitungs-Overhead).
- Grenzen des Mathis-Modells: Das Mathis-Modell setzt gleichmäßig verteilte, unabhängige Paketverluste voraus. Es liefert nur bei Verlustraten unter ca. 1 % verlässliche Werte. Liegt der Verlust darüber, wird die Warnung ausgegeben.
- Grenzen der Fensterskalierung: Das unskalierte TCP-Fenster ist auf 65.535 Bytes beschränkt. Erfordert der Pfad ein größeres Fenster, ist TCP Window Scaling nach RFC 7323 erforderlich. Das absolute Maximum für ein skaliertes Fenster liegt bei 1.073.725.440 Bytes; wird dieser Wert überschritten, greift der Hinweis.
- Ausschlüsse: Das Modell beschreibt einen eingeschwungenen Zustand eines einzelnen TCP-Flows. Dynamische Faktoren wie TCP Slow-Start, das Tuning der Überlastungssteuerung, langsame Empfänger oder TLS-Handshakes werden nicht berücksichtigt. Reale Übertragungen starten daher langsamer und können unter den berechneten Limits liegen.
Fehlermeldungen bei der Validierung
Sollten Eingabewerte unzulässig sein, gibt das Tool präzise Fehlermeldungen aus:
- Fehler beim Parsen:
"‹field›: „‹token›“ ist keine Zahl." - Leitungsgeschwindigkeit zu niedrig:
"Die Leitungsgeschwindigkeit muss größer als null sein." - Round-Trip-Time zu niedrig:
"Die Round-Trip-Time muss größer als null sein." - Datengröße zu niedrig:
"Die Datengröße muss größer als null sein." - Empfangsfenster zu niedrig:
"Das Empfangsfenster muss größer als null sein." - Empfangsfenster überschreitet RFC-Limit:
"TCP kann kein Fenster über 1,073,725,440 Bytes aushandeln (RFC 7323 Window Scaling)." - MSS außerhalb des gültigen Bereichs:
"Die MSS muss eine ganze Zahl von Bytes zwischen 1 und 65,495 sein." - Paketverlust außerhalb des gültigen Bereichs:
"Die Verlustrate muss zwischen 0 und 100 Prozent liegen." - Zahlenbereich überschritten:
"Ein Wert oder Zwischenergebnis überschreitet den unterstützten Zahlenbereich."
FAQ
Was ist das Bandbreite-Verzögerungs-Produkt und warum bestimmt es die Fenstergröße?
Das BDP – Leitungsgeschwindigkeit × Round-Trip-Time – ist die Datenmenge, die sich zu jedem Zeitpunkt im Transit befindet. TCP kann maximal ein unbestätigtes Fenster ausstehend haben, sodass ein Fenster, das kleiner als das BDP ist, die Leitung teilweise leer lässt: Bei 100 Mbit/s mit einer RTT von 50 ms fasst die Leitung 625 kB, und ein Fenster von 65,535 Bytes füllt kaum ein Zehntel davon. Deshalb benötigen schnelle, lange Pfade das TCP Window Scaling (RFC 7323), welches das verhandelbare Maximum von 65,535 Bytes auf etwa 1 GB anhebt.
Warum ist meine Übertragung langsamer als die Leitungsgeschwindigkeit, für die ich bezahle?
Ein einzelner TCP-Flow stößt auf drei unabhängige Limits, und das niedrigste gewinnt. Der Protokoll-Overhead reduziert die Leitung selbst um etwa 5% – ein Standard-Ethernet-Frame transportiert 1,460 Nutzdaten-Bytes von 1,538 Bytes auf der Leitung. Das Empfangsfenster deckelt den Durchsatz bei window ÷ RTT, sodass das klassische Fenster von 65,535 Bytes einen Pfad mit 50 ms RTT auf etwa 10.5 Mbit/s beschränkt, egal wie schnell die Leitung ist. Und Paketverlust deckelt ihn bei (MSS ÷ RTT) ÷ √loss. Das obige Ergebnis nennt das Limit, das für Ihre Zahlen bindend ist.
Wie begrenzt Paketverlust den TCP-Durchsatz?
TCP interpretiert Paketverlust als Überlastung und halbiert seine Senderate bei jedem Verlustereignis, sodass selbst winzige Verlustraten auf schnellen Pfaden eine große Rolle spielen. Das Mathis-Modell schätzt das Limit auf (MSS ÷ RTT) ÷ √p – bei 0.01% Verlust auf einem Pfad mit 50 ms RTT und einer MSS von 1,460 Bytes sind das etwa 23 Mbit/s, unabhängig von der Leitungsgeschwindigkeit. Das Modell setzt gleichmäßig verteilte, unabhängige Verlustereignisse voraus; unterhalb von etwa 1% bildet es die Realität gut ab, bei stoßweisem Verlust ist es optimistisch.
Sind die Megabytes hier dieselben wie in meinem Dateimanager?
Nicht ganz. Diese Seite verwendet dezimale Einheiten, wie in der Netzwerktechnik üblich: 1 kbit = 1,000 Bits und 1 MB = 1,000,000 Bytes. Die meisten Dateimanager rechnen in Einheiten auf 1024er-Basis, die oft fälschlicherweise als MB bezeichnet werden – eine Datei mit „100 MB“ dort ist meist 100 MiB ≈ 104.86 dezimale MB, sodass die Übertragung etwa 5% länger dauert als der dezimale Wert vermuten lässt. Tragen Sie hier 104.86 MB ein, um dies exakt abzugleichen.