L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2024 !
Paramètre de configuration du protocole TCP dans les serveurs Linux pour résoudre le problème de latence du réseau.
Le protocole TCP (Transmission Control Protocol) est un protocole de mise en réseau fondamental. Il fait partie de la suite de protocoles Internet et fonctionne dans la couche transport. Toutes les transmissions de mise en réseau sont divisées en paquets. TCP garantit que tous les paquets arrivent, dans l'ordre et sans erreur. Cela nécessite beaucoup de communication de va-et-vient (prise de contact à trois). Le problème se produit lorsque le paquet n'est pas arrivé dans un délai stipulé en raison de nombreux facteurs. La connexion réseau devient très lente et cause de la frustration pour l'utilisateur final. Dans cet article, l'explication d'un scénario en temps réel de latence du réseau et des expériences sur la récupération du serveur Linux à partir de la latence est donnée.
LATENCE DANS LE RÉSEAU :
RTT – TEMPS DE DÉCLENCHEMENT ROND .
C'est le temps mis par un paquet pour voyager d'une source spécifique vers une destination et vice-versa.
C'est un facteur important pour savoir si l'accusé de réception du paquet a pris le bon moment.
En réalité termes, nous exécutons la commande ping vers l'IP de destination à partir de la source pour savoir que la communication est vivante ou morte.
La latence est considérée comme le temps retardé dans la communication où RTT est plus élevé que la normale .
De nombreux autres facteurs comme la distance entre la source et la destination, le nombre de sauts entre eux et leur état, etc. a également un impact sur la latence.
LINUX SPECIFIC :
Pour connaître le nombre de sauts entre la source et la destination, il existe sont peu d'options intégrées disponibles comme traceroute, snoop tracing, tcpdump etc. pour obtenir les détails d'exécution à partir d'un noyau Linux patché.
TRACEROUTE COMMAND :
Cette commande permet de voir l'état de 30 sauts maximum entre la source et la destination.
| Commande: nom d'hôte traceroute |
Il se termine une fois que la destination est atteinte ou à un saut entre les deux où le saut est interrompu, donc plus de communication. ]
Brefs détails sur les paquets en cours de transmission. Il est très utile pour l'analyse au niveau des paquets et couramment utilisé pour l'analyse.
TCPDUMP:
Wireshark peut être utilisé pour récupérer les détails du vidage TCP. Les informations spécifiques au niveau du socket peuvent être récupérées à l'aide de la commande 'SS'
Exemple:
Ss –inet
I, n, e, t sont des options pour les commandes où
-n, –numeric Do n'essayez pas de résoudre les noms de service. Afficher les valeurs exactes de bande passante, au lieu de lisibles par l'homme. -e, –extended Afficher les informations détaillées sur les sockets. i, –info Afficher les informations TCP internes -t, –tcp Afficher les sockets TCP. |
Toutes les informations mentionnées ci-dessus étaient des informations de base pour l'analyse de paquets. Les paramètres TCP qui affectent le flux de paquets sont
1. ALGORITHMES DE CONTRÔLE DE CONGESTION . Il existe de nombreux algorithmes en place pour déterminer la façon dont les paquets sont envoyés et les accusés de réception sont reçus. Il existe un terme appelé fenêtre de congestion. Tous les algorithmes sont définis autour de ce
Quelques exemples
1. CUBIC: Il s'agit d'un algorithme traditionnel utilisé dans le noyau Linux principalement pour les réseaux à large bande passante et à latence élevée
2. RENO: Ceci est également utilisé comme un objet traditionnel dont le but principal est une récupération rapide.
3. BBR est le dernier (bande passante goulot d'étranglement et temps de propagation aller-retour) trouvé par Google. En utilisant cela, l'utilisation de you-tubes a été rendue plus rapide de 14% dans le monde. Lorsque le problème est survenu, l'encombrement a été vérifié sur le serveur Linux.
| sysctl -a | grep tcp_congestion_control |
Cette commande affiche l'algorithme de congestion actuellement utilisé.
Sysctl -a diplays toutes les configurations de niveau système
Il existe de nombreux problèmes de réseau dans l'utilisation de la traditionnelle algorithmes (CUBIC et RENO). Ainsi, Google est venu avec l'algorithme BBR pour réduire la latence. Cela ne peut être implémenté que dans Linux version 4.9 et supérieure. Les serveurs existants étaient inférieurs à 4,9, donc la mise à niveau de la version au moment critique n'était pas possible, elle a donc été conservée comme un futur correctif.
Pour une correction immédiate, la mise à l'échelle de la fenêtre TCP a été modifiée. Le 2 nd facteur qui influe sur la latence du réseau est la taille de la fenêtre de réception TCP. Le réglage de la taille de la fenêtre TCP dépend de ce qui suit.
| Facteur de mise à l'échelle de la fenêtre TCP Taille de la fenêtre de l'expéditeur Taille de la fenêtre de réception Taille de la fenêtre TCP. |
Parmi elles, la taille de la fenêtre de réception est une clé.
TCP est connu pour sa fiabilité et ceci est réalisé par la prise de contact à trois voies. ·
- L'expéditeur envoie les données ·
- Le récepteur les reçoit. ·
- Le récepteur renvoie l'accusé de réception à l'expéditeur en disant qu'il a reçu les données. [19659056] L'expéditeur ne peut envoyer que la quantité de données qui limite la taille du récepteur et il ne peut pas en envoyer plus qu'il le souhaite. De plus, l'expéditeur ne peut pas envoyer de données supplémentaires s'il ne reçoit pas d'accusé de réception du destinataire pour les données envoyées précédemment. Dans un scénario si la taille de la fenêtre de réception est définie sur 0, l'expéditeur ne peut jamais envoyer d'informations avant d'avoir reçu un accusé de réception du récepteur avec une valeur de taille de fenêtre non nulle.
Dans notre scénario, la taille du récepteur a été définie sur une valeur supérieure. approprié pour la bande passante du réseau, mais la taille de l'expéditeur était inférieure. C'était juste 8k. La taille de la fenêtre TCP et celle de l'expéditeur étaient toutes deux de 8 Ko.
Le noyau Linux définit toujours la taille du récepteur à deux fois la taille de l'expéditeur. Ce travail est effectué par le noyau.
Le récepteur doit donc être de 16 Ko, mais nous pouvons également régler les paramètres individuels afin que le récepteur soit défini sur 32 Ko (le noyau définit la valeur la plus élevée comme valeur finale).
L'expéditeur essaiera uniquement d'envoyer 8k de données même si le récepteur a une bande passante pour recevoir plus de données. Après de nombreuses expériences, nous avons réglé la valeur de sendbuf à 32k. Cela a réduit la latence du réseau à un niveau drastique.
Dans l'explication d'un profane:
Sendbuf est la quantité d'octets que l'expéditeur peut envoyer d'un seul coup. De même, Recvbuf est la quantité d'octets que le récepteur peut recevoir en une seule instance. La taille de la fenêtre peut être comparée à un panier. Panier contenant les données de l'expéditeur au destinataire. La quantité de données qu'il peut transporter dépend de la taille du panier (qui à son tour dépend de la bande passante. C'est pourquoi il y a un calcul pour déterminer la taille qui est le produit de la bande passante et du retard dans l'envoi des données).
Peu de détails sur perspective de test:
Nous pouvons définir manuellement la latence sur l'émulateur de réseau (netem) sur le câble Ethernet.
tc qdisc add dev eth0 root netem delay 160ms - Tc is traffic controller (inbuilt in Linux, same not available in Solaris)
- Qdisc met en file d'attente la configuration en tc. C'est la valeur par défaut.
- Ajouter – commande d'ajout
- Au périphérique Ethernet eth0
- Avec l'autorisation root sur l'émulateur de réseau (netem)
- De retard (latence) pendant 160 ms.
Connaître Ethernet
Ici ens3 doit être utilisé à la place de eth0 De même pour supprimer
tc qdisc del dev eth0 root netem En définissant la latence et en réglant les paramètres de la fenêtre avec sysctl, nous pouvons expérimenter et atteindre les valeurs souhaitées et appropriées pour notre réseau.
Source link