Optimisation des performances TCP à l’aide de TCP Nile
TCP utilise les techniques d’optimisation et les stratégies (ou algorithmes) de contrôle de la congestion suivantes pour éviter la congestion du réseau dans la transmission des données.
Stratégies de lutte contre la congestion
Le protocole TCP (Transmission Control Protocol) a longtemps été utilisé pour établir et gérer les connexions Internet, gérer les erreurs de transmission et connecter facilement des applications Web avec des périphériques clients. Mais le trafic réseau est devenu plus difficile à contrôler, car la perte de paquets ne dépend pas seulement de la congestion dans le réseau, et la congestion ne provoque pas nécessairement la perte de paquets. Par conséquent, pour mesurer la congestion, un algorithme TCP doit se concentrer à la fois sur la perte de paquets et la bande passante.
Algorithme NILE
Citrix Systems a développé un nouvel algorithme de contrôle de la congestion-control, NILE, un algorithme d’optimisation TCP conçu pour les réseaux à grande vitesse tels que LTE, LTE avancé et 3G. Le Nil répond aux défis uniques causés par la décoloration, les pertes aléatoires ou congestives, les retransmissions des couches de liaison et l’agrégation des porteurs.
L’algorithme NILE :
- Base les estimations de latence en file d’attente sur des mesures de temps aller-retour.
- Utilise une fonction congestion-fenêtre-augmentation inversement proportionnelle à la latence de la file d’attente mesurée. Cette méthode permet d’approcher le point de congestion du réseau plus lentement que la méthode TCP standard, et réduit les pertes de paquets pendant la congestion.
- Peut distinguer entre perte aléatoire et perte basée sur la congestion sur le réseau en utilisant la latence estimée de la file d’attente.
Les fournisseurs de services de télécommunication peuvent utiliser l’algorithme NILE dans leur infrastructure TCP pour :
- Optimiser les réseaux mobiles et longue distance : l’algorithme NILE atteint un débit supérieur par rapport au TCP standard. Cette fonctionnalité est particulièrement importante pour les réseaux mobiles et longue distance.
- Diminution de la latence perçue par l’application et amélioration de l’expérience de l’abonné — L’algorithme du Nil utilise les informations de perte de paquets pour déterminer si la taille de la fenêtre de transmission doit être augmentée ou diminuée, et utilise les informations de retard de mise en file d’attente pour déterminer la taille de l’incrément ou du décrément. Ce paramètre dynamique de la taille de la fenêtre de transmission diminue la latence de l’application sur le réseau.
Pour configurer la prise en charge de NILE à l’aide de l’interface de ligne de commande
À l’invite de commandes, tapez ce qui suit :
set ns tcpProfile <name> [-flavor NILE]
<!--NeedCopy-->
Configuration de la prise en charge de NILE à l’aide de l’utilitaire de configuration
- Accédez à Système > Profils > Profils TCP et cliquez sur Profils TCP .
- Dans la liste déroulante TCP Flavor, sélectionnez NILE .
Exemple :
set ns tcpProfile tcpprofile1 -flavor NILE
<!--NeedCopy-->
Algorithme de récupération de taux proportionnel (PRR)
Les mécanismes TCP Fast Recovery réduisent la latence web causée par les pertes de paquets. Le nouvel algorithme PRR (Proportional Rate Recovery) est un algorithme de récupération rapide qui évalue les données TCP lors d’une récupération de perte. Il est modelé après la réduction de la moitié de la vitesse, en utilisant la fraction appropriée à la fenêtre cible choisie par l’algorithme de contrôle de la congestion. Il minimise le réglage de la fenêtre, et la taille réelle de la fenêtre à la fin de la récupération est proche du seuil de démarrage lent (ssthresh).
TCP Ouverture rapide (TFO)
TCP Fast Open (TFO) est un mécanisme TCP qui permet un échange de données rapide et sûr entre un client et un serveur pendant la prise de main initiale de TCP. Cette fonctionnalité est disponible en tant qu’option TCP dans le profil TCP lié à un serveur virtuel d’une appliance Citrix ADC. TFO utilise un cookie TCP Fast Open (un cookie de sécurité) que l’appliance Citrix ADC génère pour valider et authentifier le client initiant une connexion TFO au serveur virtuel. En utilisant le mécanisme TFO, vous pouvez réduire la latence réseau d’une application du temps nécessaire pour un aller-retour complet, ce qui réduit considérablement le retard subi dans les transferts TCP courts.
Fonctionnement de TFO
Lorsqu’un client tente d’établir une connexion TFO, il inclut un cookie TCP Fast Open avec le segment SYN initial pour s’authentifier. Si l’authentification réussit, le serveur virtuel de l’appliance Citrix ADC peut inclure des données dans le segment SYN-ACK même s’il n’a pas reçu le segment ACK final de la poignée de main à trois voies. Cela permet d’économiser jusqu’à un aller-retour complet par rapport à une connexion TCP normale, ce qui nécessite une poignée de main à trois voies avant d’échanger des données.
Un client et un serveur principal effectuent les étapes suivantes pour établir une connexion TFO et échanger des données en toute sécurité lors de la liaison TCP initiale.
- Si le client ne dispose pas d’un cookie TCP Fast Open pour s’authentifier, il envoie une demande Fast Open Cookie dans le paquet SYN au serveur virtuel sur l’appliance Citrix ADC.
- Si l’option TFO est activée dans le profil TCP lié au serveur virtuel, l’appliance génère un cookie (en chiffrant l’adresse IP du client sous une clé secrète) et répond au client avec un SYN-ACK qui inclut le cookie d’ouverture rapide généré dans un champ d’option TCP.
- Le client met en cache le cookie pour les futures connexions TFO au même serveur virtuel sur l’appliance.
- Lorsque le client tente d’établir une connexion TFO au même serveur virtuel, il envoie SYN qui inclut le cookie d’ouverture rapide mis en cache (en tant qu’option TCP) ainsi que des données HTTP.
- L’appliance Citrix ADC valide le cookie et, si l’authentification réussit, le serveur accepte les données du paquet SYN et accuse réception de l’événement avec un SYN-ACK, un cookie TFO et une réponse HTTP.
Remarque : Si l’authentification du client échoue, le serveur supprime les données et reconnaît l’événement uniquement avec un SYN indiquant un délai d’expiration de session.
- Côté serveur, si l’option TFO est activée dans un profil TCP lié à un service, l’appliance Citrix ADC détermine si le cookie TCP Fast Open est présent dans le service auquel il tente de se connecter.
- Si le cookie TCP Fast Open n’est pas présent, l’appliance envoie une demande de cookie dans le paquet SYN.
- Lorsque le serveur principal envoie le cookie, l’appliance stocke le cookie dans le cache d’informations du serveur.
- Si l’appliance dispose déjà d’un cookie pour la paire IP de destination donnée, il remplace l’ancien cookie par le nouveau.
- Si le cookie est disponible dans le cache d’informations du serveur lorsque le serveur virtuel tente de se reconnecter au même serveur principal en utilisant la même adresse SNIP, l’appliance combine les données du paquet SYN avec le cookie et les envoie au serveur principal.
- Le serveur principal reconnaît l’événement avec des données et un SYN.
Remarque : si le serveur reconnaît l’événement avec uniquement un segment SYN, l’appliance Citrix ADC renoue immédiatement le paquet de données après avoir supprimé le segment SYN et les options TCP du paquet d’origine.
Configuration de TCP Fast Open
Pour utiliser la fonction TCP Fast Open (TFO), activez l’option TCP Fast Open dans le profil TCP approprié et définissez le paramètre TFO Cookie Timeout sur une valeur correspondant aux exigences de sécurité de ce profil.
Pour activer ou désactiver TFO à l’aide de la ligne de commande
À l’invite de commandes, tapez l’une des commandes suivantes pour activer ou désactiver TFO dans un profil nouveau ou existant.
Remarque : La valeur par défaut est DISABLED.
add tcpprofile <TCP Profile Name> - tcpFastOpen ENABLED | DISABLED
set tcpprofile <TCP Profile Name> - tcpFastOpen ENABLED | DISABLED
unset tcpprofile <TCP Profile Name> - tcpFastOpen
<!--NeedCopy-->
Exemples :
add tcpprofile Profile1 – tcpFastOpen Set tcpprofile Profile1 – tcpFastOpen Enabled unset tcpprofile Profile1 – tcpFastOpen
Pour définir la valeur du délai d’expiration du cookie TCP Fast Open à l’aide de l’interface de ligne de commande
À l’invite de commandes, tapez :
set tcpparam –tcpfastOpenCookieTimeout <Timeout Value>
<!--NeedCopy-->
Exemple :
set tcpprofile –tcpfastOpenCookieTimeout 30secs
<!--NeedCopy-->
Pour configurer le TCP Fast Open à l’aide de l’interface graphique
- Accédez à Configuration > Système > Profils, puis cliquez sur Modifier pour modifier un profil TCP.
- Sur la page Configurer le profil TCP, activez la case à cocher TCP Fast Open.
- Cliquez sur OK, puis sur Terminé.
Pour configurer la valeur de délai d’expiration TCP Fast Cookie à l’aide de l’interface graphique
Accédez à Configuration > Système > Paramètres > Modifier les paramètres TCP, puis la page Configurer les paramètres TCP pour définir la valeur de délai d’expiration du cookie TCP Fast Open.
TCP Hystart
Un nouveau paramètre de profil TCP, hystart, active l’algorithme Hystart, qui est un algorithme de démarrage lent qui détermine dynamiquement un point sûr auquel se terminer (ssthresh). Il permet une transition vers l’évitement de la congestion sans lourdes pertes de paquets. Ce nouveau paramètre est désactivé par défaut.
Si la congestion est détectée, Hystart entre dans une phase d’évitement de congestion. En l’activant, vous obtenez un meilleur débit dans les réseaux à grande vitesse avec une forte perte de paquets. Cet algorithme permet de maintenir une bande passante proche du maximum lors du traitement des transactions. Il peut donc améliorer le débit.
Configuration de TCP Hystart
Pour utiliser la fonction Hystart, activez l’option Hystart cubique dans le profil TCP approprié.
Pour configurer Hystart à l’aide de l’interface de ligne de commande (CLI)
À l’invite de commandes, tapez l’une des commandes suivantes pour activer ou désactiver Hystart dans un profil TCP nouveau ou existant.
add tcpprofile <profileName> -hystart ENABLED
set tcpprofile <profileName> -hystart ENABLED
unset tcprofile <profileName> -hystart
<!--NeedCopy-->
Exemples :
add tcpprofile Profile1 – tcpFastOpen
Set tcpprofile Profile1 – tcpFastOpen Enabled
unset tcpprofile Profile1 – tcpFastOpen
<!--NeedCopy-->
Pour configurer la prise en charge d’Hystart à l’aide de l’interface graphique
- Accédez à Configuration > Système > Profils > et cliquez sur Modifier pour modifier un profil TCP.
- Sur la page Configurer le profil TCP, activez la case à cocher Hystart cubique.
- Cliquez sur OK, puis sur Terminé.
Techniques d’optimisation
TCP utilise les techniques et méthodes d’optimisation suivantes pour des contrôles de flux optimisés.
Sélection de profil TCP basée sur des stratégies
Aujourd’hui, le trafic réseau est plus diversifié et gourmand en bande passante que jamais. Avec l’augmentation du trafic, l’effet de la qualité de service (QoS) sur les performances TCP est significatif. Pour améliorer la qualité de service, vous pouvez désormais configurer des stratégies AppQoE avec différents profils TCP pour différentes classes de trafic réseau. La stratégie AppQoE classe le trafic d’un serveur virtuel pour associer un profil TCP optimisé pour un type de trafic particulier, tel que 3G, 4G, LAN ou WAN.
Pour utiliser cette fonctionnalité, créez une action de stratégie pour chaque profil TCP, associez une action aux stratégies AppQoE et associez les stratégies aux serveurs virtuels d’équilibrage de charge.
Configuration de la sélection de profils TCP basée sur des stratégies
La configuration de la sélection de profils TCP basée sur des stratégies consiste en les tâches suivantes :
- Activation d’AppQoE. Avant de configurer la fonctionnalité de profil TCP, vous devez activer la fonctionnalité AppQoE.
- Ajout d’une action AppQoE. Après avoir activé la fonctionnalité AppQoE, configurez une action AppQoE avec un profil TCP.
- Configuration de la sélection de profils TCP basée sur AppQoE. Pour implémenter la sélection de profil TCP pour différentes classes de trafic, vous devez configurer des stratégies AppQoE avec lesquelles votre appliance Citrix ADC peut distinguer les connexions et lier l’action AppQoE correcte à chaque stratégie.
- Liaison de la stratégie AppQoE au serveur virtuel. Une fois que vous avez configuré les stratégies AppQoE, vous devez les lier à un ou plusieurs serveurs virtuels d’équilibrage de charge, de commutation de contenu ou de redirection de cache.
Configuration à l’aide de l’interface de ligne de commande
Pour activer AppQoE à l’aide de l’interface de ligne de commande :
À l’invite de commandes, tapez les commandes suivantes pour activer la fonctionnalité et vérifier qu’elle est activée :
enable ns feature appqoe
show ns feature
<!--NeedCopy-->
Pour lier un profil TCP lors de la création d’une action AppQoE à l’aide de l’interface de ligne de commande
À l’invite de commandes, tapez la commande d’action AppQoE suivante avec l’option tcpprofiletobind.
Liaison d’un profil TCP :
add appqoe action <name> [-priority <priority>] [-respondWith ( ACS | NS ) [<CustomFile>] [-altContentSvcName <string>] [-altContentPath <string>] [-maxConn <positive_integer>] [-delay <usecs>]] [-polqDepth <positive_integer>] [-priqDepth <positive_integer>] [-dosTrigExpression <expression>] [-dosAction ( SimpleResponse |HICResponse )] [-tcpprofiletobind <string>]
show appqoe action
<!--NeedCopy-->
Pour configurer une stratégie AppQoE à l’aide de l’interface de ligne de commande
À l’invite de commandes, tapez :
add appqoe policy <name> -rule <expression> -action <string>
<!--NeedCopy-->
Pour lier une stratégie AppQoE à des serveurs virtuels d’équilibrage de charge, de redirection de cache ou de commutation de contenu à l’aide de l’interface de ligne de commande
À l’invite de commandes, tapez :
bind cs vserver cs1 -policyName <appqoe_policy_name> -priority <priority>
bind lb vserver <name> - policyName <appqoe_policy_name> -priority <priority>
bind cr vserver <name> -policyName <appqoe_policy_name> -priority <priority>
<!--NeedCopy-->
Exemple :
add ns tcpProfile tcp1 -WS ENABLED -SACK ENABLED -WSVal 8 -nagle ENABLED -maxBurst 30 -initialCwnd 16 -oooQSize 15000 -minRTO 500 -slowStartIncr 1 -bufferSize 4194304 -flavor BIC -KA ENABLED -sendBuffsize 4194304 -rstWindowAttenuate ENABLED -spoofSynDrop ENABLED -dsack enabled -frto ENABLED -maxcwnd 4000000 -fack ENABLED -tcpmode ENDPOINT
add appqoe action appact1 -priority HIGH -tcpprofile tcp1
add appqoe policy apppol1 -rule "client.ip.src.eq(10.102.71.31)" -action appact1
bind lb vserver lb2 -policyName apppol1 -priority 1 -gotoPriorityExpression END -type REQUEST
bind cs vserver cs1 -policyName apppol1 -priority 1 -gotoPriorityExpression END -type REQUEST
<!--NeedCopy-->
Configuration du profilage TCP basé sur une stratégie à l’aide de l’interface graphique
Pour activer AppQoE à l’aide de l’interface graphique
- Accédez à Système > Paramètres.
- Dans le volet d’informations, cliquez sur Configurer les fonctionnalités avancées.
- Dans la boîte de dialogue Configurer les fonctionnalités avancées, activez la case à cocher AppQoE .
- Cliquez sur OK.
Pour configurer la stratégie AppQoE à l’aide de l’interface graphique
- Accédez à App-Expert > AppQoE > Actions .
- Dans le volet d’informations, effectuez l’une des opérations suivantes :
- Pour créer une action, cliquez sur Ajouter.
- Pour modifier une action existante, sélectionnez-la, puis cliquez sur Modifier.
-
Dans l’écran Créer une action AppQoE ou Configurer une action AppQoE, tapez ou sélectionnez des valeurs pour les paramètres. Le contenu de la boîte de dialogue correspond aux paramètres décrits dans « Paramètres pour configurer l’action AppQoE » comme suit (un astérisque indique un paramètre requis) :
- Name—name
- Type d’action—respondWith
- Priorité—priority
- Profondeur de la file d’attente des stratégies—polqDepth
- Profondeur de file d’attente—priqDepth
- Action DOS—dosAction
- Cliquez sur Créer.
Pour lier la stratégie AppQoE à l’aide de l’interface graphique
- Accédez à Gestion du trafic > Équilibrage de charge > Serveurs virtuels, sélectionnez un serveur, puis cliquez sur Modifier.
- Dans la section Stratégies et cliquez sur (+) pour lier une stratégie AppQoE.
- Dans le curseur Stratégies, procédez comme suit :
- Sélectionnez un type de stratégie comme AppQoE dans la liste déroulante.
- Sélectionnez un type de trafic dans la liste déroulante.
- Dans la section Liaison de la stratégie, procédez comme suit :
- Cliquez sur Nouveau pour créer une stratégie AppQoE.
- Cliquez sur Stratégie existante pour sélectionner une stratégie AppQoE dans la liste déroulante.
- Définissez la priorité de liaison et cliquez sur Lier à la stratégie au serveur virtuel.
- Cliquez sur Terminé.
Génération de blocs SACK
Les performances TCP ralentissent lorsque plusieurs paquets sont perdus dans une fenêtre de données. Dans un tel scénario, un mécanisme d’accusé de réception sélectif (SACK) combiné à une stratégie de retransmission sélective répétitive surmonte cette limite. Pour chaque paquet entrant en rupture de commande, vous devez générer un bloc SACK.
Si le paquet hors commande s’insère dans le bloc de file d’attente de réassemblage, insérez les informations de paquet dans le bloc et définissez les informations de bloc complètes comme SACK-0. Si un paquet hors commande ne rentre pas dans le bloc de réassemblage, envoyez le paquet sous la forme SACK-0 et répétez les blocs SACK précédents. Si un paquet hors commande est un doublon et que les informations de paquet sont définies comme SACK-0 alors D-SACK le bloc.
Note : Un paquet est considéré comme D-SACK s’il s’agit d’un paquet accusé de réception, ou d’un paquet hors commande qui est déjà reçu.
Révocation d’un client
Une appliance Citrix ADC peut gérer la révocation du client lors de la restauration basée sur SACK.
Vérification de la mémoire pour marquer end_point sur PCB ne tient pas compte de la mémoire totale disponible
Dans une appliance Citrix ADC, si le seuil d’utilisation de la mémoire est défini sur 75 % au lieu d’utiliser la mémoire totale disponible, les nouvelles connexions TCP contournent l’optimisation TCP.
Retransmissions inutiles en raison de blocs SACK manquants
Dans un mode non-endpoint, lorsque vous envoyez DUPACKS, si des blocs SACK sont manquants pour quelques paquets hors ordre, déclenche des retransmissions supplémentaires à partir du serveur.
SNMP pour le nombre de connexions contournées optimisation en raison d’une surcharge
Les identifiants SNMP suivants ont été ajoutés à une appliance Citrix ADC pour suivre le nombre de connexions contournées par l’optimisation TCP en raison d’une surcharge.
- 1.3.6.1.4.1.5951.4.1.1.46.13 (TCPopTimizationEnabled). Pour suivre le nombre total de connexions activées avec l’optimisation TCP.
- 1.3.6.1.4.1.5951.4.1.1.46.132 (TCPopTimizationBypassed). Pour suivre le nombre total de connexions contournées l’optimisation TCP.
Mémoire tampon de réception dynamique
Pour optimiser les performances TCP, une appliance Citrix ADC peut désormais ajuster dynamiquement la taille du tampon de réception TCP.
Dans cet article
- Stratégies de lutte contre la congestion
- Algorithme NILE
- Algorithme de récupération de taux proportionnel (PRR)
- TCP Ouverture rapide (TFO)
- TCP Hystart
- Techniques d’optimisation
- Sélection de profil TCP basée sur des stratégies
- Génération de blocs SACK
- Révocation d’un client
- Vérification de la mémoire pour marquer end_point sur PCB ne tient pas compte de la mémoire totale disponible
- Retransmissions inutiles en raison de blocs SACK manquants
- SNMP pour le nombre de connexions contournées optimisation en raison d’une surcharge