Le débit théorique d’une connexion réseau ne correspond que très rarement à la vitesse réelle observée lors d’un transfert de données. Pour évaluer précisément les performances d’un flux TCP unique, il est nécessaire de prendre en compte des facteurs physiques et protocolaires tels que la latence, la taille de la fenêtre de réception, la taille maximale de segment (MSS) et la perte de paquets. Le calculateur de débit et latence réseau permet de modéliser ces paramètres pour identifier instantanément le goulot d’étranglement d’un chemin réseau.
Comprendre les plafonds de débit TCP
Le débit d’un flux TCP unique est dicté par la règle du facteur le plus limitant. Trois plafonds indépendants s’appliquent en permanence sur un chemin réseau: la capacité physique du lien (corrigée de la surcharge protocolaire), la taille de la fenêtre de réception TCP et le taux de perte de paquets. Le débit réel s’aligne systématiquement sur la valeur la plus basse de ces trois limites.
La formule générale utilisée pour déterminer les performances du flux est la suivante:
débit = min(débit × eff, fenêtre ÷ RTT, MSS ÷ RTT ÷ √p) · BDP = débit × RTT
Pour utiliser le calculateur, vous devez renseigner plusieurs paramètres clés:
- Débit du lien: Le saut le plus lent sur le chemin — souvent le débit nominal de votre abonnement. Cette valeur doit être supérieure à zéro.
- Temps de trajet aller-retour (RTT): Le temps de ping vers l’extrémité distante — utilisez la valeur la plus élevée attendue sous charge. Cette valeur doit être supérieure à zéro.
- Taille des données: La charge utile à déplacer — un fichier, une sauvegarde, un ensemble de données. Cette valeur doit être supérieure à zéro.
- Fenêtre de réception: Les octets que le récepteur peut mettre en mémoire tampon. Cette valeur doit être supérieure à zéro et ne peut pas dépasser 1 073 725 440 octets. Si ce champ reste vide, aucune limite de fenêtre n'est appliquée.
- MSS (octets): Les octets de charge utile par paquet. Ce paramètre doit être un nombre entier d’octets compris entre 1 et 65 495. Si ce champ reste vide, la surcharge et les pertes sont ignorées.
- Perte de paquets (%): La probabilité moyenne de perte de paquets. Elle doit être comprise entre 0 et 100 pour cent. Un champ vide ou égal à 0 indique l'absence de limite liée aux pertes.
- Décimales affichées: Contrôle la précision décimale des résultats.
L'interface propose également un bouton Charger un exemple pour pré-remplir les champs avec des données types, ainsi qu'un bouton Effacer pour réinitialiser la saisie.
Le produit débit-retard (BDP) et la fenêtre de réception
Le produit débit-retard, ou BDP (Bandwidth-Delay Product), définit la quantité de données qui doit être présente simultanément sur le câble pour saturer pleinement la liaison. Il se calcule ainsi:
BDP = débit × RTT = ‹rate› × ‹rtt› = ‹bdp› = ‹bytes›
Si la fenêtre de réception TCP est inférieure au BDP, l'émetteur doit s'arrêter et attendre les accusés de réception (ACK) avant d'envoyer d'autres données, ce qui laisse le canal partiellement vide. La fenêtre nécessaire pour remplir le chemin est calculée par la formule:
Fenêtre pour remplir le chemin = BDP ÷ 8 = ‹bdp› → ‹window›
Le plafond de débit imposé par la fenêtre de réception se calcule de la manière suivante:
Plafond de la fenêtre = fenêtre ÷ RTT = ‹window› ÷ ‹rtt› = ‹value›
Limites de mise à l'échelle de la fenêtre (RFC 7323)
Le protocole TCP classique limite la taille de la fenêtre de réception à 65 535 octets. Sur les réseaux modernes à haut débit et forte latence (LFN ou Long-Fat Networks), cette limite s'avère insuffisante.
- Si la fenêtre requise pour saturer le lien dépasse 65 535 octets, le calculateur affiche la note suivante: « Remplir ce chemin nécessite une fenêtre de
‹window›— au-dessus du maximum non mis à l’échelle de 65,535 octets, les deux extrémités doivent donc négocier la mise à l’échelle de fenêtre TCP (RFC 7323). » - La limite absolue de la fenêtre de réception avec l'option de mise à l'échelle de la RFC 7323 est de 1 073 725 440 octets. Si le BDP impose une fenêtre supérieure à cette limite, le système affiche la note: « Remplir ce chemin nécessite
‹window›— au-delà de la plus grande fenêtre que TCP peut négocier (1,073,725,440 octets). Un flux unique sur ce chemin ne pourra jamais dépasser‹value›. » - Si la fenêtre saisie bride le débit, le calculateur affiche un message d'optimisation: « Augmenter la fenêtre de réception à
‹window›permettrait à ce transfert d’atteindre jusqu’à‹value›. »
L'impact de la perte de paquets et le modèle de Mathis
La perte de paquets dégrade fortement les performances TCP, car le protocole interprète chaque perte comme un signal de congestion et réduit sa fenêtre d'émission. Le calculateur utilise le modèle de Mathis pour estimer le débit maximal en présence de pertes:
Plafond lié aux pertes (Mathis) = MSS ÷ RTT ÷ √p = ‹mss› ÷ ‹rtt› ÷ √‹p› = ‹value›
Le modèle de Mathis repose sur l'hypothèse de pertes de paquets distribuées de manière uniforme et indépendante. Ce modèle est fiable pour des taux de perte inférieurs à environ 1 %. Si le taux de perte saisi dépasse ce seuil, le calculateur affiche l'avertissement suivant: « Une perte supérieure à 1% dépasse la plage de fiabilité du modèle de Mathis — considérez le plafond de perte comme optimiste. »
Surcharge protocolaire et efficacité du lien
Une partie de la bande passante physique est consommée par les en-têtes des protocoles de transport et de liaison. Le calculateur modélise cette surcharge sur la base d'une trame Ethernet standard, en ajoutant 78 octets de surcharge par paquet (40 octets pour les en-têtes TCP/IP et 38 octets de surcharge physique sur le câble).
L'efficacité du protocole est calculée comme suit:
Efficacité du protocole = MSS ÷ (MSS + 78 B) = ‹mss› ÷ ‹frame› = ‹eff› (40 B d’en-têtes de paquet + 38 B sur le câble)
Le débit utile maximal disponible pour les données applicatives (le plafond du lien après surcharge) est alors déterminé par:
Plafond du lien = débit × efficacité = ‹rate› × ‹eff› = ‹value›
Interprétation des résultats et calcul du temps de transfert
Une fois les calculs effectués, l'outil affiche le Débit TCP attendu accompagné de la mention indiquant la contrainte active: « limité par ‹constraint› », où la contrainte correspond à la capacité du lien, la fenêtre de réception ou la perte de paquets.
Le temps total nécessaire pour acheminer les données comprend le temps d'établissement ou de latence initiale (1 RTT) et le temps de transfert de la charge utile:
Temps de transfert = RTT + 8 × taille ÷ débit = ‹rtt› + 8 × ‹size› ÷ ‹throughput› = ‹time›
Les résultats détaillés affichent également:
- Temps de transfert
- Temps jusqu’au premier octet (1 RTT)
- Temps de transfert brut
- Produit débit-retard
- Fenêtre pour remplir le chemin
- Débit limité par la fenêtre
- Débit limité par les pertes (Mathis)
- Plafond du lien après surcharge
- Efficacité du protocole
Un bouton Copier le résultat permet de copier l'ensemble de ces données calculées.
Limites du modèle théorique
Les calculs s'appliquent à un flux TCP unique en régime permanent. Les phénomènes transitoires ou spécifiques tels que le démarrage lent (slow start), les algorithmes de contrôle de congestion, les limitations de traitement du récepteur ou les négociations de sécurité (poignées de main TLS) ne sont pas modélisés. Les transferts réels démarreront donc plus lentement et pourront afficher des performances inférieures aux plafonds calculés.
Confidentialité des données
Chaque valeur que vous saisissez est calculée dans ce navigateur — rien n’est envoyé nulle part. Le traitement s'effectue localement sur votre terminal pour garantir la confidentialité de vos paramètres réseau.
FAQ
Pourquoi mon transfert est-il plus lent que le débit de connexion pour lequel je paie?
Un flux TCP unique fait face à trois plafonds indépendants, et le plus bas l’emporte. La surcharge protocolaire réduit le lien lui-même d’environ 5% — une trame Ethernet standard transporte 1,460 octets de charge utile sur 1,538 sur le câble. La fenêtre de réception limite le débit à fenêtre ÷ RTT, de sorte que la fenêtre classique de 65,535 octets limite un chemin de 50 ms à environ 10.5 Mbit/s, quelle que soit la vitesse du lien. Et la perte le limite à (MSS ÷ RTT) ÷ √perte. Le résultat ci-dessus indique quel plafond s’applique à vos chiffres.
Qu’est-ce que le produit débit-retard et pourquoi définit-il la taille de la fenêtre?
Le BDP — débit du lien × temps de trajet aller-retour — représente la quantité de données en transit à tout moment. TCP ne peut avoir au maximum qu’une seule fenêtre non acquittée en attente, de sorte qu’une fenêtre plus petite que le BDP laisse le canal partiellement vide: à 100 Mbit/s avec un RTT de 50 ms, le canal contient 625 kB, et une fenêtre de 65,535 octets en remplit à peine un dixième. C’est pourquoi les chemins rapides et longs ont besoin de la mise à l’échelle de fenêtre TCP (RFC 7323), qui élève le maximum négociable de 65,535 octets à environ 1 GB.
Comment la perte de paquets limite-t-elle le débit TCP?
TCP traite la perte comme une congestion et divise par deux son débit d’envoi à chaque événement de perte, de sorte que même de minuscules taux de perte comptent sur les chemins rapides. Le modèle de Mathis estime le plafond à (MSS ÷ RTT) ÷ √p — à 0.01% de perte sur un chemin de 50 ms avec un MSS de 1,460 octets, cela représente environ 23 Mbit/s, quelle que soit la vitesse du lien. Le modèle suppose des événements de perte uniformément répartis et indépendants; en dessous d’environ 1% il suit bien la reality, et pour les pertes en rafales, il se montre optimiste.
Les mégaoctets ici sont-ils les mêmes que dans mon gestionnaire de fichiers?
Pas tout à fait. Cette page utilise des unités décimales, la convention des réseaux: 1 kbit = 1,000 bits et 1 MB = 1,000,000 d’octets. La plupart des gestionnaires de fichiers comptent en unités basées sur 1024, souvent étiquetées à tort MB — un fichier de « 100 MB » y fait généralement 100 MiB ≈ 104.86 MB décimaux, de sorte qu’il prend environ 5% de temps en plus à transférer que ce que suggère le chiffre décimal. Entrez 104.86 MB ici pour correspondre exactement.