ForHosting KIT · Entwickler-Tools

TCP-Fenstergröße für Durchsatz

100 Mbit/s bei 50 ms Umlaufzeit verlangen 625.000 Bytes unterwegs, weit mehr als das klassische TCP-Fenster mit 65.535 Bytes: Geben Sie Rate und RTT ein und erhalten Sie Fenstergröße und Skalierungsfaktor, die Ihre Leitung füllen. Kostenlos in Ihrem Browser.

Kostenlos
Läuft in Ihrem Browser
Ohne Anmeldung
Ihre Daten bleiben auf Ihrem Gerät

Im Browser ausführen – kostenlos API ansehen

Nutzen Sie es über WebAPIE-MailTelegramApp bald

Rechenbeispiel

Wenn Sie eingeben

Durchsatz (Mbps): 100
Rtt ms: 50

Erhalten Sie

Fenster (Bytes): 625.000
Fenster (Bits): 5.000.000
Fenster (KiB): 610,3515625
Fenster (MiB): 0,5960464478

Lange, hochkapazitive Netze —hohe Bandbreite multipliziert mit hoher Latenz— lassen TCP verhungern, wenn das Empfangsfenster nicht groß genug ist, um die Leitung über eine volle Round-Trip-Zeit gefüllt zu halten. Netzwerker, SREs und Studierende, die WAN-Strecken, Satellitenpfade oder Cloud-Tunnel zwischen Regionen dimensionieren, brauchen das Bandbreite-Verzögerungs-Produkt, keine Faustregel. Dieser Rechner für die TCP-Fenstergröße zum Durchsatz nimmt Zieldurchsatz in Megabit pro Sekunde und Pfad-RTT in Millisekunden entgegen, multipliziert sie mit dem exakten Umrechnungsfaktor zu Bytes und liefert das erforderliche Fenster in Bytes, Bits, Kibibytes und Mebibytes. Er meldet außerdem, wann das klassische unskalierte TCP-Fenster von 65535 Bytes zu klein ist, empfiehlt den minimalen Window-Scale-Shift nach RFC 1323 und zeigt den maximalen Durchsatz, den Sie ohne Skalierung bei gleichem RTT noch erreichen könnten.

Warum die Fenstergröße Bandbreite mal Verzögerung ist

TCP darf unbestätigte Daten nur bis zum vom Empfänger angezeigten Fenster (und dem Congestion Window des Senders) ausstehend haben. Auf einem Pfad mit Kapazität C Bit pro Sekunde und Round-Trip-Zeit R Sekunden muss die Menge der Daten im Flug, um die Leitung voll auszulasten, C mal R betragen — das Bandbreite-Verzögerungs-Produkt. Teilen Sie durch acht, um dieses Produkt in Bytes auszudrücken; diese Zahl ist das minimale Empfangsfenster für einen Vollraten-Transfer im Beharrungszustand, sofern die Überlaststeuerung nicht limitiert.

In handlichen Engineering-Einheiten ergeben Megabit pro Sekunde mal Millisekunden mal einhundertfünfundzwanzig Bytes, weil ein Megabit pro Sekunde einhundertfünfundzwanzigtausend Bytes pro Sekunde ist und eine Millisekunde ein Tausendstel einer Sekunde. Beispiel: einhundert Megabit pro Sekunde bei fünfzig Millisekunden brauchen sechshundertfünfundzwanzigtausend Bytes im Flug. Ohne diese Puffertiefe leert der Sender sein Fenster, stoppt und wartet auf Acknowledgements, sodass der gemessene Goodput weit unter der Leitungsrate bleibt, obwohl die physische Verbindung in Ordnung ist.

Dieser Endpunkt dimensioniert das Fenster nur aus dem BDP; er modelliert weder Paketverlust, Slow Start noch Bufferbloat — das sind separate Stellschrauben der Kapazitätsplanung.

Wo ein TCP-Fenster-Durchsatz-Rechner seinen Nutzen hat

WAN- und Rechenzentrumsplaner nutzen einen TCP-Fenstergrößen-Rechner vor Leitungsaufrüstungen, damit Empfangspuffer und OS-Defaults zum neuen BDP passen statt zu raten. Cloud-Architekten, die regionsübergreifende Datenbankreplikation oder Object-Storage-Transfers dimensionieren, wandeln veröffentlichtes RTT und Ziel-Megabit in konkrete Puffer-Bytes für Lasttestpläne um. Satelliten- und Mobil-Backhaul-Teams zeigen, warum Multi-Megabit-Strecken noch kriechen, wenn das RTT hunderte Millisekunden beträgt und Window Scale aus ist.

Unterricht und Zertifizierungslabore brauchen ein deterministisches Orakel für Hausaufgaben zum Bandbreite-Verzögerungs-Produkt, das Lehrbuch-Einheiten ohne Tabellenfehler trifft. Fehlgeschlagene Validierung wird nicht berechnet. Lassen Sie Verlust, Pacing und Überlaststeuerung in Ihren eigenen Tools; nutzen Sie diesen Endpunkt als einzige Wahrheitsquelle für die BDP-Arithmetik, damit Docs, Runbooks und Edge-Worker gleich planen.

Anwendungsfälle

WAN- und LFN-Kapazitätsplanung

Wandeln Sie Ziel-Mbps und gemessenes RTT in das Empfangsfenster (und den Scale-Shift) um, das nötig ist, um einen langen, hochkapazitiven Netzpfad zu füllen.

Dimensionierung regionsübergreifender Cloud-Transfers

Dimensionieren Sie Socket-Puffer für Datenbankreplikation, Backup oder Objekte, damit der Durchsatz nicht durch ein unskaliertes 64-KiB-Fenster gedeckelt wird.

Häufige Fragen

Was ist das Bandbreite-Verzögerungs-Produkt (BDP)?

BDP ist Leitungsrate mal RTT: die Daten, die im Flug sein müssen, um den Pfad voll zu halten. Das angezeigte TCP-Fenster sollte mindestens so viele Bytes haben (ohne Congestion-Grenzen).

Modelliert dies Paketverlust oder Überlaststeuerung?

Nein. Es dimensioniert das Fenster nur aus dem BDP, damit die Leitung gefüllt werden kann. Verlust, RTT-Varianz und Congestion Windows sind separat; nutzen Sie dafür andere Tools.

Wie berechne ich die TCP-Fenstergröße aus Mbit/s und RTT?

Multiplizieren Sie die Rate in Megabit pro Sekunde mit der Umlaufzeit in Millisekunden und mit 125, dann erhalten Sie Bytes. Bei 100 Mbit/s und 50 ms müssen 625.000 Bytes unterwegs sein, um die Leitung auszulasten.

Wann brauche ich TCP-Fensterskalierung?

Sobald das Ergebnis über 65.535 Bytes liegt, dem Höchstwert eines TCP-Fensters ohne Skalierung. Für 625.000 Bytes ist der kleinste Window-Scale-Faktor 4, der die Obergrenze auf 1.048.560 Bytes hebt.

Wie schnell ist eine Übertragung ohne Fensterskalierung?

Höchstens 65.535 Bytes pro Umlauf. Auf einer Strecke mit 50 ms begrenzt das die Übertragung auf 10,4856 Mbit/s, egal wie schnell die Leitung ist; deshalb kriechen Fernkopien ohne Skalierung.

Für Entwickler — API-Zugang

Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.

Endpunkt

POSThttps://api.kit.forhosting.com/dev/tcp-window-for-throughput

Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.

Aufruf aus Ihrem Stack

curl -X POST https://api.kit.forhosting.com/dev/tcp-window-for-throughput \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"throughput_mbps":100,"rtt_ms":50}'

const res = await fetch("https://api.kit.forhosting.com/dev/tcp-window-for-throughput", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "throughput_mbps": 100,
    "rtt_ms": 50
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/dev/tcp-window-for-throughput",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "throughput_mbps": 100,
    "rtt_ms": 50
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/tcp-window-for-throughput", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"throughput_mbps":100,"rtt_ms":50}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"throughput_mbps":100,"rtt_ms":50}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/tcp-window-for-throughput", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Beispiel-Anfrage

{
  "throughput_mbps": 100,
  "rtt_ms": 50
}

Beispiel-Antwort

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev.tcp_window_for_throughput",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.

Preis

pro Anfrage$0.002

Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.

Fehler

HTTP	Code	Bedeutung
`401`	`unauthorized`	Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer).
`402`	`insufficient_balance`	Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht.
`404`	`unknown_type`	Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog.
`429`	`rate_limited`	Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt.

Technische Hinweise

Nicht-positive Eingaben scheitern mit invalid_input und werden nicht abgerechnet.

Eingabevertrag, Window Scale und Antwortfelder

Kombinieren Sie das Ergebnis mit dem sysctl oder der Socket-Option Ihres Stacks für Empfangspuffer und Window Scale; dieser Rechner schreibt keine Konfiguration auf Hosts. Senden Sie per POST einen JSON-Body mit zwei erforderlichen positiven endlichen Zahlen: throughput_mbps, dem Ziel-Goodput oder der Verbindungsrate in Megabit pro Sekunde, und rtt_ms, der Ende-zu-Ende-Round-Trip-Zeit in Millisekunden. Jedes Feld darf als JSON-Zahl oder als numerische Zeichenkette ankommen. Fehlende Felder, nicht-endliche Werte, Null und negative Werte scheitern mit invalid_input und einer Meldung, die das Feld nennt; diese Fehler werden nicht abgerechnet. Bei Erfolg spiegelt der Body die Eingaben, liefert window_bytes, window_bits, window_kib und window_mib für das BDP, classic_max_window_bytes gleich 65535, window_scale_needed true, wenn das BDP diese klassische Grenze überschreitet, window_scale_shift als den kleinsten RFC-1323-Shift, der das Sechzehn-Bit-Fenster genügend multipliziert, um das BDP abzudecken (Obergrenze vierzehn), scaled_max_window_bytes als 65535 mal zwei hoch diesem Shift, max_throughput_mbps_without_scale für dasselbe RTT ohne Skalierung, und eine kurze Formelzeichenkette. Beispiel: throughput_mbps einhundert und rtt_ms fünfzig ergeben sechshundertfünfundzwanzigtausend window_bytes und window_scale_needed true.

Wo ein TCP-Fenster-Durchsatz-Rechner seinen Nutzen hat

Weil die Implementierung pure parse Stufe A ist, kostet jeder erfolgreiche Aufruf den veröffentlichten Basispreis $0.002 ohne Modell-Tokens und ohne ausgehendes Netz.

Integrationsbeispiele

Lehre des Bandbreite-Verzögerungs-Produkts

Geben Sie Studierenden ein deterministisches BDP-Orakel, das window_bytes liefert und erklärt, wann Window Scale RFC 1323 Pflicht ist.

Technische Fragen

Wie berechne ich die TCP-Fenstergröße für einen Zieldurchsatz?

Senden Sie positive throughput_mbps und rtt_ms. Die API liefert window_bytes = throughput_mbps × rtt_ms × 125 (das Bandbreite-Verzögerungs-Produkt in Bytes), plus Bits, KiB und MiB.

Wann ist Window Scale erforderlich?

Wenn window_bytes 65535 überschreitet, das klassische unskalierte TCP-Fenster. Die Antwort setzt window_scale_needed auf true und gibt den minimalen window_scale_shift (RFC 1323).

Was kostet der TCP-Fenster-Durchsatz-Rechner?

Das Browser-Tool ist kostenlos. API-Anfragen nutzen vorausbezahltes KIT-Guthaben zu $0.002 pro erfolgreichem Aufruf; ungültige Eingabe wird nicht abgerechnet.

Vollständige KIT-Dokumentation lesen →

TCP-Fenstergröße für Durchsatz

Im Browser ausführen – kostenlos

Rechenbeispiel

Warum die Fenstergröße Bandbreite mal Verzögerung ist

Wo ein TCP-Fenster-Durchsatz-Rechner seinen Nutzen hat

Anwendungsfälle

WAN- und LFN-Kapazitätsplanung

Dimensionierung regionsübergreifender Cloud-Transfers

Häufige Fragen

Verwandte Tools

Für Entwickler — API-Zugang

Endpunkt

Aufruf aus Ihrem Stack

Beispiel-Anfrage

Beispiel-Antwort

Preis

Fehler

Technische Hinweise

Eingabevertrag, Window Scale und Antwortfelder

Wo ein TCP-Fenster-Durchsatz-Rechner seinen Nutzen hat

Integrationsbeispiele

Lehre des Bandbreite-Verzögerungs-Produkts

Technische Fragen

danke