Pourquoi la mise à niveau de ma bande passante n'a-t-elle pas accéléré la copie de mes fichiers ?

« Nous venons de passer d'une connexion T1 (1,544 Mbps) à une connexion T3 (44,736 Mbps), alors pourquoi faut-il encore 90 minutes pour copier ce fichier ? »

La réponse est simple : une capacité accrue n'est pas synonyme d'une vitesse de transfert plus rapide. Si vous augmentez votre capacité de près de 29 fois (44,736 / 1,544), vous pourrez peut-être copier 29 fichiers en 90 minutes, mais vous ne pourrez probablement pas copier ce fichier plus rapidement. J'ai abordé ce sujet l'année dernière dans le blog intitulé « Problèmes de performances des applications et latence », mais je pense que les transferts de fichiers et copy_file méritent un blog plus approfondi.

La clé réside dans la taille des fenêtres, c'est-à-dire le nombre d'octets que l'hôte/l'application émettrice peut envoyer sans avoir à s'arrêter et à attendre un accusé de réception de la part de l'hôte/l'application réceptrice. Certaines applications, comme FTP, ne disposent pas d'accusé de réception au niveau de la couche application et s'appuient sur TCP. Dans ce cas, la taille de la fenêtre est basée sur ce que la couche TCP de l'hôte distant annonce, jusqu'à 64 Ko, ce qui correspond au maximum pris en charge par STCP. Certaines applications disposent d'une fenêtre de couche applicative. Pour ces applications, la fenêtre limitante est la plus petite des fenêtres TCP et applicative.

Le débit maximal est calculé comme suit :

W / RTT = T

Où

W est la taille de la fenêtre en octets.

Le RTT est le temps aller-retour en secondes.

T est le débit en octets par seconde

Le temps aller-retour est le temps nécessaire pour envoyer des données et obtenir l'accusé de réception. Pour les longues distances, c'est-à-dire à travers le pays, ce temps dépend principalement de la distance que les octets doivent parcourir et de la vitesse de traitement de tous les équipements réseau entre les points d'extrémité. La vitesse de traitement de l'hôte récepteur, la taille des paquets (valeur TCP MSS, voir « Une manière simple d'améliorer le débit entre les sous-réseaux ») et, bien sûr, la bande passante de la liaison la plus lente jouent un rôle moins important.

Par exemple, si le RTT est de 0,050 seconde et que la fenêtre est de 64 Ko, le débit maximal sera de 1 310 720 octets par seconde (64 * 1024 / 0,050). Tant que la capacité inutilisée de la liaison est supérieure au débit, l'augmentation de la capacité n'accélérera pas le temps de transfert.

T est le débit maximal possible. Rien de ce que vous pouvez faire (à part augmenter la fenêtre ou réduire le RTT) ne peut accélérer les choses, MAIS des conditions réseau hostiles peuvent considérablement ralentir les choses.

Pour estimer le temps de transfert, il suffit de diviser la taille du fichier par le débit.

F/ W * RTT = Ti

Où

F est la taille du fichier en octets.

W est la taille de la fenêtre en octets.

Le RTT est le temps aller-retour en secondes.

Ti est le temps en secondes nécessaire pour transférer le fichier.

OSL a une taille de fenêtre d'application de 4 Ko, le système de fichiers OpenVOS rapporte les tailles de fichiers en blocs de 4 Ko, donc pour estimer le temps nécessaire pour copier un fichier entre deux systèmes OpenVOS à l'aide de la commande copy_file, il suffit de

F * RTT = Ti

Où

F est la taille du fichier en blocs.

Le RTT est le temps aller-retour en secondes.

Ti est le temps en secondes nécessaire pour transférer le fichier.

Sur une liaison avec un RTT de 0,050 seconde, OSL mettra un peu plus de 41 minutes pour copier un fichier de 50 000 blocs (50 000 * 0,05). Le débit maximal sera de 81 920 octets par seconde (4096 / 0,050). Tant que la capacité réseau inutilisée de votre liaison est supérieure à 81 920 octets par seconde, l'ajout de capacité ne réduira pas le temps nécessaire à la copie du fichier.

La manière la plus simple de mesurer le temps aller-retour est d'utiliser la commande ping. Malheureusement, ping ne vous donne pas un seul chiffre pour le RTT, mais plusieurs chiffres qui peuvent varier considérablement, par exemple :

Si vous souhaitez calculer le meilleur débit possible, utilisez le chiffre le plus bas. Si vous souhaitez obtenir une estimation raisonnable de ce à quoi vous pouvez vous attendre, utilisez un nombre de pings de 10, éliminez les deux chiffres les plus élevés et les deux chiffres les plus bas, puis calculez la moyenne des chiffres restants.

Comme je l'ai mentionné plus haut, un réseau hostile peut ralentir considérablement les opérations. Les délais d'attente Ping en sont une indication. Ainsi, tout délai d'attente signifie que ces calculs sont probablement très optimistes. Les transferts peuvent également être ralentis par des disques et/ou des processeurs très sollicités qui empêchent l'expéditeur de lire et d'envoyer les données aussi rapidement que possible ou qui ralentissent la lecture des données par le destinataire par rapport à leur vitesse d'arrivée, ce qui retarde les accusés de réception des applications (augmentant ainsi le temps aller-retour) et peut remplir les tampons de réception TCP, ce qui oblige l'hôte expéditeur à interrompre la transmission. La seule façon de savoir si l'une de ces conditions s'applique est d'effectuer un traçage des paquets.