Calculateur de débit TCP et de temps de transfert
Votre lien affiche 1 Gbit/s, mais la copie vers le site distant plafonne à quelques dizaines de Mbit/s ? La latence, la fenêtre TCP et les pertes fixent un plafond qu'aucun abonnement ne lève. Ce calculateur le chiffre, avec la durée du transfert.
Le calcul se fait dans votre navigateur : aucune valeur saisie n'est envoyée.
Débit TCP, produit bande passante × délai et durée de transfert
Résultat
Débit d'un flux TCP
1 000 Mbit/s
limité par le lien
Produit bande passante × délai
2,38 Mio
2 500 000 octets : la fenêtre minimale pour remplir le lien
Durée du transfert, un flux
2 h 13 min
Hors en-têtes IP, TCP et Ethernet, qui retirent encore quelques pour cent.
Utilisation du lien
100 %
Flux parallèles pour remplir le lien
1 flux
| Débit du lien | 1 000 Mbit/s |
| Plafond imposé par la fenêtre | 1 678 Mbit/s |
| Plafond imposé par les pertes (Mathis) | aucun |
Comment le calcul est fait
TCP n'envoie jamais plus qu'une fenêtre de données sans avoir reçu d'accusé de réception. Tant que la fenêtre est plus petite que ce que le lien peut contenir, l'émetteur attend. Le calculateur prend donc le plus petit de trois plafonds : le débit du lien, celui qu'autorise la fenêtre, et celui qu'autorisent les pertes.
BDP (octets) = débit (bit/s) × RTT (s) / 8
plafond fenêtre = fenêtre (octets) × 8 / RTT
plafond pertes = (MSS × 8 / RTT) × √(3/2) / √p (Mathis et al., 1997)
débit d'un flux = min(lien, plafond fenêtre, plafond pertes)
flux nécessaires = ⌈ lien / min(plafond fenêtre, plafond pertes) ⌉La fenêtre utile est la plus petite des deux mémoires tampons : celle d'envoi chez l'émetteur, celle de réception chez le destinataire. Sur Linux, le réglage automatique les fait grandir jusqu'à un plafond : entre 64 Kio et 4 Mio selon la RAM pour l'envoi (tcp_wmem), entre 128 Kio et 32 Mio pour la réception (tcp_rmem). Sans l'option window scale, la fenêtre ne dépasse pas 64 Kio.
Le plafond dû aux pertes vient du modèle de Mathis : chaque perte divise la fenêtre de congestion, qui remonte ensuite d'un segment par aller-retour. Plus la latence est grande, plus la remontée est lente. Le MSS par défaut, 1 448 octets, correspond à un MTU de 1 500 octets moins les en-têtes IP (20), TCP (20) et l'option timestamps (12).
Sources : documentation ip-sysctl du noyau Linux (tcp_rmem, tcp_wmem), RFC 7323 (window scaling), Mathis, Semke, Mahdavi et Ott, « The macroscopic behavior of the TCP congestion avoidance algorithm », 1997.
Sauvegardes lointaines et réplication hors site
Une sauvegarde hors site traverse forcément de la latence, et c'est souvent elle, plus que le débit souscrit, qui fixe la durée. Avec la fenêtre d'envoi de 4 Mio que Linux autorise par défaut, un flux plafonne à 1,68 Gbit/s à 20 ms, mais à 335 Mbit/s à 100 ms. Ajoutez 0,01 % de pertes à 100 ms, et le plafond tombe à environ 14 Mbit/s.
C'est ce qui se joue dans la réplication entre deux Proxmox Backup Server : le sync-job transfère les morceaux dédupliqués en HTTPS, donc sur TCP, et subit les mêmes plafonds. Pour savoir si votre sauvegarde vers Nimbus tient dans la nuit, le calculateur de fenêtre de sauvegarde part de votre débit montant et du volume modifié chaque jour. Ce calculateur-ci explique pourquoi le débit réel reste parfois bien en dessous du débit souscrit.
On gagne donc à raccourcir le chemin. Nous opérons notre propre réseau, l'AS206014, depuis les datacenters Equinix PA3, PA4 et PA5, connecté aux points d'échange France-IX, AMS-IX, DE-CIX, LINX et HopUS. Le détail est sur notre page transit IP et peering BGP, et le choix d'opérer un réseau en propre est expliqué sur celle de notre réseau autonome AS206014.
Après le calcul
La durée du transfert n'est qu'une partie de la reprise après incident. Le calculateur RPO / RTO l'ajoute à la détection, à l'intervention et à la remise en service, pour chiffrer la durée d'arrêt réelle. Et pour savoir quel volume vous aurez à transférer, le calculateur ZFS et stockage PBS estime l'espace qu'occupe une rétention de sauvegardes.
Questions fréquentes
Combien de temps pour transférer 1 To sur un lien de 1 Gbit/s ?
Environ 2 h 13 min si un seul flux TCP remplit le lien : 1 000 Go × 8 bits divisés par 1 000 Mbit/s. Les en-têtes IP, TCP et Ethernet ajoutent quelques pour cent. Sur 100 Mbit/s, le même volume prend environ 22 h 13 min. Si la fenêtre TCP est trop petite ou si le lien perd des paquets, un seul flux n'atteint pas ce débit et la durée s'allonge d'autant.
Qu'est-ce que le produit bande passante × délai (BDP) ?
C'est la quantité de données « en vol » sur le lien : le débit multiplié par la latence aller-retour. À 1 Gbit/s et 20 ms, le BDP vaut 2,5 millions d'octets, soit 2,38 Mio. Pour remplir le lien, l'émetteur doit pouvoir envoyer au moins cette quantité sans attendre d'accusé de réception : la fenêtre TCP doit donc être au moins égale au BDP.
Pourquoi mon transfert plafonne-t-il bien en dessous du débit de mon lien ?
Un flux TCP ne dépasse jamais sa fenêtre divisée par la latence. Avec une fenêtre de 64 Kio, sans l'option window scaling, un flux plafonne à 26,2 Mbit/s à 20 ms de latence, quel que soit le débit du lien. Les pertes de paquets sont l'autre cause fréquente : à 20 ms, 0,1 % de pertes limite un flux à environ 22 Mbit/s selon le modèle de Mathis.
Combien de flux parallèles faut-il pour remplir le lien ?
Le débit du lien divisé par le plafond d'un flux, arrondi au-dessus. Sur un lien de 10 Gbit/s à 20 ms, avec la fenêtre d'envoi de 4 Mio que Linux autorise par défaut, un flux plafonne à 1,68 Gbit/s : il en faut 6. C'est pour cela que les outils de réplication et de sauvegarde ouvrent souvent plusieurs connexions.
Ce calculateur remplace-t-il un test de débit ?
Non. Il donne les plafonds théoriques qu'imposent la fenêtre, la latence et les pertes. Le débit réel dépend aussi de l'algorithme de congestion (CUBIC, BBR), du démarrage lent de TCP, du processeur et des disques aux deux bouts. Pour mesurer, lancez un vrai transfert entre les deux machines et comparez-le au plafond calculé ici.
Contact
Adresse
5 B RUE DES NOYERS, 95300 PONTOISE, FRANCE