Comprendre les limites de débit d’un flux TCP unique
Le débit réel d’une connexion réseau ne correspond presque jamais à la vitesse brute de la liaison physique. Lorsqu’un seul flux TCP transfère des données sur un chemin réseau, ses performances maximales sont dictées par l’interaction constante entre la latence, la taille des tampons de réception et la perte de paquets.
Le calcul du débit attendu repose sur la recherche du goulot d’étranglement le plus restrictif parmi trois plafonds physiques et protocolaires distincts: la capacité utile de la liaison, la limite imposée par la fenêtre de réception et la limite liée à la perte de paquets (calculée selon le modèle de Mathis). Le débit effectif final correspond systématiquement à la plus petite de ces trois valeurs.
Paramètres d’entrée du réseau et du protocole
Pour évaluer précisément le comportement d’un transfert, plusieurs variables clés doivent être configurées:
- Débit de la liaison: Représente le saut le plus lent sur le chemin, ce qui correspond généralement à la vitesse nominale de votre forfait internet. Cette valeur doit être strictement supérieure à zéro.
- Temps de propagation en boucle (RTT): Le temps de ping aller-retour vers l’extrémité distante. Il convient d’utiliser la valeur la plus élevée attendue sous charge. Ce paramètre doit être supérieur à zéro.
- Taille des données: La charge utile totale à déplacer, comme un fichier, une sauvegarde ou un ensemble de données. Cette valeur doit être supérieure à zéro.
- Fenêtre de réception: Le volume d’octets que le récepteur peut mettre en mémoire tampon. Si ce champ reste vide, le calcul considère qu’il n’y a pas de limite de fenêtre. Si elle est spécifiée, elle doit être supérieure à zéro et ne peut pas dépasser 1 073 725 440 octets.
- MSS (octets): La taille maximale de segment (Maximum Segment Size), représentant les octets de charge utile par paquet. Une valeur de 1 460 octets remplit une trame Ethernet standard. Ce paramètre doit être un nombre entier d’octets compris entre 1 et 65 495. Laisser ce champ vide désactive la prise en compte du surdébit et de la perte.
- Perte de paquets (%): La probabilité moyenne de perte de paquets sur le chemin. Elle doit être comprise entre 0 et 100 pour cent. Un champ vide ou égal à 0 indique l’absence de limite liée à la perte.
- Décimales affichées: Permet de contrôler la précision décimale des résultats générés.
L’interface utilisateur propose également un bouton Charger un exemple pour tester le calculateur avec des données types, ainsi qu’un bouton Effacer pour réinitialiser l’ensemble des champs de saisie.
Modélisation mathématique et formules de calcul
Le calcul du comportement du flux TCP s’appuie sur des relations mathématiques précises qui lient le débit, la latence et le surdébit protocolaire:
débit = min(débit liaison × eff, fenêtre ÷ RTT, MSS ÷ RTT ÷ √(p))
BDP = débit liaison × RTT
Étape 1: Efficacité du protocole et plafond de la liaison
Le surdébit est modélisé sur une trame Ethernet standard, ajoutant un total de 78 octets par paquet (40 octets pour les en-têtes TCP/IP et 38 octets de surdébit physique sur le câble).
- Formule:
Efficacité du protocole = MSS ÷ (MSS + 78 o) = ‹mss› ÷ ‹frame› = ‹eff› (en-têtes de paquet de 40 o + 38 o sur le câble) - Plafond de la liaison:
Plafond de la liaison = débit liaison × efficacité = ‹rate› × ‹eff› = ‹value›
Étape 2: Produit débit-retard (BDP) et fenêtre requise
Le produit débit-retard détermine la quantité de données qui doit se trouver simultanément « sur le câble » pour saturer la liaison.
- Formule BDP:
BDP = débit liaison × RTT = ‹rate› × ‹rtt› = ‹bdp› = ‹bytes› - Fenêtre requise:
Fenêtre pour remplir le chemin = BDP ÷ 8 = ‹bdp› → ‹window›
Étape 3: Plafond de la fenêtre de réception
Si la fenêtre de réception est trop petite pour contenir le BDP, le protocole TCP doit s’arrêter et attendre les accusés de réception, ce qui limite le débit.
- Formule:
Plafond de fenêtre = fenêtre ÷ RTT = ‹window› ÷ ‹rtt› = ‹value›
Étape 4: Plafond de perte (Modèle de Mathis)
La perte de paquets force TCP à réduire sa fenêtre d’émission pour éviter la congestion. Le modèle de Mathis estime cette limite:
- Formule:
Plafond de perte (Mathis) = MSS ÷ RTT ÷ √p = ‹mss› ÷ ‹rtt› ÷ √‹p› = ‹value›
Étape 5: Débit attendu et temps de transfert
Le débit final correspond à la valeur la plus restrictive:
- Débit attendu:
Débit attendu = le plus bas de ces plafonds = ‹value› → limité par ‹constraint›(où la contrainte est soit la capacité de la liaison, la fenêtre de réception, ou la perte de paquets). - Temps de transfert:
Temps de transfert = RTT + 8 × taille ÷ débit = ‹rtt› + 8 × ‹size› ÷ ‹throughput› = ‹time›
Règles de gestion, limites et alertes système
Le calculateur applique des règles strictes basées sur les standards de l’IETF et affiche des notifications dynamiques selon les valeurs saisies:
- Mise à l’échelle de la fenêtre (RFC 7323): La spécification TCP d’origine limite la fenêtre de réception à 65 535 octets. Si le BDP exige une fenêtre supérieure à cette limite, le système affiche la note: « Remplir ce chemin nécessite une fenêtre de
‹window›— au-dessus du maximum non mis à l’échelle de 65,535 octets, de sorte que les deux extrémités doivent négocier la mise à l’échelle de fenêtre TCP (RFC 7323). ». - Limite absolue RFC 7323: La taille maximale absolue qu’une fenêtre TCP peut négocier via l’option de mise à l’échelle est de 1 073 725 440 octets. Si la fenêtre requise dépasse ce seuil, 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›. ». - Optimisation de la fenêtre: Si la fenêtre saisie bride le débit, le système indique: « Augmenter la fenêtre de réception à
‹window›permettrait à ce transfert d’atteindre jusqu’à‹value›. ». - Limites du modèle de Mathis: Ce modèle mathématique suppose des pertes de paquets indépendantes et uniformément réparties. Il perd sa fiabilité lorsque le taux de perte dépasse environ 1 %. Au-delà de ce seuil, le système affiche l’avertissement: « Une perte supérieure à 1% se situe en dehors de la plage de fiabilité du modèle de Mathis — considérez le plafond de perte comme optimiste. ».
- Exclusions du modèle: Les calculs décrivent un régime permanent pour un seul flux TCP. Les phénomènes transitoires comme le démarrage lent (slow start), les algorithmes de contrôle de congestion, les ralentissements 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 afficheront des performances globales inférieures aux plafonds théoriques calculés.
Confidentialité et traitement des données
La confidentialité de vos analyses réseau est préservée par l’architecture même de l’outil. Chaque valeur que vous entrez est calculée dans ce navigateur — rien n’est envoyé nulle part. Le traitement s’effectue intégralement en local sur votre machine.
FAQ
Qu’est-ce que le produit débit-retard, et pourquoi définit-il la taille de la fenêtre? Le BDP — débit de la liaison × temps de propagation en boucle — correspond à la quantité de données en transit à tout moment. TCP ne peut avoir au plus 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 ko, 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 fait passer le maximum négociable de 65,535 octets à environ 1 Go.
Pourquoi mon transfert est-il plus lent que le débit de liaison pour lequel je paie? Un flux TCP unique fait face à trois plafonds indépendants, et le plus bas l’emporte. Le surdébit du protocole réduit la liaison elle-même d’environ 5% — une trame Ethernet standard transporte 1,460 octets de charge utile sur 1,538 octets 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 de la liaison. Et la perte le limite à (MSS ÷ RTT) ÷ √perte. Le résultat ci-dessus indique quel plafond s’applique à vos chiffres.
Comment la perte de paquets limite-t-elle le débit TCP? TCP traite la perte comme une congestion et réduit de moitié 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 de la liaison. 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 réalité, et pour les pertes par 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 Mo = 1,000,000 d’octets. La plupart des gestionnaires de fichiers comptent en unités basées sur 1024, souvent étiquetées à tort Mo — un fichier de « 100 Mo » y est généralement de 100 MiB ≈ 104.86 Mo 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 Mo ici pour correspondre exactement.