Dans mon travail, je dois en apprendre beaucoup sur plusieurs sujets. En particulier sur le marché de la virtualisation, de nombreuses personnes sont généralement bien préparées en matière d’infrastructure, de serveurs et de stockage, mais j’ai découvert que le point le plus faible est la mise en réseau. Certains sujets sont obscurs pour beaucoup, comme Layer2 vs Layer3, BGP, Spanning Tree, mais il y a un sujet qui est vraiment important même pour les gars de l’infrastructure, mais il leur est presque inconnu: la latence.
Qu’est-ce que la latence ?
Aussi rapide que cela puisse être, même la vitesse de la lumière n’est pas infinie. Il faut du temps à un photon pour passer du point A au point B, et par exemple la lumière générée par le Soleil met 8 minutes à atteindre la Terre. Nos réseaux informatiques ne sont même pas proches de cette vitesse, car d’abord nos connexions ne se font généralement pas avec de la fibre optique (qui serait finalement aussi rapide que la lumière) mais avec des câbles électriques et donc les transmissions sur ces supports sont plus lentes, mais aussi parce qu’il existe de nombreux appareils entre la source et la destination qui doivent manipuler le paquet. L’hôte source, les commutateurs, les routeurs, les pare-feu, l’hôte cible ; chaque « saut » ajoute du temps au temps total dont un paquet a besoin pour atteindre sa destination. Nous pouvons concevoir cette situation comme ceci:
( source: https://stackoverflow.com/questions/8682702/how-to-calculate-packet-time-from-latency-and-bandwidth )
Ainsi, dit simplement, la latence est le temps qu’il faut à un paquet pour passer de la source à la destination.
Dans un réseau local, il est facile d’appliquer une approximation et de déclarer que le délai de traitement est de 0, et que les multiples commutateurs entre deux hôtes n’ajoutent pas de latence supplémentaire. Après tout, lorsque nous exécutons une commande ping pour vérifier si un hôte est connecté, la latence est toujours « inférieure à 1 ms » :
Pour cette raison, il n’est pas rare de calculer la vitesse de transfert maximale en regardant simplement la bande passante disponible:
– Une liaison ethernet de 1 Go, divisée par 8, me donne 125 Mbps
– Une liaison ethernet de 10 Go signifie 1250 MBps
et ainsi de suite. Et si ma bande passante est de 125MBps, cela signifie que je peux transférer 125MB chaque seconde.
Pourquoi la latence est-elle importante ?
Car l’ignorer, avec d’autres paramètres, conduit à de faux résultats!
Regardez l’exemple précédent. Même sur un réseau local, où la latence est proche de zéro, d’autres paramètres peuvent avoir un impact sur la vitesse finale. Un avant tout: la taille de la fenêtre TCP. Je ne vais pas répéter ce qui a déjà été écrit de manière parfaite par d’autres, donc si vous voulez en savoir plus, lisez cet article de Brad Hedlund. Quel est le piège? La vitesse de liaison dont nous parlons habituellement est la vitesse de liaison par câble pure. Mais en plus, nous devons exécuter plusieurs protocoles, l’un au-dessus de l’autre, comme TCP sur IP. TCP divise les données en paquets, et la taille des paquets est dictée par la taille de la fenêtre TCP: plus cette valeur est grande, plus de données peuvent être transférées en une seule transmission. Ensuite, une charge utile est emballée dans un paquet, il y a donc des octets supplémentaires pour chaque paquet à transmettre, même s’ils ne contiennent aucune donnée (il y a aussi une surcharge pour la trame Ethernet sous-jacente, pensez à toute la discussion en ce qui concerne les trames Jumbo). Enfin, la latence TCP joue son rôle, car je ne peux transmettre le paquet suivant qu’une fois que le précédent a atteint sa destination, car le lien est par ailleurs occupé à transférer les autres paquets.
La latence et la taille de la fenêtre deviennent primordiales lorsque nous passons des réseaux locaux aux réseaux publics. Ici, la valeur < 1ms disparaît, et nous avons des valeurs plus élevées à prendre en compte. Plus la latence est élevée, plus petite est la bande passante « réelle » maximale que je verrai. Prenons un exemple simple : un client dispose d’un lien de 100 Mbps vers Internet et doit transférer un fichier de 1 To à son fournisseur de services.
Les calculs théoriques habituels seraient simples:
100 Mbps = 12,5 MBps
1 To = 1000 Go = 1000000 Mo
1000000 Mo / 12,5 MBps = 80000 secondes = 1333,33 minutes = 22,22 heures ou (d:h:m :s): 22h: 13m:20s
Mais si vous essayez d’envoyer ce fichier à votre fournisseur, il ne prendra JAMAIS ce temps à compléter, sauf si vous et votre fournisseur de services êtes connectés à la même liaison ethernet; ce qui signifie que vous n’utilisez pas du tout Internet!
Comment calculer correctement la vitesse de transfert
J’ai calculé la valeur précédente jusqu’aux secondes exactes en utilisant ce bel outil:
http://wintelguy.com/transfertimecalc.pl
Si vous le regardez cependant, vous verrez la même « erreur d’approximation » dont j’ai parlé précédemment: seules la taille et la bande passante sont prises en compte. Pas de taille de fenêtre et pas de latence. Mais le site Web WintelGuy a des outils plus étonnants, et l’un est exactement ce dont nous avons besoin:
http://wintelguy.com/wanperf.pl
Dans celui-ci, vous pouvez voir que chaque paramètre important est répertorié et utilisé pour les calculs. Répétons le même calcul que nous avons fait auparavant, mais maintenant avec de nouvelles informations:
Nous avons ajouté une latence de 40 ms et accepté les deux autres valeurs par défaut (perte de paquets et MTU). Nous n’avons aucune chance de changer de MTU via une liaison Internet, car de nombreux appareils entre nous et nos fournisseurs de services ne sont pas sous notre contrôle. C’est l’une des raisons pour lesquelles de nombreux opérateurs de télécommunications proposent à leurs clients des liens privés MPLS au lieu de liens VPN sur Internet public, car les paramètres de connexion peuvent être contrôlés et réglés par le fournisseur (enfin, il y a aussi un peu de verrouillage, mais c’est une autre histoire…). Ici, vous voyez que la surcharge et la latence TCP affectent déjà le débit maximal réel, qui tombe à 94,9 Mbps. Je dirais cependant que c’est une très bonne situation, et cela pourrait être pire: gardons tous les autres paramètres comme avant, et augmentons la latence à 150 ms:
Le débit est réduit à 77,8Mbps, soit une perte de 22% de la vitesse théorique. Et ça peut être encore pire : une connexion ADSL par exemple a plus de pertes de paquets, donc si on garde 150ms de latence, mais qu’on augmente la perte de paquets de 10 fois, on l’obtient (ignorez le fait qu’aucun ADSL ne peut aller à 100 Mbps, c’est fait pour garder la même vitesse sur tous les exemples):
La perte de paquets est passée de 0,0001 (1 paquet perdu pour 10000 transmis) à 0.001 (1 paquet perdu pour 1000 transmis), et cette valeur à elle seule a diminué notre vitesse maximale de 75%!!!
Donc, la prochaine fois que vous verrez que votre nouvelle ligne Internet brillante ne fonctionnera pas comme prévu, avant de blâmer votre fournisseur de services ou le logiciel que vous utilisez pour transférer ces données, jetez un meilleur œil à votre réseau. Vous constaterez peut-être que ces 25 Mbps sont la vitesse la plus rapide que vous puissiez obtenir.
