18 votes

Dépannage des vitesses de réseau - la vieille question

Je cherche de l'aide pour répondre à une question qui, j'en suis sûr, est vieille comme le monde. Je me suis retrouvé dans une situation où j'aspire à comprendre plus clairement le débit d'un réseau, mais je n'arrive pas à trouver d'informations qui me fassent "cliquer".

Nous disposons de quelques serveurs répartis géographiquement, exécutant différentes versions de Windows. En supposant que nous utilisons toujours un hôte (un ordinateur de bureau) comme source, lorsque nous copions des données de cet hôte vers d'autres serveurs à travers le pays, nous constatons une grande variation de la vitesse. Dans certains cas, nous pouvons copier des données à 12 Mo/s de manière constante, dans d'autres, nous voyons 0,8 Mo/s. Il convient de noter qu'après avoir testé 8 destinations, nous semblons toujours être soit à 0,6-0,8 Mo/s, soit à 11-12 Mo/s. Dans le bâtiment qui nous intéresse principalement, nous avons une connexion OC-3 avec notre FAI.

Je sais qu'il y a beaucoup de variables en jeu, mais j'espérais que les experts ici présents pourraient répondre à quelques questions de base pour m'aider à mieux comprendre.

1.) Pour des machines plus anciennes, fonctionnant sous Windows XP, server 2003, etc., avec une carte Ethernet 100Mbps et une latence typique de 72 ms, est-ce que 0,8 MB/s semble raisonnable ? Ou pensez-vous que cette lenteur soit suffisante pour indiquer un problème ?

2.) La "vitesse mathématique la plus rapide" classique de "débit = fenêtre TCP / latence" est, dans notre cas, calculée à 0,8 MB/s (64Kb / 72 ms). D'après ce que j'ai compris, il s'agit d'une limite supérieure ; on ne s'attend pas à atteindre (en raison de l'overhead) et encore moins à dépasser cette vitesse. Dans certains cas, cependant, nous observons des vitesses de 12,3 Mo/s. Il y a des accélérateurs Steelhead dispersés sur le réseau, pourraient-ils expliquer un taux de transfert aussi élevé ?

3.) Il a été suggéré que l'utilisation de SMB par rapport à SMB2 pourrait expliquer les différences de vitesse. En effet, comme prévu, les captures de paquets montrent que les deux sont utilisés en fonction des versions du système d'exploitation en jeu, comme on pouvait s'y attendre. Je comprends ce qui détermine l'utilisation ou non de SMB2, mais je suis curieux de savoir quel type de gain de performance vous pouvez attendre avec SMB2.

Mon problème semble simplement être un manque d'expérience, et plus important encore, de perspective, en termes de ce que sont et ne sont pas des vitesses de réseau raisonnables. Quelqu'un pourrait-il m'aider à trouver un contexte/perspective ?

4voto

rnxrx Points 8043

La formule mathématique à laquelle vous faites référence est en fait le moyen de déterminer les paramètres de taille de fenêtre de transmission les plus efficaces pour TCP, et non la bande passante réellement disponible. TCP utilise un mécanisme appelé fenêtre glissante qui permet d'ajuster les vitesses de transmission en fonction des conditions du réseau. L'idée est qu'un émetteur TCP envoie de plus en plus de données sans exiger d'accusé de réception de la part du récepteur. S'il y a une perte de données, la quantité de données envoyées entre les accusés de réception diminue, ce qui réduit également la bande passante effective.

La formule en question détermine en fait la taille idéale de cette fenêtre de transmission TCP en fonction de la latence et du temps de latence aller-retour entre une paire d'hôtes donnée. L'idée est d'avoir une fenêtre de taille telle que la quantité de données "en vol" corresponde à ce que l'on appelle le produit bande passante-délai. Par exemple, si vous disposez de 50 mégabits par seconde (6,25 méga-octets) et d'une latence aller-retour moyenne de 100 ms, vous aurez 6,25 * 0,1 = 625 kilo-octets de données. C'est la valeur que le protocole TCP négocierait (s'il est configuré correctement). La taille de la fenêtre varie en fonction des caractéristiques de latence et de bande passante de vos liaisons.

Ce dont vous avez besoin, c'est d'un outil de gestion de la bande passante, comme iperf (gratuit), qui fonctionne à la fois sur la source et sur vos différentes destinations. Cela devrait vous donner une idée de la quantité réelle de débit possible (indépendamment des autres applications) tout en fournissant également un aperçu de la latence. L'exécution d'un ping étendu entre les hôtes vous donnera également une idée générale des caractéristiques de latence. Lorsque vous aurez ces données, vous aurez une meilleure idée de ce que vous devriez voir en termes de débit.

BTW - L'utilisation de tout type d'optimiseur de réseau local intègre souvent la compression des données, l'optimisation TCP, la mise en cache, etc. Bien que pratique, cela peut masquer la nature des liens sous-jacents. Une fois que vous avez une idée de la bande passante brute / du délai (et de la perte de paquets, potentiellement), vous pouvez regarder de plus près pour vous assurer que vos différents hôtes sont configurés pour tirer correctement parti de la bande passante disponible.

2voto

Ilya Points 31

Essayez "ping -l 8092" ou FTP ou HTTP pour vérifier si c'est un problème de SMB.

Tout d'abord : quel support utilisez-vous pour connecter les ordinateurs ? Qu'est-ce que le "100mpbs" ? Ethernet ? Vous ne pouvez pas l'utiliser pour des ordinateurs "distribués géographiquement", n'est-ce pas ?

Dans le cas du "vpn sur Internet", les routeurs entre vos ordinateurs peuvent utiliser des liens différents : l'un est rapide, l'autre non. Ils peuvent choisir le lien en fonction de nombreux paramètres.

Veuillez décrire votre réseau.

Cela pourrait également être un problème de MTU : plusieurs liens peuvent avoir des MTU différents.

2voto

Univ426 Points 2139

De nombreux commentaires et utilisateurs ont donné de bons conseils à ce sujet. Certains d'entre eux sont assez proches de ce que je recherchais, mais j'ai également eu la chance de rencontrer un vétéran du réseau de notre entreprise qui m'a aidé à clarifier les choses. J'ai pensé poster mes conclusions/compréhensions ici pour en faire profiter les autres. N'hésitez pas à me corriger si vous avez des doutes :

1.) Le débit maximal d'une session TCP unique avec une latence de 72ms et une fenêtre de 64K est d'environ 0,8 MB/s, ce qui rend cette vitesse raisonnable pour des copies à un seul fil, une seule session, comme celles que nous avons effectuées avec robocopy.

2.) Cette différence de vitesse semble se résumer à l'efficacité de la méthode de transfert. Dans notre cas, nous utilisions Robocopy et Repliweb. J'ai découvert que Robocopy utilise une seule session TCP, alors que Repliweb peut ouvrir plusieurs sessions pour envoyer les données.

3.) Les recherches effectuées sur le site Web de Microsoft montrent que SMB2 offre un gain de performance considérable par rapport à SMB1. Toutefois, dans certains cas, des problèmes ont été rencontrés dans la façon dont le système d'exploitation négocie le protocole à utiliser, de sorte qu'il faut être conscient a.) des cas dans lesquels SMB2 puede être utilisé, et b.) si SMB2 est réellement utilisé ou non, en se basant sur les captures du réseau.

Actuellement, il semble que Wire-shark puisse déterminer l'utilisation du protocole SMB2.

J'espère que cela vous aidera. Encore une fois, ma compréhension est assez rudimentaire ici, n'hésitez pas à développer.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X