The Cable GuyRéglage automatique de la fenêtre de réception TCP
Joseph Davies
Bienvenue dans le premier article du Cable Guy de TechNet Magazine. Les habitués des articles parus sur le site Web TechNet savent déjà que nous abordons tous les types de problèmes réseau et nous poursuivrons cette tradition ici chaque mois. Si vous êtes nouveau et que vous cherchez une archive des articles précédents, visitez le site du Cable Guy.
Commençons par notre premier sujet : la fenêtre de réception TCP.
Le débit par des connexions TCP peut être limité par l'envoi et la réception d'applications, l'envoi et la réception d'implémentations de TCP et le chemin de transmission entre les homologues de TCP. Dans cet article, je vais décrire la fenêtre de réception TCP et son impact sur le débit TCP, l'utilisation de l'évolutivité de la fenêtre TCP et la nouvelle fonctionnalité de Réglage automatique de la fenêtre de réception dans Windows Vista™ qui optimise le débit TCP pour les données reçues.
La fenêtre de réception TCP
Les connexions TCP ont un certain nombre de caractéristiques importantes. Premièrement, elles représentent un circuit point-à-point logique entre deux protocoles de la couche application. TCP ne fournit pas un service de livraison un-à-plusieurs, il offre uniquement une livraison un-à-un.
Deuxièmement, les connexions TCP sont orientées connexion. Avant le transfert des données, deux processus de couche d'application doivent négocier formellement une connexion TCP à partir du processus d'établissement de connexion TCP. De même, les connexions TCP sont officiellement fermées après la négociation avec le processus d'arrêt de connexion TCP.
Troisièmement, les données fiables envoyées sur une connexion TCP sont ordonnées et un accusé de réception du destinataire est attendu. En l'absence d'un accusé de réception, le segment est retransmis. Au niveau du destinataire, les segments dupliqués sont supprimés et les segments arrivant dans le mauvais ordre sont remis dans le bon ordre.
Quatrièmement, les connexions TCP sont en duplex intégral. Pour chaque homologue TCP, la connexion TCP consiste en deux canaux logiques : un canal sortant et un canal entrant. L'en-tête TCP contient le numéro de séquence des données sortantes et un accusé de réception (ACK) des données entrantes.
De plus, TCP affiche les données passant par les canaux entrants et sortants logiques comme un flux continu d'octets. Le numéro de séquence et le numéro d'accusé de réception de chaque en-tête TCP sont définis dans les limites d'octets. TCP n'est pas conscient de limites d'enregistrement ou message dans le flux d'octets. Le protocole de la couche application doit fournir l'analyse correcte du flux d'octets entrants.
Pour limiter la quantité de données pouvant être envoyées simultanément et fournir un contrôle du flux côté réception, les homologues TCP utilisent une fenêtre. La fenêtre est la portée des données du flux d'octets que le destinataire autorise l'émetteur à envoyer. L'émetteur peut envoyer uniquement les octets du flux d'octets compris à l'intérieur de la fenêtre. La fenêtre suit le flux d'octets sortants de l'émetteur et le flux d'octets entrants du destinataire.
Pour un canal logique donné (une direction de la connexion TCP en duplex intégral) l'émetteur gère une fenêtre d'envoi et le destinataire gère une fenêtre de réception. Lorsqu'il n'y a pas de données ou de segments ACK en transit, les fenêtres d'envoi et de réception d'un canal logique correspondent. En d'autres termes, la portée des données dans le flux d'octets sortants que l'émetteur est autorisé à envoyer correspond à la portée des données dans le flux d'octets entrants que le destinataire peut recevoir. La figure 1 illustre cette relation d'envoi et réception.
Figure 1** Correspondance des fenêtres d'envoi et de réception **(Cliquer sur l'image pour l'agrandir)
Pour indiquer la taille de la fenêtre de réception, l'en-tête TCP contient un champ de fenêtre 16 bits. Lorsque le destinataire obtient des données, il renvoie des accusés de réception (ACK) à l'émetteur en indiquant les octets reçus. Dans chaque ACK, le champ Fenêtre indique le numéro d'octets restant dans la fenêtre de réception. Lorsque les données sont envoyées, qu'elles font l'objet d'un accusé de réception et qu'elles sont récupérées par l'application, les fenêtres d'envoi et de réception glissent vers la droite. La fenêtre de réception est la fenêtre qui contrôle la quantité de données non reconnues transmises par l'émetteur au destinataire.
Comme il peut y avoir des données de la fenêtre de réception qui n'ont pas encore été récupérées par l'application et des données qui ont été reçues mais pas reconnues, la fenêtre de réception TCP a une structure supplémentaire, comme illustré par la figure 2.
Figure 2** Types de données de la fenêtre de réception TCP **(Cliquer sur l'image pour l'agrandir)
Notez la différence entre les fenêtres de réception maximale et actuelle. La fenêtre de réception maximale a une taille fixe. La fenêtre de réception actuelle a une taille variable et correspond à la quantité restante de données que le destinataire autorise l'émetteur à envoyer. La taille de la fenêtre de réception actuelle est la valeur du champ Fenêtre indiquée dans les ACK renvoyés à l'émetteur et elle correspond à la différence entre la taille de la fenêtre de réception maximale et la quantité des données reçues et reconnues mais non récupérées par l'application.
Fenêtre de réception TCP et débit TCP
Pour optimiser le débit TCP (en supposant que le chemin de transmission est dépourvu d'erreurs), l'émetteur doit envoyer suffisamment de paquets pour remplir le canal logique situé entre l'émetteur et le destinataire. La capacité du canal logique peut être calculée par la formule suivante :
Capacity in bits = path bandwidth in bits per second * round-trip time (RTT) in seconds
La capacité est connue comme le produit bande passante/délai (BDP). Le canal peut être gros (bande passante élevée), fin (bande passante basse), court (RTT bas) ou long (élevé RTT) Les canaux qui sont gros et longs ont le BDP le plus élevé. Les chemins situés sur des satellites ou des réseaux étendus (WAN) d'entreprise qui comprennent des liaisons en fibre optique intercontinentaux sont des exemples de chemins de transmission à BDP élevé.
Augmentation des performances côté émetteur pour transmission à BDP élevé
La nouvelle fonctionnalité de réglage automatique de la fenêtre de réception offre des performances améliorées pour la réception de données sur des liaisons à BDP élevé, mais qu'en est-il des performances de l'émetteur ?
Les algorithmes existants qui empêchent un homologue TCP émetteur de submerger le réseau ralentissent le début et évitent la congestion. Ces algorithmes augmentent la fenêtre d'envoi (le nombre de segments que l'émetteur peut envoyer) lors du début de l'envoi de données à la connexion et au moment de la récupération après une perte de segment.
La lenteur du démarrage augmente la fenêtre d'envoi d'un segment TCP complet pour chaque segment d'accusé de réception (pour TCP dans Windows XP et Windows Server 2003) ou pour chaque segment reconnu (pour TCP dans Windows Vista et Windows Server « Longhorn »). L'élimination de la congestion augmente la fenêtre d'envoi d'un segment TCP complet pour chaque fenêtre de données complète reconnue.
Ces algorithmes conviennent pour les petits BDP et les petites tailles de fenêtre de réception. Cependant, lorsque vous avez une connexion TCP avec une fenêtre de réception de grande taille et un BDP élevé (par exemple avec une réplication des données entre deux serveurs situés sur une liaison WAN rapide et un temps d'aller-retour de 100 millisecondes), ces algorithmes n'augmentent pas la fenêtre de réception suffisamment vite pour utiliser pleinement la bande passante de la connexion.
Pour mieux utiliser la bande passante de connexions TCP dans ces situations, la pile TCP/IP nouvelle génération inclut Compound TCP (CTCP). CTCP augmente la fenêtre d'envoi d'une manière plus agressive pour les connexions avec de grandes tailles de fenêtres et des BDP élevés. CTCP tente d'optimiser le débit sur ces types de connexions en contrôlant les variations de délai et les pertes. Par ailleurs, CTCP s'assure que son comportement n'a pas d'impact négatif sur d'autres connexions TCP.
Les tests effectués en interne chez Microsoft ont révélé une forte réduction des temps de sauvegarde de fichiers (environ moitié moins) pour une connexion de 1 Gigabit par seconde avec un temps d'aller-retour de 50 millisecondes. Ces performances peuvent être encore meilleures avec des connexions ayant un BDP plus élevé. CTCP et le réglage automatique de la fenêtre de réception contribuent ensemble à une meilleure utilisation de la liaison et peuvent générer des gains de performance substantiels pour les connexions dotés de BDP élevés.
CTCP est activé par défaut sur les ordinateurs exécutant Windows Server « Longhorn » et désactivé par défaut sur les ordinateurs exécutant Windows Vista. Vous pouvez activer CTCP avec la commande « netsh interface tcp set global congestionprovider=ctcp ». Vous pouvez désactiver CTCP avec la commande « netsh interface tcp set global congestionprovider=none ».
La taille du champ Fenêtre dans l'en-tête TCP est de 16 bits, ce qui permet à un homologue TCP d'annoncer une taille de fenêtre de réception maximale de 65 535 octets. Vous pouvez calculer le débit approximatif pour une taille de fenêtre TCP donnée avec la formule suivante :
Throughput = TCP maximum receive windowsize / RTT
Par exemple, avec une fenêtre de réception de 65 535 octets, vous pouvez uniquement atteindre un débit approximatif de 5,24 mégabits par seconde (Mbits/s) sur un chemin ayant un RTT de 100 millisecondes, sans tenir compte de la bande passante réelle du chemin de transmission. Avec les chemins de transmission à BDP élevés d'aujourd'hui, la taille de fenêtre TCP conçue à l'origine devient un goulet d'étranglement du débit, même à sa valeur maximale.
Évolutivité de la fenêtre TCP
Pour que les tailles de fenêtres supérieures puissent prendre en charge les chemins de transmission haut débit, RFC 1323 (ietf.org/rfc/rfc1323.txt) définit une évolutivité de fenêtre qui permet à un destinataire d'avoir une taille de fenêtre supérieure à 65 535 octets. L'option Évolutivité de la fenêtre TCP comprend un facteur d'évolutivité de fenêtre qui, associé au champ Fenêtre de 16 bits dans l'en-tête TCP, peut augmenter la taille de la fenêtre de réception à un maximum d'1 Go environ. L'option Évolution de la fenêtre est envoyée uniquement dans les segments SYN (Synchronise) au cours du processus d'établissement de connexion. Les deux homologues TCP peuvent indiquer des facteurs d'évolutivité de fenêtre différents à utiliser pour leurs tailles de fenêtres de réception. En permettant à un émetteur d'envoyer plus de données sur une connexion, l'évolutivité de la fenêtre TCP permet aux noeuds TCP de mieux utiliser certains types de chemins de transmission dotés de BDP élevés.
Bien que la taille de la fenêtre de réception soit importante pour le débit TCP, la vitesse à laquelle l'application récupère les données accumulées dans la fenêtre de réception (le taux de récupération de l'application) constitue un autre facteur important pour déterminer le débit TCP optimal. Si l'application ne récupère pas les données, la fenêtre de réception commence à se remplir, ce qui force le destinataire à indiquer une taille de fenêtre actuelle inférieure. Dans les cas extrêmes, l'ensemble de la fenêtre de réception maximale est rempli, ce qui force le destinataire à indiquer une taille de fenêtre de 0 octet. Dans ce cas, l'émetteur doit arrêter d'envoyer des données jusqu'à ce que la fenêtre de réception se vide. Par conséquent, pour optimiser le débit TCP, la fenêtre de réception TCP pour une connexion doit être réglée sur une valeur reflétant à la fois le BDP du chemin de transmission de la connexion et le taux de récupération de l'application.
Même si vous pouviez déterminer correctement le BDP et le taux de récupération de l'application, ceux-ci peuvent changer. Le taux de BDP peut varier en fonction de la congestion sur le chemin de transmission et le taux de récupération de l'application peut varier en fonction du nombre de connexions sur lesquelles l'application reçoit des données.
La Fenêtre de réception dans Windows XP
Pour la pile TCP/IP dans Windows XP (et Windows Server® 2003), la taille de la fenêtre de réception maximale a un certain nombre d'attributs significatifs. Premièrement, la valeur par défaut se base sur la vitesse de liaison de l'interface d'envoi. La véritable valeur s'ajuste automatiquement sur les incréments de la taille de segment maximale (MSS) négociée pendant l'établissement de connexion TCP.
Deuxièmement, la taille de la fenêtre de réception maximale peut être configurée manuellement. Les valeurs de registre HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\TCPWindowSize et HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Interface\InterfaceGUID\TCPWindowSize peuvent être réglées sur un maximum de 65 535 octets (sans évolutivité de fenêtre) ou 1 073 741 823 (avec évolutivité de fenêtre).
Troisièmement, la taille de la fenêtre de réception maximale peut l'évolutivité de fenêtre. Vous pouvez activer l'évolutivité de fenêtre en réglant la valeur de registre HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts sur 1 ou 3. Par défaut, l'évolutivité de fenêtre est utilisée sur une connexion uniquement si le segment SYN reçu contient l'option d'évolutivité de fenêtre.
Pour finir, la taille de fenêtre de réception maximale peut être spécifiée par une application en utilisant l'option SO_RCVBUF de Windows Sockets lorsqu'une connexion est établie. Pour l'évolutivité de fenêtre, l'application doit spécifier une taille de fenêtre supérieure à 65 535 octets.
Malgré la prise en charge des fenêtres évolutives, la taille de la fenêtre de réception maximale dans Windows XP peut quand même limiter le débit parce qu'il y a une taille maximale fixe pour toutes les connexions TCP (sauf mention contraire dans l'application), ce qui peut augmenter le débit pour certaines connexions et le diminuer pour d'autres. De plus, la taille de la fenêtre de réception maximale fixe pour une connexion TCP ne varie pas en fonction des modifications du taux de récupération de l'application ou de la congestion sur le chemin de transmission.
Réglage automatique de la fenêtre de réception dans Windows Vista
Pour optimiser le débit TCP, en particulier pour les chemins de transmission dotés d'un BDP élevé, la pile TCP/IP nouvelle génération de Windows Vista (et la prochaine version de Windows Server, nom de code « Longhorn ») prend en charge le réglage automatique de la fenêtre de réception. Cette fonctionnalité détermine la taille de la fenêtre de réception optimale en mesurant le BDP et le taux de récupération de l'application et en adaptant la taille de la fenêtre au chemin de transmission en cours et aux conditions d'application.
Le réglage automatique de la fenêtre de réception active l'évolutivité de la fenêtre TCP par défaut, ce qui permet une taille de fenêtre de réception maximale de 16 Mo. Lorsque les données circulent sur la connexion, la pile TCP/IP nouvelle génération surveille la connexion, mesure son BDP et son taux de récupération de l'application actuels et ajuste la taille de la fenêtre de réception pour optimiser le débit. La pile TCP/IP nouvelle génération n'utilise plus la valeur de registre TCPWindowSize.
Le réglage automatique de la fenêtre de réception a plusieurs avantages. Il détermine automatiquement la taille de la fenêtre de réception optimale en fonction de la connexion. Dans Windows XP, la valeur de registre TCPWindowSize s'applique à toutes les connexions. Les applications n'ont plus besoin de spécifier des tailles de fenêtres TCP par le biais d'options Windows Sockets. Et les administrateurs informatiques n'ont plus besoin de configurer manuellement une taille de fenêtre de réception TCP pour des ordinateurs spécifiques.
Avec le réglage automatique de la fenêtre de réception, un homologue TCP Windows Vista indique généralement des tailles de fenêtre de réception bien supérieures à celles d'un homologue TCP Windows XP. Ceci permet à l'autre homologue TCP de remplir le canal de l'homologue TCP Windows Vista en envoyant plus de segments de données TCP sans avoir à attendre un ACK (en fonction du contrôle de congestion TCP). Pour un trafic réseau client typique, tel que des pages Web ou le courrier électronique, le serveur Web ou le serveur de messagerie pourra envoyer plus de données TCP plus rapidement à l'ordinateur client, ce qui entraîne une augmentation globale des performances réseau. Plus le BDP et le taux de récupération de l'application sont élevés, plus les performances augmentent.
L'impact sur le réseau est le suivant : un flux de paquets de données TCP, qui serait normalement expédié à un rythme plus bas et mesuré, est envoyé beaucoup plus vite, ce qui entraîne un plus grand pic d'utilisation du réseau pendant le transfert des données. Pour les ordinateurs équipés de Windows XP et Windows Vista exécutant le même transfert de données sur un canal gros et long, la même quantité de données est transférée. Cependant, le transfert de données de l'ordinateur équipé de Windows Vista est plus rapide en raison de la taille supérieure de la fenêtre de réception et de la capacité du serveur à remplir le canal reliant le serveur au client.
Étant donné que le réglage automatique de la fenêtre de réception augmentera l'utilisation par le réseau de chemins de transmission à BDP élevés, l'utilisation de la Qualité de Service (QoS) ou de limitation du taux d'envoi de l'application risque de devenir importante pour les chemins de transmission utilisant toutes les capacités ou presque. Pour répondre à cet éventuel besoin, Windows Vista prend en charge des paramètres de QoS basé sur les stratégies qui vous permettent de définir des taux de limitation pour le trafic envoyé selon l'adresse IP ou le port TCP. Pour plus d'informations, voir les ressources sur le QoS basé sur les stratégies.
Augmentation du débit TCP pour les réseaux à forte perte
Les réseaux à forte perte peuvent réduire considérablement le débit TCP à cause des pauses et retransmissions fréquentes. Les réseaux sans fil sont un exemple de réseaux à forte perte, notamment ceux basés sur IEEE 802.11, General Packet Radio Service (GPRS), ou Universal Mobile Telecommunications System (UMTS), qui peuvent avoir des pertes de paquets élevées en fonction des conditions du réseau, de l'atténuation des signaux, d'interférences électromagnétiques et du changement d'emplacement de l'ordinateur.
La pile TCP/IP nouvelle génération prend en charge les quatre RFC suivantes pour optimiser le débit dans les environnements à forte perte :
RFC 2582 : Modification NewReno de l'algorithme de récupération rapide de TCP
L'algorithme de récupération rapide, défini dans RFC 2001, est basé sur l'algorithme Reno, qui augmente la quantité de données qu'un émetteur peut envoyer lorsqu'un segment est retransmis en raison d'un événement de retransmission rapide. Bien que l'algorithme Reno fonctionne bien pour les segments perdus individuels, il ne marche pas aussi bien lorsqu'il y a plusieurs segments perdus. L'algorithme NewReno offre un débit plus rapide en modifiant la façon dont un émetteur peut augmenter sa vitesse d'envoi lors de la récupération rapide si plusieurs segments d'une fenêtre de données sont perdus et l'émetteur reçoit un accusé de réception partiel (un accusé de réception pour une partie uniquement des données effectivement reçues).
RFC 2883 : Extension de l'option d'accusé de réception sélectif (SACK, Selective Acknowledgement) pour TCP
SACK, défini dans RFC 2018, permet à un destinataire d'indiquer jusqu'à quatre blocs de non-contigus de données reçues en utilisant une option SACK TCP. La RFC 2883 définit une utilisation supplémentaire des champs dans l'option SACK TCP pour accuser réception des paquets dupliqués. Ainsi, l'émetteur peut déterminer lorsqu'il a retransmis un segment de façon inutile et ajuster son comportement pour empêcher de futures retransmissions inutiles. La diminution du nombre de retransmissions améliore le débit global.
RFC 3517 : Algorithme conservatif de récupération de perte basé sur SACK pour TCP
L'implémentation actuelle de TCP/IP dans Windows Server 2003 et Windows XP utilise les informations SACK uniquement dans le but de déterminer les segments TCP qui ne sont pas arrivés à destination. La RFC 3517 définit une méthode d'utilisation des informations SACK pour effectuer la récupération de perte lors de la réception d'accusés de réception dupliqués, remplaçant l'algorithme de récupération rapide le plus ancien lorsque l'option SACK est activée sur une connexion. La pile TCP/IP nouvelle génération conserve une trace des informations SACK en fonction de la connexion et contrôle les accusés de réception entrants et dupliqués pour effectuer une récupération plus rapide lorsque plusieurs segments ne sont pas reçus à destination.
RFC 4138 : Récupération F-RTO (Forward RTO-Recovery) : Algorithme pour la détection des fausses expirations de retransmission avec TCP et le protocole SCTP (Stream Control Transmission Protocol)
Des fausses retransmissions de segments TCP peuvent survenir avec une augmentation soudaine dans RTT, entraînant le début des expirations de retransmission (RTO) de segments précédemment envoyés et forçant TCP à commencer à les retransmettre. Si l'augmentation survient juste avant l'envoi d'une fenêtre complète de données, un émetteur peut retransmettre la fenêtre de données entière. L'algorithme F-RTO empêche la fausse retransmission de segments TCP avec le comportement suivant.
Lorsque le RTO expire pour plusieurs segments, TCP retransmet juste le premier segment. Lorsque le premier accusé de réception arrive, TCP commence à envoyer de nouveaux segments (si la taille de fenêtre indiquée le permet). Si l'accusé de réception suivant confirme les autres segments ayant expiré mais n'ayant pas été retransmis, TCP détermine que l'expiration était fausse et ne retransmet pas les autres segments expirés.
Lorsque des environnements présentent des augmentations soudaines et temporaires du temps RTT (lorsqu'un client sans fil passe d'un point d'accès à un autre, par exemple), l'algorithme F-RTO empêche toute retransmission inutile de segments et revient plus rapidement à sa fréquence d'envoi normale. L'utilisation des algorithmes de récupération de perte basés sur SACK et F-RTO convient mieux aux connexions utilisant des liaisons GPRS.
Joseph Daviesest rédacteur technique chez Microsoft et il enseigne et écrit sur le réseau Windows depuis 1992. Il a écrit cinq livres pour Microsoft Press et on lui doit les articles mensuels du Cable Guy de Technet.
© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.