Calcul débit TCP, RTT et fenêtre
Estimez le débit TCP théorique à partir de la taille de fenêtre, du RTT et d’un facteur d’efficacité. Cet outil permet aussi de vérifier l’impact d’une capacité de lien et du produit bande passante-délai sur les performances observées.
Calculateur interactif
Formule de base : débit théorique = fenêtre TCP / RTT. Le résultat est converti en bits/s puis ajusté par un coefficient d’efficacité. Si une capacité de lien est renseignée, l’outil affiche aussi le débit effectif plafonné.
Résultats
Renseignez les paramètres puis cliquez sur « Calculer » pour voir le débit TCP estimé, le BDP et les comparaisons de scénario.
Guide expert du calcul débit TCP, RTT et fenêtre
Le calcul du débit TCP à partir du RTT et de la taille de fenêtre est l’un des fondamentaux les plus utiles pour comprendre les performances réseau. Lorsqu’un utilisateur observe un téléchargement plus lent que la capacité nominale de sa liaison, il ne s’agit pas toujours d’un problème de bande passante brute. Très souvent, la cause réelle se trouve dans l’interaction entre la latence, la fenêtre TCP disponible, le comportement de congestion et les limitations applicatives. En pratique, un lien 1 Gb/s peut se comporter comme un lien bien plus lent si la pile TCP ne maintient pas suffisamment de données en vol pour remplir le tuyau réseau.
Le principe général est simple. TCP autorise l’émetteur à envoyer une certaine quantité de données avant de devoir attendre des accusés de réception. Cette quantité est représentée par la fenêtre. Le RTT, ou Round Trip Time, mesure le temps aller-retour entre l’envoi d’un segment et la réception de l’ACK correspondant. Si la fenêtre est petite et le RTT élevé, l’émetteur reste fréquemment en attente, ce qui limite fortement le débit soutenu. À l’inverse, une fenêtre suffisamment grande par rapport au RTT permet de maintenir un volume de données en transit compatible avec la capacité du lien.
La formule pédagogique de base est la suivante : débit théorique ≈ fenêtre TCP / RTT. Pour obtenir un débit en bits par seconde, on multiplie la fenêtre exprimée en octets par 8, puis on divise par le RTT exprimé en secondes. Cette approximation est extrêmement utile pour estimer un plafond de performance. Elle ne remplace pas une analyse protocolaire complète, mais elle donne une excellente intuition sur la relation entre latence et débit. C’est précisément ce que fait le calculateur ci-dessus en ajoutant un facteur d’efficacité et un éventuel plafonnement par la capacité du lien.
Pourquoi le RTT influence autant les performances TCP
Le RTT représente le temps nécessaire pour qu’une unité d’information fasse l’aller-retour entre deux hôtes. Plus il est élevé, plus TCP met de temps à recevoir la confirmation qu’il peut continuer à avancer son flux. Cela signifie qu’une même fenêtre est consommée plus lentement. Prenons un exemple direct. Si la fenêtre est de 256 Ko et que le RTT vaut 10 ms, le débit théorique est bien supérieur au cas où le RTT est de 100 ms. La raison n’est pas mystérieuse : dans le second scénario, la même quantité de données reste bloquée plus longtemps “en vol” avant d’être acquittée.
En réseau local, les RTT sont généralement très faibles, souvent inférieurs à quelques millisecondes. Sur des accès nationaux ou inter-régionaux, on voit fréquemment des RTT de l’ordre de 10 à 40 ms. Sur des liaisons intercontinentales, les valeurs peuvent monter à 80, 120, 180 ms ou davantage. Cette simple variation a un impact massif sur la fenêtre requise pour saturer un lien rapide. Si l’on vise 1 Gb/s sur 100 ms de RTT, il faut maintenir énormément plus de données en vol que pour atteindre ce même débit sur 5 ms.
| Scénario | RTT typique observé | Interprétation opérationnelle | Impact sur la fenêtre nécessaire |
|---|---|---|---|
| LAN d’entreprise | 1 à 3 ms | Latence très faible, excellent environnement pour TCP classique | Faible fenêtre suffisante pour des débits élevés |
| Réseau national | 10 à 30 ms | Cas fréquent pour data centers proches ou backbone national | Fenêtre moyenne à élevée selon la capacité |
| Inter-régional / international proche | 30 à 80 ms | Début d’effet sensible sur les transferts volumineux | Fenêtre plus large requise pour exploiter les liens rapides |
| Transcontinental | 80 à 180 ms | Latence importante, tuning TCP indispensable sur gros débits | Très grande fenêtre nécessaire pour éviter la sous-utilisation |
La fenêtre TCP : définition, rôle et limites
La fenêtre TCP peut être vue comme le volume maximal de données non acquittées qu’un émetteur est autorisé à conserver en circulation. Historiquement, la taille de fenêtre sans option de scaling était limitée à 65 535 octets. Cette valeur suffit pour des réseaux à faible RTT et à débit modéré, mais elle devient rapidement insuffisante lorsque l’on augmente la bande passante ou la distance. L’option TCP Window Scale a précisément été introduite pour dépasser cette limite et permettre des fenêtres beaucoup plus grandes.
Une erreur fréquente consiste à raisonner uniquement en mégabits par seconde. En réalité, pour les protocoles fiables comme TCP, il faut aussi raisonner en “volume de données en transit”. Si le lien peut transporter beaucoup de bits, mais que l’émetteur n’a pas l’autorisation de garder assez de données en vol pendant un RTT complet, le pipeline reste partiellement vide. La bande passante théorique existe, mais TCP n’a pas de quoi l’exploiter pleinement.
C’est là qu’intervient la notion de produit bande passante-délai, ou BDP. Le BDP mesure la quantité de données qui doivent être simultanément en circulation pour saturer un lien. Formellement, BDP = bande passante × RTT. Si le BDP d’un lien est de 12,5 Mo, alors une fenêtre bien en dessous de cette valeur empêchera d’atteindre le débit maximal. Le calculateur met en évidence cette relation afin d’aider à dimensionner la fenêtre de réception ou à vérifier la cohérence d’une mesure terrain.
Tableau de référence : BDP réel pour plusieurs capacités et RTT
Les chiffres suivants sont des calculs physiques réels dérivés de la formule du produit bande passante-délai. Ils servent de repère pour comprendre les ordres de grandeur qu’impliquent les réseaux modernes.
| Capacité du lien | RTT | BDP en bits | BDP approximatif en octets | Conséquence pratique |
|---|---|---|---|---|
| 100 Mb/s | 10 ms | 1 000 000 bits | 125 000 octets | Une fenêtre de 128 Ko approche la saturation théorique |
| 100 Mb/s | 100 ms | 10 000 000 bits | 1 250 000 octets | Une petite fenêtre limite fortement le débit |
| 1 Gb/s | 20 ms | 20 000 000 bits | 2 500 000 octets | Il faut plusieurs mégaoctets de fenêtre |
| 1 Gb/s | 100 ms | 100 000 000 bits | 12 500 000 octets | Le tuning TCP et l’auto-tuning deviennent cruciaux |
| 10 Gb/s | 50 ms | 500 000 000 bits | 62 500 000 octets | Des buffers et fenêtres très larges sont nécessaires |
Comment utiliser correctement un calculateur débit TCP RTT fenêtre
- Mesurez ou estimez un RTT représentatif du trajet réel entre client et serveur.
- Identifiez la fenêtre TCP effective, ou à défaut une valeur de fenêtre cible raisonnable.
- Appliquez la formule débit = fenêtre / RTT pour obtenir un plafond de base.
- Ajoutez un coefficient d’efficacité pour tenir compte des en-têtes, ACK, phases de contrôle et variations réseau.
- Comparez le résultat à la capacité du lien afin de savoir si la vraie limitation vient du réseau ou de TCP lui-même.
Cette méthodologie est très utile dans les audits de performance, la validation d’architectures WAN, la préparation d’une migration vers un backbone plus rapide et l’analyse de téléchargements jugés anormalement lents. Elle aide aussi à distinguer un problème de latence d’un problème de bande passante. Si la capacité du lien est élevée mais que le calcul théorique basé sur la fenêtre et le RTT reste bas, il y a de fortes chances que l’optimisation doive porter sur TCP ou sur l’application.
Exemple détaillé de calcul
Supposons une fenêtre TCP effective de 512 Ko et un RTT moyen de 80 ms. Convertissons d’abord les unités. 512 Ko correspondent à 524 288 octets. Le RTT de 80 ms correspond à 0,08 seconde. Le débit théorique devient donc 524 288 × 8 / 0,08 = 52 428 800 bit/s, soit environ 52,43 Mb/s. Si vous appliquez une efficacité de 92 %, le débit utile estimé descend à environ 48,23 Mb/s. Si le lien physique est à 1 Gb/s, la limitation vient clairement de la combinaison fenêtre + RTT et non de la capacité brute de la ligne.
Maintenant, gardons la même fenêtre mais réduisons le RTT à 20 ms. On obtient 524 288 × 8 / 0,02 = 209 715 200 bit/s, soit environ 209,72 Mb/s avant efficacité. La différence est spectaculaire. Cela montre pourquoi les applications sensibles aux délais se comportent mieux à proximité de l’utilisateur, pourquoi les CDN sont efficaces, et pourquoi les grandes distances pénalisent les gros transferts si la fenêtre n’est pas adaptée.
Facteurs qui font diverger le débit réel du débit théorique
- La perte de paquets, même faible, peut déclencher des mécanismes de réduction de congestion.
- Le jitter modifie le RTT instantané et perturbe la régularité de la transmission.
- Les fenêtres annoncées peuvent être inférieures à celles attendues en raison de limites système ou applicatives.
- Les proxies, middleboxes et pare-feu peuvent altérer les flux ou les temporisations.
- Le protocole applicatif peut sérialiser les échanges et empêcher l’utilisation optimale du pipeline TCP.
- Les serveurs de destination peuvent être CPU-bound, storage-bound ou volontairement rate-limited.
Ordres de grandeur utiles et données publiques
Les organismes publics qui publient des mesures de performance Internet montrent régulièrement que la latence médiane sur le haut débit fixe reste très inférieure à celle de certains réseaux à longue distance ou encombrés, et que la vitesse nominale annoncée n’est pas toujours le bon indicateur d’expérience. Pour approfondir, vous pouvez consulter le programme Measuring Broadband America de la FCC, qui publie des jeux de données et des analyses sur le débit, la latence et la qualité d’accès. Pour une approche académique solide des mécanismes de transport, les supports de cours réseaux de nombreuses universités américaines constituent une référence, par exemple des ressources de Carnegie Mellon University ou des cours disponibles sur des domaines universitaires comme Princeton University.
Dans l’ingénierie réseau, ces données publiques sont précieuses car elles permettent de confronter les calculs théoriques à des observations terrain. Vous pouvez, par exemple, utiliser votre RTT mesuré, calculer le BDP d’une liaison, puis comparer cette exigence à la fenêtre réellement configurée ou observée dans une capture réseau. Cette confrontation permet d’expliquer des écarts de performance sans tomber dans l’approximation.
Bonnes pratiques pour améliorer le débit TCP sur des RTT élevés
- Activer et vérifier le TCP window scaling sur les hôtes concernés.
- Contrôler l’auto-tuning des buffers TCP côté émission et réception.
- Réduire la distance logique grâce à un CDN, un cache, un point de présence local ou un hébergement plus proche.
- Limiter la perte de paquets et la congestion grâce à une bonne qualité de service et à des buffers adaptés.
- Utiliser des flux parallèles ou des protocoles applicatifs modernes lorsque cela est pertinent.
- Surveiller les métriques applicatives et non seulement les métriques L3 ou L4.
En résumé
Le calcul débit TCP RTT et fenêtre constitue un outil de diagnostic simple, rapide et redoutablement efficace. Si vous retenez une seule idée, c’est la suivante : le débit soutenu n’est pas uniquement une question de mégabits disponibles, mais aussi de quantité de données que TCP peut conserver en vol pendant un RTT complet. Plus le RTT monte, plus il faut une fenêtre importante pour maintenir le même débit. Le calculateur ci-dessus vous aide à visualiser cette relation, à estimer un plafond réaliste et à déterminer si votre limitation provient de la latence, de la fenêtre, de la capacité du lien ou d’un mélange des trois.