7 votes

Latence dans les réseaux TCP/IP sur Ethernet

Quelles ressources (livres, pages Web, etc.) recommanderiez-vous ?

  • expliquer les causes de la latence dans les réseaux TCP/IP sur Ethernet ;
  • mentionne des outils permettant d'identifier les facteurs de latence (par exemple, certaines entrées dans le fichier netstat -s ) ;
  • suggérer des moyens de modifier la pile TCP de Linux afin de réduire la latence TCP (Nagle, tampons de sockets, etc.).

Le plus proche que je connaisse est le présent document mais c'est assez bref.

Vous pouvez également répondre directement aux questions ci-dessus.

éditer Pour être clair, la question ne porte pas seulement sur la latence "anormale", mais sur la latence en général. En outre, elle porte spécifiquement sur le protocole TCP/IP sur Ethernet et non sur d'autres protocoles (même s'ils présentent de meilleures caractéristiques de latence).

0 votes

Bien entendu, je ne vous ferai pas l'injure de vous demander si vous initiez la connexion en utilisant une adresse IP et non un nom qui doit être résolu via le DNS - et cela ne serait pas dû à la latence du TCP...

1 votes

@ring0 - C'est certainement une belle façon de "ne pas insulter" quelqu'un.

9voto

gfrizzle Points 4518

En ce qui concerne les réglages du noyau pour la latence, il y en a un qui me vient à l'esprit :

echo 1 > /proc/sys/net/ipv4/tcp_low_latency

A partir de la la documentation :

Si cette option est activée, la pile TCP prend des décisions qui privilégient des latence plutôt qu'un débit plus élevé. [ ] [ ] Un exemple d'application où cette valeur par défaut devrait être modifiée serait un cluster de calcul Beowulf. serait un cluster de calcul Beowulf. Valeur par défaut : 0

Vous pouvez également désactiver l'algorithme de Nagle dans votre application (qui mettra en mémoire tampon la sortie TCP jusqu'à la taille maximale du segment) avec quelque chose comme :

#include <sys/types.h>
#include <stdio.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <stdlib.h>
#include <linux/tcp.h>

int optval = 1;
int mysock;

void main() {
    void errmsg(char *msg) {perror(msg);exit(1);}

    if((mysock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) {
        errmsg("setsock failed");
    }

    if((setsockopt(mysock, SOL_SOCKET, TCP_NODELAY, &optval, sizeof(optval))) < 0) {
        errmsg("setsock failed");
    }

    /* Some more code here ... */

    close(mysock);
}

Le "contraire" de cette option est TCP_CORK qui "re-nagera" les paquets. Attention toutefois, car TCP_NODELAY n'ont pas toujours l'effet escompté et, dans certains cas, peuvent nuire aux performances. Par exemple, si vous envoyez des données en masse, vous voudrez maximiser le débit par paquet. TCP_CORK . Si vous avez une application qui nécessite une interactivité immédiate (ou si la réponse est beaucoup plus importante que la demande, ce qui annule la charge de travail), utilisez TCP _NODELAY . Par ailleurs, ce comportement est spécifique à Linux et BSD est probablement différent, donc administrateur de la mise en garde .

Veillez à effectuer des tests approfondis avec votre application et votre infrastructure.

0 votes

(+1) Merci, c'est précisément le type d'information que je recherche.

0 votes

TCP_NODELAY est un bon conseil, mais j'ai constaté en pratique que le réglage de tcp_low_latency n'a aucun effet sur la latence. Il y a peut-être un scénario ésotérique où cela fait une différence, mais nous avons essayé avec différentes cartes réseau et une gamme de noyaux pour obtenir une meilleure latence et nous n'avons pas vu de différence avec ce paramètre.

6voto

sysadmin1138 Points 129885

D'après mon expérience, la principale cause de anormal sur des réseaux à haut débit par ailleurs sains sont le TCP Windowing ( RFC1323, section 2 ), avec une deuxième place, très proche, pour les fautes concernant les TCP Delayed Acks ( RFC1122 section 4.2.3.2 ). Ces deux méthodes sont des améliorations apportées au TCP pour mieux gérer les réseaux à grande vitesse. Lorsqu'elles sont interrompues, les vitesses chutent à des niveaux très lents. Dans ces cas, les défaillances affectent les transferts importants (pensez aux flux de sauvegarde), alors que le petit trafic extrêmement transactionnel (le transfert de données moyen est inférieur à la taille du MTU et il y a BEAUCOUP de va-et-vient) sera moins affecté par ces défaillances.

Une fois de plus, j'ai constaté que les plus gros problèmes liés à ces deux questions se posaient lorsque deux piles TCP/IP différentes communiquaient. Par exemple, Windows/Linux, 2.4-Linux/2.6-Linux, Windows/NetWare, Linux/BSD. Le like to like fonctionne très, très bien. Microsoft a réécrit la pile TCP/IP de Windows dans Server 2008, ce qui a introduit des problèmes d'interopérabilité avec Linux qui n'existaient pas avec Server 2003 (je crois que ces problèmes ont été résolus, mais je n'en suis pas sûr à 100 %).

Des désaccords sur la méthode exacte de l'accusé de réception différé ou sélectif peuvent conduire à des cas comme celui-ci :

192.168.128.5 -> 192.168.128.20: 1500b payload, SEQ 1562
192.168.128.5 -> 192.168.128.20: 1500b payload, SEQ 9524
\[200ms pass\]
192.168.128.20 -> 192.168.128.5: ACK 1562
192.168.128.5 -> 192.168.128.20: 1500b payload, SEQ 12025
192.168.128.5 -> 192.168.128.20: 1500b payload, SEQ 13824
\[200ms pass\]
192.168.128.20 -> 192.168.128.5: ACK 12025

Le débit chute à cause de tous les délais de 200 ms (le délai d'attente de Windows est par défaut de 200 ms). Dans ce cas, les deux parties de la conversation n'ont pas réussi à gérer le TCP Delayed Ack.

Les défauts de TCP Windowing sont plus difficiles à remarquer car leur impact peut être moins évident. Dans les cas extrêmes, le fenêtrage échoue complètement et vous obtenez des paquets->ack->packet->ack->packet->ack, ce qui est vraiment lent lors du transfert de tout ce qui est significativement plus grand que 10KB et qui amplifie tout ce qui a été fait. latence fondamentale sur le lien. Le mode le plus difficile à détecter est celui où les deux parties renégocient continuellement la taille de leur fenêtre et où l'une d'elles (l'expéditeur) ne respecte pas la négociation, ce qui nécessite la gestion de quelques paquets avant que les données puissent continuer à être transmises. Ce type de défaut se traduit par des lumières rouges clignotantes dans les traces Wireshark, mais se manifeste par un débit plus faible que prévu.


Comme je l'ai mentionné, les problèmes susmentionnés ont tendance à affecter les grands transferts. Le trafic tel que la vidéo en continu ou les flux de sauvegarde peuvent être vraiment affectés par ces problèmes, de même que le simple téléchargement de fichiers très volumineux (comme les fichiers ISO de distro Linux). Il se trouve que le TCP Windowing a été conçu comme un moyen de contourner les problèmes fondamentaux de latence, car il permet le pipelining des données ; vous n'avez pas besoin d'attendre le temps d'aller-retour pour chaque paquet envoyé, vous pouvez simplement envoyer un gros bloc et attendre un seul ACK avant d'en envoyer d'autres.

Cela dit, certains modèles de réseaux ne bénéficient pas de ces solutions de contournement. Les petits transferts hautement transactionnels, tels que ceux générés par les bases de données, sont ceux qui souffrent le plus de ces solutions. normal latence sur la ligne. Si le RTT est élevé, ces charges de travail en souffriront beaucoup, alors que les charges de travail en flux large en souffriront beaucoup moins.

2voto

Antoine Benkemoun Points 7284

Il existe de nombreuses réponses à cette question.

Rappelez-vous le fonctionnement du TCP. Le client envoie SYN, le serveur répond SYN/ACK et le client répond ACK. Une fois que le serveur a reçu l'ACK, il peut maintenant envoyer des données. Cela signifie que vous devez attendre deux fois le temps d'aller-retour (RTT) pour envoyer le premier bit de données significatif. Si vous avez 500 ms de RTT, vous avez un délai d'une seconde dès le départ. Si les sessions sont de courte durée mais nombreuses, cela créera beaucoup de latence.

Une fois la session établie, le serveur envoie des unités de données qui doivent être acquittées par le client. Le serveur ne peut envoyer qu'un nombre limité de données avant d'exiger l'accusé de réception de la première unité de données. Cela peut également créer un temps de latence. Si une unité de données est abandonnée, il faut reprendre la transmission à partir de là, ce qui crée un temps de latence supplémentaire.

Au niveau IP, il y a la fragmentation (même si elle est assez rare aujourd'hui). Si vous envoyez des trames de 1501 octets et que l'autre partie ne prend en charge qu'un MTU de 1500, vous enverrez un paquet IP supplémentaire pour ce dernier bit de données. Ce problème peut être résolu en utilisant des trames Jumbo.

La meilleure façon d'augmenter le débit de TCP/IP est de réduire la latence autant que possible et d'éviter les erreurs de transmission autant que possible. Je ne connais pas d'amélioration du noyau, mais je suis sûr que quelqu'un le saura.

1 votes

Et si vous comptez sur les trames jumbo, n'oubliez pas qu'elles doivent être activées de bout en bout pour que vous puissiez en tirer profit...

0 votes

Pour les applications à forte latence, les trames jumbo sont une mauvaise idée, même si elles sont prises en charge de bout en bout.

2voto

JamesBarnett Points 1119

Dans le cas du WAN, la vitesse de la lumière est le principal facteur d'introduction de la latence. Il faut un minimum théorique de ~36,2 ms pour que les données traversent l'Amérique du Nord.

Un aller simple le long des câbles à fibres optiques en quelques secondes :

  • $_DISTANCE_IN_MILES * ( Cable_Refraction / SPEED_OF_LIGHT )

Multiplier par 1000 pour convertir les secondes en millisecondes. Doubler pour l'aller-retour :

  • $_DISTANCE_IN_MILES * ( Cable_Refraction / SPEED_OF_LIGHT ) * 1000 * 2

Voici la latence de Washington, DC zu Los Angeles, CA :

  • 2308 * (1.46 / 186000) * 1000 * 2 = 36.23311ms

  • vitesse de la lumière (en miles par seconde) = 186000
  • indice de réfraction de la fibre optique = 1,46
  • distance (de DC à LA en miles) = 2308

En savoir plus sur la formule

1 votes

Pour les kilomètres, la vitesse de la lumière devrait être de 299 792,458.

1voto

lanoxx Points 1081

Ce n'est probablement pas la réponse que vous cherchez : la principale cause de latence dans un réseau étendu est la vitesse de la lumière (elle est beaucoup trop lente !). En outre, les liaisons saturées avec un gros tampon en cours de route ont tendance à obtenir une latence impressionnante.

0 votes

Oui, vous avez raison. Il faut un minimum théorique de ~36,3 ms pour que les données traversent l'Amérique du Nord. Voir ma réponse pour les calculs.

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