Vous venez d'acheter un serveur avec un canal dédié garanti à 1Gbit/s (ou plus) et vous êtes déçu de constater que les transferts de fichiers ne sont pas aussi rapides que vous l'aviez prévu. Avant d'écrire à l'assistance technique et de chercher des problèmes de réseau, essayez d'évaluer le débit TCP réel d'un hôte à l'autre.
Les deux facteurs les plus importants pour la réussite d'un transfert de données via TCP sont les suivants :
- Lataille de la fenêtre TCP - c'est le nombre d'octets qu'une partie accepte sans confirmation ;
- Ledélai circulaire de transmission-réception (latence) - le temps nécessaire pour envoyer un paquet et confirmer sa livraison.
- La connaissance de ces deux éléments vous permettra de calculer la bande passante maximale pouvant être partagée entre deux hôtes, quelle que soit la bande passante.
La formule de calcul de la bande passante TCP
Débit TCP (bits/s) = Taille de la fenêtre TCP (bits) / Latence aller-retour (s)
Prenons un exemple simple. Nous disposons d'une liaison Ethernet gigabit entre serveurs avec une latence circulaire de 30 ms. Nous devons envoyer un gros fichier d'un serveur à un autre par FTP. Quelle largeur de bande réelle pouvons-nous espérer ?
Il faut d'abord convertir la taille de la fenêtre TCP d'octets en bits. Dans ce cas, nous utiliserons la taille de fenêtre TCP standard d'une machine Windows, soit 64 KB = 65 536 B = 65 536 * 8 = 524 288 bits.
Il faut ensuite prendre la taille de la fenêtre TCP en bits et la diviser par la latence circulaire du canal, exprimée en secondes. Pour les besoins de ces calculs, 30 ms correspond à 0,030 s.
Débit TCP maximal = 524 288 bits / 0,030 s = 17 476 266 bps = 17,4 Mbps
Bien qu'il y ait une connexion Ethernet gigabit entre les deux serveurs, il ne faut pas s'attendre à plus de 17 Mbit/s lors du transfert de fichiers.
Comment rendre le réseau plus rapide ? La réponse est évidente : augmenter la taille de la fenêtre TCP et/ou réduire le délai du signal.
La négociation d'une fenêtre TCP plus grande nécessite une configuration manuelle individuelle de chaque serveur, ce qui conduit à la question suivante : quelle est la taille optimale de la fenêtre TCP ? Pour le savoir, il est nécessaire d'effectuer un calcul inverse basé sur la largeur de bande.
La formule pour calculer la taille optimale de la fenêtre TCP est la suivante
Taille de la fenêtre TCP (octets) = Taille de la fenêtre TCP (bits) / 8 = Largeur de bande (bits/s) * Latence aller-retour (s) / 8
Dans l'exemple ci-dessus, pour une route Ethernet gigabit entre serveurs avec une latence circulaire de 30 ms, on obtient la valeur suivante :
1 000 000 000 bits/s * 0,030 s = 30 000 000 bits / 8 = 3 750 000 octets.
En d'autres termes, si vous configurez les deux serveurs pour une fenêtre TCP de 3 750 KB, la connexion FTP remplira complètement la bande passante et atteindra une bande passante de 1 Gbit/s.
Il faut savoir que l'augmentation de la taille de la fenêtre TCP présente des inconvénients.
Tout d'abord, il faudra plus de mémoire pour mettre en mémoire tampon les serveurs, ce qui est nécessaire pour stocker les données non confirmées au cas où elles seraient présentes.
Deuxièmement, l'augmentation de la taille de la fenêtre TCP peut entraîner la perte d'un plus grand nombre de paquets, ce qui nécessite la réexpédition d'une fenêtre entière. Cela peut avoir un impact négatif sur les performances. Pour résoudre ce problème, la pile TCP/IP du serveur peut activer l'option "selective acknowledgment", qui est désactivée par défaut.
Pour résoudre ce problème, des accélérateurs WAN - des accélérateurs de réseau globaux - peuvent être placés aux deux extrémités de la ligne. Ils peuvent effectuer les opérations suivantes
- ouvrir une fenêtre TCP élargie
- offrir la possibilité d'optimiser finement le protocole TCP (par exemple, acquittement sélectif uniquement entre les pédales d'accélérateur) ;
- ne nécessitent pas de configuration spéciale du serveur ni de mémoire tampon supplémentaire ;
- peuvent utiliser des fonctions spéciales de la couche application du modèle OSI (couche 7 - accès aux services du réseau) pour réduire le délai circulaire.
Temps de latence
Vous voulez réduire le retard des signaux ? Est-ce possible en principe ? Comme nous ne pouvons pas vaincre la vitesse de la lumière, nous ne pouvons pas influencer le temps qu'il faut à un signal pour parcourir une certaine distance. La meilleure façon d'optimiser un système complet est d'installer un accélérateur WAN à chaque extrémité de la ligne, qui transmet les paquets TCP reçus au serveur local, le "trompant" ainsi sur le taux réel de transfert de données. Cela nous évite d'avoir à ajuster la taille de la fenêtre TCP sur les serveurs eux-mêmes. Une paire d'appareils WAAS utilise une fenêtre TCP plus grande et des accusés de réception sélectifs sur l'ensemble du segment de ligne.
En outre, le WAAS purge efficacement un flux TCP des données redondantes, ce qui permet d'obtenir un niveau de compression extrêmement élevé (compression). Chaque pédale d'accélérateur se souvient des données précédemment consultées. Si un fragment dupliqué se reproduit, il est supprimé et remplacé par une minuscule balise de 2 octets. Cette marque minuscule est reconnue par la pédale d'accélération distante, qui insère le fragment de données original à sa place avant d'envoyer le trafic au serveur local.
Le résultat avéré de l'optimisation est un débit plus élevé entre les serveurs sans qu'il soit nécessaire de procéder à un réglage TCP spécial des serveurs locaux.
Formule de calcul du délai maximal admissible pour un débit donné
Exemple. Sur un site entre deux serveurs distants, vous devez garantir un débit FTP de 10 Gbps en utilisant une taille de fenêtre TCP standard (64KB). Quel est le délai maximal autorisé pour le signal ?
Latence aller-retour (ms) = taille de la fenêtre TCP (bits) / largeur de bande requise (bps)
524 288 bits / 10 000 000 bps = 52,4 microsecondes
Que faire ?
En principe, il n'est pas nécessaire d'augmenter la fenêtre TCP ou d'installer des amplificateurs de réseau étendu. Il suffit d'utiliser le multithreading et vous pourrez utiliser le canal à 100 % de sa bande passante !