ForHosting KIT · Outils pour développeurs

Calculateur fenêtre TCP pour débit

100 Mbit/s sur un aller-retour de 50 ms exigent 625 000 octets en transit, bien au-delà de la fenêtre TCP classique de 65 535 octets : indiquez débit et RTT pour obtenir la fenêtre et le facteur d'échelle qui remplissent le lien. Gratuit dans votre navigateur.

Gratuit
Fonctionne dans votre navigateur
Sans inscription
Vos données restent sur votre appareil

Lancer gratuitement Voir l’API

Utilisez-le depuis WebAPIE-mailTelegramApp bientôt

Exemple résolu

Si vous saisissez

Débit (Mbps): 100
Rtt ms: 50

Vous obtenez

Fenêtre (octets): 625 000
Fenêtre (bits): 5 000 000
Fenêtre (Kio): 610,3515625
Fenêtre (Mio): 0,5960464478

Les réseaux longs et à fort débit —bande passante élevée multipliée par une latence élevée— affament TCP si la fenêtre de réception n’est pas assez grande pour garder le tuyau plein pendant un aller-retour complet. Ingénieurs réseau, SRE et étudiants qui dimensionnent des liaisons WAN, des chemins satellitaires ou des tunnels cloud inter-régions ont besoin du produit bande passante-délai, pas d’une règle empirique. Ce calculateur de taille de fenêtre TCP pour le débit accepte le débit cible en mégabits par seconde et le RTT du chemin en millisecondes, les multiplie par le facteur exact qui donne des octets, et renvoie la fenêtre requise en octets, bits, kibioctets et mébioctets. Il signale aussi quand la fenêtre TCP classique de 65535 octets sans mise à l’échelle est trop petite, recommande le décalage Window Scale minimal selon la RFC 1323, et montre le débit maximal encore atteignable sans mise à l’échelle au même RTT.

Pourquoi la taille de fenêtre égale bande passante fois délai

TCP ne peut avoir de données non acquittées en attente qu’à hauteur de la fenêtre annoncée par le récepteur (et de la fenêtre de congestion de l’émetteur). Sur un chemin de capacité C bits par seconde et de temps d’aller-retour R secondes, la quantité de données qui doit être en vol pour utiliser pleinement la liaison est C fois R — le produit bande passante-délai.

Divisez par huit pour exprimer ce produit en octets ; ce nombre est la fenêtre de réception minimale pour un transfert à plein débit en régime permanent si le contrôle de congestion n’est pas le facteur limitant. En unités d’ingénierie pratiques, mégabits par seconde fois millisecondes fois cent vingt-cinq donnent des octets, car un mégabit par seconde vaut cent vingt-cinq mille octets par seconde et une milliseconde est un millième de seconde. Exemple : cent mégabits par seconde à cinquante millisecondes exigent six cent vingt-cinq mille octets en vol.

Sans cette profondeur de tampon, l’émetteur vide sa fenêtre, s’arrête et attend des acquittements, si bien que le goodput mesuré tombe bien en dessous du débit de ligne même si le lien physique est sain. Ce point de terminaison ne dimensionne la fenêtre qu’à partir du BDP ; il ne modélise ni perte de paquets, ni slow start, ni bufferbloat, qui sont d’autres leviers de planification de capacité.

Où un calculateur de fenêtre TCP et de débit s’avère utile

Les concepteurs de WAN et de centres de données utilisent un calculateur de taille de fenêtre TCP avant d’élargir des circuits afin que tampons de réception et valeurs par défaut du SE correspondent au nouveau BDP au lieu de deviner. Les architectes cloud qui dimensionnent la réplication de bases inter-régions ou les transferts de stockage d’objets convertissent le RTT publié et les mégabits cibles en octets de tampon concrets pour les plans de test de charge.

Les équipes de backhaul satellite et mobile montrent pourquoi des liaisons multi-mégabits rampent encore quand le RTT vaut des centaines de millisecondes et que Window Scale est désactivé. Salles de classe et laboratoires de certification ont besoin d’un oracle déterministe pour les devoirs sur le produit bande passante-délai qui respecte les unités du manuel sans erreurs de tableur. Une validation échouée ne consomme pas de solde.

Laissez perte, pacing et contrôle de congestion dans vos propres outils ; utilisez ce point de terminaison comme source unique de vérité pour l’arithmétique du BDP afin que documentation, runbooks et workers de bord planifient de la même façon.

Cas d’usage

Planification de capacité WAN et LFN

Convertissez Mbps cibles et RTT mesuré en fenêtre de réception (et décalage d’échelle) nécessaire pour remplir un chemin de réseau long et à fort débit.

Dimensionnement des transferts cloud inter-régions

Dimensionnez les tampons de socket pour réplication de base, sauvegarde ou objets afin que le débit ne soit pas plafonné par une fenêtre non mise à l’échelle de 64 KiB.

Questions fréquentes

Qu’est-ce que le produit bande passante-délai (BDP) ?

Le BDP est le débit de la liaison multiplié par le RTT : les données qui doivent être en vol pour garder le chemin plein. La fenêtre annoncée de TCP doit faire au moins autant d’octets (hors limites de congestion).

Ce modèle inclut-il la perte de paquets ou le contrôle de congestion ?

Non. Il ne dimensionne la fenêtre qu’à partir du BDP pour que le tuyau puisse se remplir. Perte, variance de RTT et fenêtres de congestion sont séparées ; utilisez d’autres outils pour cela.

Comment calculer la taille de la fenêtre TCP à partir du débit et du RTT ?

Multipliez le débit en mégabits par seconde par le temps aller-retour en millisecondes, puis par 125, pour obtenir des octets. À 100 Mbit/s et 50 ms, il faut 625 000 octets en transit pour remplir le lien.

Quand faut-il activer la mise à l'échelle de la fenêtre TCP ?

Dès que le résultat dépasse 65 535 octets, le maximum qu'une fenêtre TCP peut annoncer sans mise à l'échelle. Pour 625 000 octets, le plus petit décalage Window Scale est 4, ce qui porte le plafond à 1 048 560 octets.

Quel débit atteint un transfert sans mise à l'échelle de la fenêtre ?

Au plus 65 535 octets par aller-retour. Sur un trajet de 50 ms, le transfert plafonne ainsi à 10,4856 Mbit/s, quelle que soit la vitesse du lien physique : d'où la lenteur des copies longue distance sans mise à l'échelle.

Outils associés

Pour les développeurs — accès API

Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.

Endpoint

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

Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.

Appeler depuis votre 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)

Exemple de requête

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

Exemple de réponse

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

L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.

Tarifs

par requête$0.002

Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.

Erreurs

HTTP	Code	Signification
`401`	`unauthorized`	Clé API absente ou invalide : vérifiez l’en-tête Authorization.
`402`	`insufficient_balance`	Solde insuffisant : rechargez votre compte pour lancer cette tâche.
`404`	`unknown_type`	Type de tâche inconnu : vérifiez le champ type de votre requête.
`429`	`rate_limited`	Trop de requêtes : ralentissez la cadence, puis réessayez.

Notes techniques

Les entrées non positives échouent avec invalid_input et ne sont pas facturées.

Contrat d’entrée, Window Scale et champs de réponse

Associez le résultat au sysctl ou à l’option de socket de votre pile pour le tampon de réception et Window Scale ; ce calculateur n’applique aucune configuration aux hôtes. Envoyez un corps JSON en POST avec deux nombres finis positifs obligatoires : throughput_mbps, le goodput ou débit de liaison cible en mégabits par seconde, et rtt_ms, le temps d’aller-retour de bout en bout en millisecondes. Chaque champ peut arriver comme nombre JSON ou comme chaîne numérique. Champs manquants, valeurs non finies, zéro et négatifs échouent avec invalid_input et un message qui nomme le champ ; ces échecs ne sont pas facturés. En cas de succès le corps renvoie les entrées, window_bytes, window_bits, window_kib et window_mib pour le BDP, classic_max_window_bytes égal à 65535, window_scale_needed à true lorsque le BDP dépasse cette limite classique, window_scale_shift comme le plus petit décalage RFC 1323 qui multiplie la fenêtre de seize bits assez pour couvrir le BDP (plafond quatorze), scaled_max_window_bytes comme 65535 fois deux élevé à ce décalage, max_throughput_mbps_without_scale pour le même RTT si vous restez sans mise à l’échelle, et une courte chaîne de formule. Exemple : throughput_mbps cent et rtt_ms cinquante donnent six cent vingt-cinq mille window_bytes et window_scale_needed true.

Où un calculateur de fenêtre TCP et de débit s’avère utile

Comme l’implémentation est pure parse de niveau A, chaque appel réussi coûte le prix de base publié $0.002 sans jetons de modèle ni réseau sortant.

Cas d'intégration

Enseignement du produit bande passante-délai

Offrez aux étudiants un oracle BDP déterministe qui renvoie window_bytes et explique quand Window Scale RFC 1323 est obligatoire.

Questions techniques

Comment calculer la taille de fenêtre TCP pour un débit cible ?

Envoyez throughput_mbps et rtt_ms positifs. L’API renvoie window_bytes = throughput_mbps × rtt_ms × 125 (le produit bande passante-délai en octets), plus bits, KiB et MiB.

Quand Window Scale est-il requis ?

Lorsque window_bytes dépasse 65535, la fenêtre TCP classique sans mise à l’échelle. La réponse met window_scale_needed à true et donne le window_scale_shift minimal (RFC 1323).

Combien coûte le calculateur de fenêtre TCP et de débit ?

L’outil navigateur est gratuit. Les requêtes API utilisent le solde KIT prépayé à $0.002 par appel réussi ; une entrée invalide n’est pas facturée.

Consulter la documentation complète du KIT →

Lancer gratuitement

Exemple résolu

Pourquoi la taille de fenêtre égale bande passante fois délai

Où un calculateur de fenêtre TCP et de débit s’avère utile

Cas d’usage

Planification de capacité WAN et LFN

Dimensionnement des transferts cloud inter-régions

Questions fréquentes

Outils associés

Pour les développeurs — accès API

Endpoint

Appeler depuis votre stack

Exemple de requête

Exemple de réponse

Tarifs

Erreurs

Notes techniques

Contrat d’entrée, Window Scale et champs de réponse

Où un calculateur de fenêtre TCP et de débit s’avère utile

Cas d'intégration

Enseignement du produit bande passante-délai

Questions techniques

merci