Server TCP Window Scaling et optimisation du débit dans le centre de données

Serveur TCP Dans les centres de calcul, le window scaling est décisif pour le débit utilisable par connexion, surtout en cas de bande passante élevée et de RTT à deux chiffres. Je montre comment calculer la fenêtre de réception, la mettre à l'échelle de manière dynamique et réduire le goulot d'étranglement entre les deux fenêtres grâce à un réglage ciblé. Taille de la fenêtre et la latence.

Points centraux

Pour que l'article permette de s'orienter rapidement, je résume d'abord les principaux messages. Je me concentre sur la taille de la fenêtre, le RTT, le produit de la bande passante et du délai et les paramètres utiles du système. Chaque affirmation est directement liée à un débit de données reproductible. J'évite la théorie sans référence et je fournis des étapes applicables. Il en résulte un chemin clair allant du diagnostic à Tuning.

• Mise à l'échelle des fenêtres supprime la limite de 64 Ko et permet de créer de grandes fenêtres.
• RTT et la taille de la fenêtre déterminent le débit maximal (≈ Window/RTT).
• BDP indique la taille de fenêtre nécessaire pour une utilisation complète du lien.
• Tampon et l'auto-réglage des piles de l'OS entraînent des performances réelles.
• Multi-flux et les paramètres de protocole augmentent le transfert de données.

Pourquoi la taille des fenêtres et le RTT dictent le débit

Je calcule la limite supérieure par connexion avec la formule simple débit ≈ Fenêtre/RTT. Une fenêtre de 64 Ko et 50 ms de RTT fournissent environ 10 Mbps, même si la fibre optique permet 1 Gbps. Cet écart est particulièrement visible sur les longues distances et les chemins WAN. Plus la latence est grande, plus une petite fenêtre ralentit le transfert. Je donne donc la priorité à une taille de fenêtre de réception suffisamment grande, plutôt que d'acheter uniquement de la bande passante qui reste inutilisée. J'adresse ainsi la véritable vis de réglage dans le Pile TCP.

Limites de la fenêtre TCP classique

La fenêtre 16 bits d'origine limite la valeur à 65 535 octets et fixe ainsi une limite dure pour débit avec un RTT élevé. Sur un réseau local, cela se remarque rarement, mais sur les continents, le taux chute drastiquement à des Mbit/s à un ou deux chiffres. Un exemple le montre clairement : 64 Ko avec un RTT de 100 ms ne donnent qu'environ 5 Mbit/s. Ce n'est pas suffisant pour les sauvegardes, la réplication ou les transferts de fichiers volumineux. Je résous cette limite en appliquant systématiquement le window scaling. active et que j'examine la négociation.

Comment fonctionne le TCP Window Scaling

Avec l'option Échelle de fenêtre j'agrandis la fenêtre logique à l'aide d'un exposant (0-14) qui est négocié lors du handshake SYN. La fenêtre effective résulte de Header-Window × 2^Scale et peut ainsi atteindre des tailles de l'ordre du gigaoctet. L'essentiel est que les deux points finaux acceptent l'option et qu'aucun composant intermédiaire ne la filtre. Je vérifie le handshake dans Wireshark et je fais attention à l'option dans SYN et SYN/ACK. Si elle est absente, la connexion retombe à 64 Ko, ce qui Débit immédiatement limitée.

Taille dynamique des fenêtres dans les systèmes actuels

Les noyaux Linux modernes et les serveurs Windows adaptent le RWIN de manière dynamique et atteignent plusieurs mégaoctets dans des conditions favorables. Sous Linux, je contrôle le comportement via net.ipv4.tcp_rmem, net.ipv4.tcp_wmem et net.ipv4.tcp_window_scaling. Sous Windows, je vérifie avec netsh int tcp show global, si l'auto-réglage est actif. Je m'assure qu'il y a suffisamment de tampons des deux côtés pour que la croissance ne s'arrête pas aux valeurs maximales. Je profite ainsi des avantages de la mise à l'échelle automatique en Fonctionnement productif de.

Estimer correctement le BDP : Quelle doit être la taille de la fenêtre ?

Le produit de délai de bande passante (BDP) me fournit la taille cible pour la fenêtre TCP : bande passante × RTT. Je fixe la fenêtre de réception au moins à cet ordre de grandeur afin d'utiliser la ligne au maximum de ses capacités. Sans une mémoire tampon suffisante, la connexion reste bien en deçà de la bande passante nominale. Le tableau suivant montre des combinaisons typiques de RTT et de bande passante avec les tailles de fenêtre requises et la limite d'une fenêtre de 64 Ko. Je peux ainsi voir d'un coup d'œil l'intensité d'une petite fenêtre à WAN-de l'Europe.

RTT	Bande passante	BDP (Mbits)	Fenêtre minimale (MB)	Débit avec 64 Ko
20 ms	1 Gbit/s	20	≈ 2,5	≈ 26 Mbit/s
50 ms	1 Gbit/s	50	≈ 6,25	≈ 10 Mbit/s
100 ms	1 Gbit/s	100	≈ 12,5	≈ 5 Mbit/s
50 ms	10 Gbit/s	500	≈ 62,5	≈ 10 Mbit/s

Tuning pratique : de la mesure à l'ajustement

Je commence par prendre des mesures : ping et traceroute fournissent les RTT, iperf3 mesure les taux d'entrée et de sortie et Wireshark montre le négocié Mise à l'échelle dans le handshake. Si la fenêtre reste à 64 Ko dans la trace, je recherche les périphériques qui filtrent ou modifient les options. Je contrôle la conformité des pare-feux, des passerelles VPN et des équilibreurs de charge avec la RFC1323. Si la négociation convient, je vérifie les limites de la mémoire tampon et les limites maximales d'auto-réglage du système d'exploitation. En outre, j'évalue le choix de l'algorithme de contrôle de congestion, car sa réaction aux pertes et à la latence reflète la situation réelle. Débit Je résume les détails dans l'article Contrôle de la congestion TCP ensemble.

Choisir judicieusement les tampons de réception et d'envoi

Je m'appuie sur mon expérience pour le dimensionnement de la mémoire tampon. BDP et fixe les valeurs maximales de manière généreuse, mais contrôlée. Sous Linux, j'ajuste net.ipv4.tcp_rmem et net.ipv4.tcp_wmem (respectivement minimum/défaut/maximum) et garde une marge de manœuvre pour les longues distances. Sous Windows, je vérifie les niveaux d'auto-réglage et je documente les changements dans la pile TCP. Important : les mémoires tampon plus importantes nécessitent de la RAM, c'est pourquoi j'évalue le nombre et le type de mes connexions à forte charge. J'approfondis l'arrière-plan et des exemples sur le choix correct de la mémoire tampon dans l'article "La mémoire tampon". Réglage du tampon de socket, Le projet a été lancé en 2008 avec le soutien de la Commission européenne, qui a rendu tangibles les relations entre les tampons, le RWIN et la latence.

Parallélisation : utiliser plusieurs flux TCP de manière ciblée

Même avec une grande fenêtre, j'obtiens souvent plus dans la pratique en utilisant plusieurs flux en parallèle. De nombreux outils de sauvegarde, téléchargeurs ou solutions de synchronisation le font déjà par défaut. Grâce à la parallélisation, je contourne les limites per-connexion dans les boîtes intermédiaires et je lisse les fluctuations des différents flux. Je segmente les transferts par fichiers ou par blocs et je définis des valeurs de concordance raisonnables. Je répartis ainsi les risques et gagne des points de pourcentage supplémentaires. Bande passante dehors.

Ajuster finement les niveaux de protocole et d'application

Tous les logiciels n'utilisent pas de grandes Fenêtre efficace, car les confirmations supplémentaires ou les petites tailles de blocs ralentissent le transfert de données. J'augmente la taille des blocs, j'active le pipelining et j'établis des requêtes parallèles si l'application le permet. Les versions SMB modernes, les piles HTTP contemporaines et les moteurs de sauvegarde optimisés en profitent de manière mesurable. Je vérifie également le TLS-Offloading, le MSS-Clamping et les Jumbo-Frames, si l'ensemble de la chaîne les supporte proprement. Ces vis de réglage complètent le window scaling et soulèvent le réel Débit sur.

Comprendre le réglage automatique : Limites, heuristiques et valeurs par défaut utiles

Le tuning automobile ne s'improvise pas. Sous Linux, outre les tcp_rmem/tcp_wmem avant tout net.core.rmem_max et net.core.wmem_max la limite supérieure par socket. Des valeurs telles que 64-256 Mo sont recommandées pour les transferts WAN à haut débit. BDP-sont courantes. J'active net.ipv4.tcp_moderate_rcvbuf=1, pour que le noyau démarre progressivement la fenêtre de réception, et vérifiez que net.ipv4.tcp_adv_win_scale, L'option "Taille de la fenêtre" détermine le degré d'agressivité avec lequel les mémoires tampons libres sont converties en taille de fenêtre. tcp_timestamps et SAC je les garde actives, car elles ciblent les retransmissions et sont indispensables avec de grandes fenêtres.

Sous Windows, j'observe le comportement avec netsh int tcp show global et netsh int tcp show heuristics. Je règle généralement le niveau de réglage de la voiture sur normal et désactive les heuristiques qui ralentissent inutilement la croissance des fenêtres pour les chemins identifiés comme „lien lent“. Important dans les deux mondes : Les applications qui sont explicitement SO_RCVBUF/SO_SNDBUF peuvent ralentir efficacement l'auto-réglage. C'est pourquoi je vérifie si les processus du serveur (par exemple les proxies, les démons de transfert) présentent de tels dépassements et je les adapte.

Analyse de la trace : ce que je vérifie dans le handshake et le flux de données

Dans Wireshark, je valide dans SYN/SYN-ACK à côté de Échelle de fenêtre également SACK Autorisé, Timestamps et le MSS. Dans le flux de données, je regarde „Bytes in flight“, „TCP Window Size value“ et „Calculated Window Size“. Si la fenêtre calculée reste vide malgré une rmem plat, bloquent des limites ou l'application est application-limited. J'utilise également les graphes de flux TCP (Time-Sequence, Window Scaling) pour voir si la fenêtre s'agrandit de manière dynamique et si les retransmissions ou les paquets hors ordre annulent l'effet.

MTU, MSS et Jumbo-Frames : combien ils rapportent vraiment

Les grandes fenêtres n'ont d'effet que si le pipeline est rempli efficacement. Je vérifie donc le MTU effectif le long du chemin. Avec lien ip et ethtool j'identifie des limites locales, avec ping -M do -s je teste Path-MTU. Si PMTUD tombe en panne, j'active sous Linux net.ipv4.tcp_mtu_probing=1 ou mettre en place un clampage MSS judicieux sur les appareils de périphérie afin d'éviter la fragmentation. Les trames Jumbo (9000) sont intéressantes au sein d'une structure configurée de manière homogène, elles réduisent la charge de l'unité centrale et augmentent les performances. Goodput. Par contre, sur des segments de chemin hétérogènes ou WAN, je donne la priorité à un PMTUD propre et à des valeurs MSS cohérentes plutôt qu'à une augmentation brute du MTU.

Pertes, ECN et gestion des files d'attente

Dans le cas de grandes fenêtres, de faibles taux de perte de paquets suffisent à faire baisser massivement le débit réel. Je vérifie donc activement si ECN est pris en charge et s'il n'y a pas de nettoyage le long du chemin, et je combine cela avec AQM (par exemple FQ-CoDel) sur les interfaces de périphérie. Cela réduit la Délai de mise en file d'attente et empêche le bufferbloat sans garder la fenêtre artificiellement petite. Sous Linux, des systèmes modernes de détection des pertes comme RACK/TLP m'aident à fermer Tails plus rapidement. Dans les environnements avec des rafales fréquentes, je mise sur un contrôle de congestion compatible avec le pacing (par exemple CUBIC avec des limites de file d'attente d'octets ou BBR), mais je continue à veiller à ce que la fenêtre de réception soit suffisamment grande - même BBR ne peut pas fournir sans un RWIN adéquat.

Vue du serveur et de l'application : utiliser les options de socket en connaissance de cause

De nombreux processus de serveur définissent des tailles de buffer difficiles et limitent ainsi la croissance. Je vérifie explicitement les valeurs de démarrage et de pic avec ss -ti (Linux) et observe skmem/rcv_space. Au niveau de l'application, j'ajuste la taille des blocs et des enregistrements, je désactive Nagle (TCP_NODELAY) uniquement lorsque la latence par message est plus critique que le débit, et je réduis les effets de retard ACK en augmentant la taille des unités d'envoi. Pour les transferts de fichiers, j'utilise sendfile() ou des mécanismes de copie zéro, ainsi que des E/S asynchrones, afin que l'espace utilisateur ne devienne pas un goulot d'étranglement.

Mise à l'échelle à 10/25/40/100G : CPU, offloads et multi-queues

Les grandes fenêtres sollicitent l'hôte. Je m'assure que TSO/GSO et GRO/LRO sont actifs pour que le système gère efficacement les grands segments. Avec RSS/Multiqueue, je répartis les flux sur plusieurs cœurs, j'adapte l'affinité IRQ aux topologies NUMA et j'observe la charge SoftIRQ. Du côté de l'appareil, j'ajuste les tampons circulaires et le coalesçage des interruptions pour que l'hôte ne soit pas pris dans une tempête d'interruptions. Tout cela permet d'éviter que la mise à l'échelle des fenêtres ne se heurte aux limites de l'unité centrale et que les taux atteints restent reproductibles.

Chemin d'accès étape par étape : Du débit cible à la configuration

• Définir l'objectif : débit souhaité et RTT mesuré (par exemple 5 Gbit/s à 40 ms).
• BDP calculer : 5 Gbit/s × 0,04 s = 200 Mbit ≈ 25 Mo fenêtre.
• Définir les limites de Linux : sysctl -w net.core.rmem_max=268435456, net.core.wmem_max=268435456, net.ipv4.tcp_rmem="4096 87380 268435456", net.ipv4.tcp_wmem="4096 65536 268435456", net.ipv4.tcp_moderate_rcvbuf=1.
• Vérifier Windows : netsh int tcp show global; Tuning automobile normal, ne limitant pas les heuristiques.
• Valider le handshake : Wireshark - Window Scale, MSS, SACK/timestamps disponibles.
• Sauvegarder MTU/MSS : PMTUD fonctionnel ou MSS-clamping le long du chemin.
• Définir le contrôle de la congestion et l'AQM : CUBIC/BBR adapté au profil ; ECN/AQM actif sur Edge.
• Avec iperf3 vérifier les données : flux unique et flux multiple (-P), avec/sans TLS/application.
• Vérifier la mémoire tampon de l'application : aucune petite SO_RCVBUF/SO_SNDBUF Définir, augmenter la taille des blocs.

Les pièges typiques et les contrôles rapides

Je tombe souvent sur des pare-feux ou des routeurs qui Options dans l'en-tête TCP ou les rejeter. Les chemins asymétriques aggravent le problème, car l'aller et le retour passent par des politiques différentes. Une normalisation TCP agressive dans les routeurs d'accès détruit également la négociation correcte. Des tampons et des délais d'attente trop serrés entraînent de longues phases de récupération en cas de pertes. Je teste les modifications dans des fenêtres isolées, j'observe les retransmissions et j'ajuste progressivement pour que les Stabilité est préservée.

Contexte de l'hébergement et des centres de données

Dans les configurations de production, de nombreux clients partagent le même Infrastructure, C'est pourquoi l'utilisation efficace par connexion compte. Je profite des topologies Leaf-Spine, des chemins est-ouest courts et de suffisamment de liaisons montantes. Des algorithmes modernes de contrôle des congestions, une gestion propre des files d'attente et des règles de qualité de service robustes rendent les résultats reproductibles. Je planifie la taille des fenêtres et des tampons en tenant compte des pics de charge et des sessions parallèles. Ainsi, les performances restent cohérentes et l'effet de Mise à l'échelle des fenêtres arrive à tous les services.

Suivi et optimisation continue

Je mesure régulièrement avec iperf3 entre les sites, suit le RTT, la gigue, les retransmissions et les Goodput. Les données de flux et sFlow/NetFlow m'aident à reconnaître à temps les modèles dans le trafic. En cas d'anomalies, je vérifie les pertes de paquets, car même de faibles taux réduisent fortement le débit. Analyser les pertes de paquets ensemble. Je gère des tableaux de bord de séries chronologiques pour que les ruptures de tendance soient immédiatement visibles. Ainsi, mon réglage reste efficace et je réagis aux modifications des chemins, des politiques ou des profils de charge avant qu'elles ne se produisent. Utilisateur le sentir.

Un bref résumé de la pratique

Grandes fenêtres via Mise à l'échelle des fenêtres, Les tampons appropriés et un handshake bien négocié placent le levier au bon endroit. Je calcule le BDP, je mesure le RTT réel et je définis les valeurs maximales de manière à ce que l'auto-réglage puisse se développer. Ensuite, je vérifie les paramètres du protocole et je fais appel à la parallélisation si nécessaire. Si le débit n'est pas à la hauteur des attentes, je recherche de manière ciblée des boîtes intermédiaires qui filtrent les options et j'optimise le contrôle de la congestion ainsi que le comportement de la file d'attente. J'exploite ainsi la capacité disponible. Bande passante Je peux ainsi me passer de mises à niveau matérielles coûteuses qui ne résolvent pas le véritable problème.