Optimisation de TCP pour améliorer les performances réseau

Cette page décrit les méthodes permettant de calculer les paramètres corrects pour réduire la latence de vos connexions TCP dans les scénarios Google Cloud et hybrides. Cette page vous aide également à mieux comprendre comment améliorer la latence de connexion entre les processus dans Google Cloud.

L'architecture moderne de microservices préconise le développement de petits services ayant une seule responsabilité. Les services doivent communiquer via TCP ou UDP, en fonction des attentes de fiabilité du système. Il est donc essentiel que les systèmes basés sur les microservices communiquent de manière fiable et avec une faible latence.

Google Cloud assure à la fois fiabilité et faible latence en fournissant un réseau mondial, ce qui signifie que vos utilisateurs peuvent également opérer au niveau international. Disposer d'un réseau mondial signifie que vous créez un réseau cloud privé virtuel (VPC, Virtual Private Cloud) qui couvre des régions et des zones. Les applications peuvent se connecter entre elles dans plusieurs régions et zones sans quitter le réseau Google Cloud.

Les applications développées pour un environnement de centre de données traditionnel peuvent présenter un ralentissement des performances lorsqu'elles sont déplacées vers un environnement cloud hybride, c'est-à-dire lorsque certains composants de l'application s'exécutent dans un centre de données d'entreprise et d'autres dans le cloud. La lenteur des performances peut être le résultat d'un certain nombre de facteurs. Cet article porte sur les latences aller-retour et leur incidence sur les performances TCP dans les applications qui déplacent une quantité considérable de données sur une partie quelconque du réseau.

Le problème : latence et comportement TCP

TCP utilise un mécanisme de fenêtrage pour empêcher qu'un émetteur rapide ne surcharge un récepteur plus lent. Le récepteur annonce la quantité de données que l'émetteur doit envoyer avant d'attendre l'actualisation de la fenêtre par le récepteur. Par conséquent, si une application réceptrice ne peut pas recevoir de données sur la connexion, la quantité de données pouvant être mises en file d'attente est limitée.

La fenêtre TCP permet une utilisation efficace de la mémoire sur les systèmes émetteurs et récepteurs. Lorsque l'application réceptrice consomme des données, l'actualisation de la fenêtre est envoyée à l'émetteur. Le délai le plus rapide d'actualisation d'une fenêtre correspond à un aller-retour, ce qui conduit à la formule suivante pour calculer l'une des limites de performance du transfert de données groupées sur une connexion TCP :

Débit <= taille de la fenêtre / latence du délai aller-retour (DAR)

Dans la conception d'origine de TCP, la taille maximale de cette fenêtre est de 65 535 octets (64 KiB - 1). Ce chiffre correspondait à la quantité maximale de données que l'émetteur pouvait envoyer avant de recevoir l'actualisation de la fenêtre qui lui permettrait l'envoi d'une quantité de données plus importante.

Modifications apportées à TCP depuis son introduction

Depuis son introduction, certaines fonctionnalités clés de TCP ont changé :

La vitesse courante des réseaux a été multipliée par quatre.
La mémoire typique d'un système a été multipliée par quatre.

Résultat de la première modification : les tailles de fenêtre TCP initiales ont entraîné une utilisation inefficace des ressources réseau. Un émetteur envoie une quantité de données égale à la taille d'une fenêtre à la meilleure vitesse possible dans les conditions du réseau, puis reste inactif pendant une période de temps considérable en attendant l'actualisation de la fenêtre TCP. Résultat de la seconde modification : les émetteurs et les récepteurs disposent davantage de mémoire pour la mise en réseau, ce qui leur permet de contourner la limite résultant de la première modification.

Le schéma suivant illustre ce format d'échange.

L'émetteur envoie seulement 64 K de données et attend très longtemps après l'envoi avant de recevoir l'actualisation de la fenêtre.

L'émetteur ne peut pas utiliser pleinement le réseau, car il attend l'actualisation de la fenêtre TCP avant d'envoyer des données supplémentaires.

Envoyer davantage de données à la fois

La solution consiste à envoyer davantage de données à la fois. À mesure que la bande passante du réseau augmente, davantage de données peuvent être acheminées dans le canal (réseau) et, à mesure que le canal s'allonge, le délai nécessaire pour accuser réception des données devient plus long. C'est ce qu'on appelle le produit délai-bande passante (BDP, Bandwidth-Delay Product). Il correspond à la largeur de bande passante multipliée par le délai aller-retour (DAR), ce qui donne une valeur qui spécifie le nombre optimal de bits à envoyer pour remplir le canal. La formule est la suivante :

BDP (bits) = bande passante (bits/seconde) * DAR (secondes)

Le BDP calculé est utilisé comme taille de fenêtre TCP à des fins d'optimisation.

Par exemple, imaginons que vous disposiez d’un réseau de 10 Gbit/s présentant un DAR de 30 millisecondes. Pour la taille de la fenêtre, utilisez la valeur de la taille de la fenêtre TCP d'origine (65 535 octets). Cette valeur est loin de tirer parti de la capacité de bande passante. Les performances TCP maximales possibles sur cette liaison sont les suivantes :

(65 535 octets * 8 bits/octet) = bande passante * 0,030 seconde
bande passante = (65 535 octets * 8 bits/octet) / 0,030 seconde
bande passante = 524 280 pixels / 0,030 seconde
bande passante = 17 476 000 bits/seconde

En d'autres termes, ces valeurs permettent d'obtenir un débit légèrement supérieur à 17 Mbits par seconde, ce qui représente une petite fraction de la capacité du réseau 10 Gbit/s.

La solution : adaptation de fenêtre TCP

Pour résoudre les limitations de performances imposées par la conception initiale de la taille de fenêtre TCP, des extensions du protocole TCP ont été introduites, lesquelles permettent d'ajuster la taille de la fenêtre à des valeurs beaucoup plus grandes. L'adaptation de fenêtre TCP s'applique à des fenêtres dont la taille peut atteindre 1 073 725 440 octets, soit près de 1 Gio. Cette fonctionnalité est décrite dans la RFC 1323 en tant qu'option d'adaptation de fenêtre TCP.

L’extension d’adaptation de fenêtre étend la définition de la fenêtre TCP à 30 bits et utilise ensuite un facteur de scaling pour porter ces valeurs de 30 bits dans le champ de fenêtre de 16 bits de l’en-tête TCP. Pour voir si la fonctionnalité est activée sur les systèmes Linux, utilisez la commande suivante :

sudo sysctl net.ipv4.tcp_window_scaling

(Cette fonctionnalité est activée par défaut sur toutes les machines virtuelles Linux de Google Cloud.) Une valeur de retour de 1 indique que l'option est activée. Si la fonctionnalité est désactivée, vous pouvez l'activer à l'aide de la commande suivante :

sudo sysctl -w net.ipv4.tcp_window_scaling=1

Débit avec une taille de fenêtre plus grande

Vous pouvez utiliser l'exemple précédent pour montrer l'avantage de l'adaptation de fenêtre. Comme dans cet exemple, supposons un réseau de 10 Gbit/s présentant une latence de 30 millisecondes, puis calculons une nouvelle taille de fenêtre à l'aide de la formule suivante :

(Vitesse de la liaison * latence) / 8 bits = taille de la fenêtre

Si vous utilisez les chiffres de l'exemple, vous obtenez ceci :

(10 Gbit/s * 30 ms / 1 000 s) / 8 bits/octet = taille de la fenêtre
(10 000 Mbit/s * 0,030 seconde) / 8 bits/octet = 37,5 Mo

Augmenter la taille de la fenêtre TCP à 37 Mo peut augmenter la limite théorique des performances de transfert de données groupées de TCP à une valeur proche de la capacité du réseau. Bien entendu, de nombreux autres facteurs peuvent limiter les performances, tels que la surcharge du système, la taille moyenne des paquets et le nombre d'autres flux partageant la liaison, mais comme vous pouvez le constater, la taille de la fenêtre compense largement les limites imposées par la taille restreinte précédente.

Définir les paramètres Linux configurables afin de modifier la taille de la fenêtre TCP

Sous Linux, la taille de la fenêtre TCP est affectée par les paramètres configurables sysctl(8) suivants :

net.core.rmem_max
net.core.wmem_max
net.ipv4.tcp_rmem
net.ipv4.tcp_wmem

Les deux premiers paramètres configurables affectent la taille maximale de fenêtre TCP pour les applications qui tentent de contrôler directement la taille de la fenêtre TCP, en limitant la requête des applications à ces valeurs seulement. Les deux autres paramètres configurables affectent la taille de fenêtre TCP pour les applications qui laissent la fonction de réglage automatique de Linux se charger de cette tâche.

La valeur optimale de la taille de fenêtre dépend de votre situation particulière, mais le point de départ est le plus grand produit BDP (produit délai-bande passante) du ou des chemins sur lesquels le système doit envoyer des données. Dans ce cas, vous devez définir les paramètres configurables en procédant comme suit :

Assurez-vous de disposer de droits racines.
Obtenez les paramètres actuels du tampon. Enregistrez-les au cas où vous souhaiteriez annuler ces modifications.
```
sudo sysctl -a | grep mem
```
Définissez une variable d’environnement sur la nouvelle taille de fenêtre TCP que vous souhaitez utiliser :
```
MaxExpectedPathBDP=8388608
```
Définissez la taille maximale de la mémoire tampon de réception du système d'exploitation pour tous les types de connexions :
```
sudo sysctl -w net.core.rmem_max=$MaxExpectedPathBDP
```
Définissez la taille maximale de la mémoire tampon d'envoi du système d'exploitation pour tous les types de connexions :
```
sudo sysctl -w net.core.wmem_max=$MaxExpectedPathBDP
```
Définissez les paramètres de la mémoire tampon de réception TCP (tcp_rmem) :
```
sudo sysctl -w net.ipv4.tcp_rmem="4096 87380 $MaxExpectedPathBDP"
```
Le paramètre tcp_rmem prend en compte trois valeurs :
- Taille minimale du tampon de réception pouvant être allouée à un socket TCP. Dans cet exemple, la valeur est de 4096 octets.
- Taille par défaut du tampon de réception, qui remplace également la valeur /proc/sys/net/core/rmem_default utilisée par d'autres protocoles. Dans l'exemple, la valeur est de 87380 octets.
- Taille maximale de la mémoire tampon de réception pouvant être allouée à un socket TCP. Dans l'exemple, elle est définie sur la valeur définie précédemment (8388608 octets).
Définissez les paramètres de la mémoire tampon d'envoi TCP (tcp_wmem) :
```
sudo sysctl -w net.ipv4.tcp_wmem="4096 16384 $MaxExpectedPathBDP"
```
Le paramètre tcp_wmem prend en compte trois valeurs :
- Espace minimal du tampon d'envoi TCP disponible pour un socket TCP.
- Espace par défaut du tampon autorisé pour un socket TCP.
- Espace maximal du tampon d'envoi TCP.
Définissez les paramètres configurables de sorte que les connexions suivantes utilisent les valeurs que vous avez spécifiées :
```
sudo sysctl -w net.ipv4.route.flush=1
```

Pour conserver ces paramètres lors des redémarrages, ajoutez les commandes que vous avez définies précédemment au fichier /etc/sysctl.conf :

sudo bash -c 'cat << EOF >> /etc/sysctl.conf
net.core.rmem_max=8388608
net.core.wmem_max=8388608
net.ipv4.tcp_rmem=4096 87380 8388608
net.ipv4.tcp_wmem=4096 16384 8388608
net.ipv4.route.flush=1
EOF'

Tester le DAR avec une taille de fenêtre actualisée

Lorsque TCP a une taille de fenêtre suffisante pour utiliser le produit BDP, la situation est différente, comme indiqué dans le schéma suivant :

L'émetteur envoie une grande quantité de données à la fois et attend très peu de temps l’actualisation de la fenêtre.

La taille de la fenêtre TCP peut toujours être adaptée en fonction des ressources disponibles pour le processus impliqué et de l'algorithme TCP utilisé. Comme le montre le schéma, l'adaptation de fenêtre permet à une connexion d'aller bien au-delà de la taille de fenêtre de 65 Ko définie dans la spécification TCP d'origine.

Vous pouvez tester cela vous-même. Tout d'abord, assurez-vous d'avoir bien modifié la taille de la fenêtre TCP sur votre ordinateur local et sur un ordinateur distant en définissant les paramètres configurables sur les deux ordinateurs. Exécutez ensuite les commandes suivantes :

dd if=/dev/urandom of=sample.txt bs=1M count=1024 iflag=fullblock
scp sample.txt your_username@remotehost.com:/some/remote/directory

La première commande crée un fichier sample.txt de 1 Go contenant des données aléatoires. La seconde commande copie ce fichier de votre ordinateur local vers un ordinateur distant.

Notez le résultat de la commande scp sur la console, qui affiche la bande passante en Kbit/s. Vous devriez obtenir une différence considérable dans les résultats avant et après les modifications de la taille de la fenêtre TCP.

Étapes suivantes

Lisez l'article de blog sur les 5 étapes pour améliorer les performances du réseau Google Cloud.
Découvrez les produits de mise en réseau adaptables à l'échelle mondiale.
Apprenez-en davantage sur les niveaux de service réseau sur Google Cloud.
Découvrez comment évaluer les performances du réseau.