In Citrix ADC 13.0
In Citrix ADC
In All products
Documentation produit
In Citrix ADC 13.0
In Citrix ADC
In All products
Citrix ADC
Current Release 12.1 11.1
Voir PDF

Optimisation TCP

August 20, 2021
Contribution de: 
C

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 TCP a longtemps été utilisé pour établir et gérer les connexions Internet, gérer les erreurs de transmission et connecter facilement les applications Web aux 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 PRR (Proportional Rate Recovery)

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 ce 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 back-end effectuent les étapes suivantes pour établir une connexion TFO et échanger des données en toute sécurité lors de la connexion TCP initiale.

  1. 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.
  2. 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 ouvert rapide généré dans un champ d’option TCP.
  3. Le client met en cache le cookie pour les futures connexions TFO au même serveur virtuel sur l’appliance.
  4. 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.
  5. 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 accuse réception de l’événement uniquement avec un SYN indiquant un délai d’expiration de session.

  1. 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.
  2. Si le cookie TCP Fast Open n’est pas présent, l’appliance envoie une demande de cookie dans le paquet SYN.
  3. Lorsque le serveur principal envoie le cookie, l’appliance stocke le cookie dans le cache d’informations du serveur.
  4. 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.
  5. 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 à l’aide de la même adresse SNIP, l’appliance combine les données du paquet SYN avec le cookie et les envoie au serveur principal.
  6. 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.

Activer ou désactiver TFO à l’aide de l’interface de 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
    Examples
    add tcpprofile Profile1 – tcpFastOpen
    Set tcpprofile Profile1 – tcpFastOpen Enabled
    unset tcpprofile Profile1 – tcpFastOpen
<!--NeedCopy-->

À l’invite de commandes, tapez :

    set tcpparam –tcpfastOpenCookieTimeout <Timeout Value>
    Example
    set tcpprofile –tcpfastOpenCookieTimeout 30secs
<!--NeedCopy-->

Pour configurer le TCP Fast Open à l’aide de l’interface graphique

  1. Accédez à Configuration > Système > Profils, puis cliquez sur Modifier pour modifier un profil TCP.
  2. Dans la page Configurer le profil TCP, activez la case à cocher TCP Fast Open.
  3. Cliquez sur OK, puis sur Terminé.

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 la 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 Cubic HyStart dans le profil TCP correspondant.

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 -hystart ENABLED
    set tcpprofile profile1 -hystart ENABLED
    unset tcprofile profile1 -hystart
<!--NeedCopy-->

Pour configurer la prise en charge HyStart à l’aide de l’interface graphique

  1. Accédez à Configuration > Système > Profils > et cliquez sur Modifier pour modifier un profil TCP.
  2. Sur la page Configurer le profil TCP, activez la case à cocher Hystart cubique.
  3. Cliquez sur OK, puis sur Terminé.

Contrôle du taux de rafale TCP

On observe que les mécanismes de contrôle TCP peuvent entraîner un flux de trafic bourré sur les réseaux mobiles à grande vitesse avec un impact négatif sur l’efficacité globale du réseau. En raison des conditions du réseau mobile telles que la congestion ou la retransmission de données de couche 2, les accusés de réception TCP arrivent à l’expéditeur, ce qui déclenche une explosion de transmission. Ces groupes de paquets consécutifs envoyés avec un court intervalle inter-paquets, il est appelé TCP paquet rafale. Pour surmonter l’éclatement du trafic, l’appliance Citrix ADC utilise une technique de contrôle du taux d’éclatement TCP. Cette technique permet d’espacer uniformément les données dans le réseau pendant toute une période d’aller-retour afin que les données ne soient pas envoyées en rafale. En utilisant cette technique de contrôle du taux d’éclatement, vous pouvez obtenir un meilleur débit et des taux de largage de paquets plus bas.

Fonctionnement du contrôle de taux d’éclatement TCP

Dans une appliance Citrix ADC, cette technique répartit uniformément la transmission d’un paquet sur toute la durée du temps de rotation (RTT). Ceci est réalisé en utilisant une pile TCP et un planificateur de paquets réseau qui identifie les différentes conditions réseau pour sortir les paquets pour les sessions TCP en cours afin de réduire les rafales.

À l’expéditeur, au lieu de transmettre des paquets immédiatement après réception d’un accusé de réception, l’expéditeur peut retarder la transmission des paquets pour les étaler à la vitesse définie par le planificateur (configuration dynamique) ou par le profil TCP (configuration fixe).

Configuration du contrôle du taux de rafale TCP

Pour utiliser l’option Contrôle de taux d’éclatement TCP dans le profil TCP approprié et définir les paramètres de contrôle de taux d’éclatement.

Pour définir le contrôle du taux de rafale TCP à l’aide de la ligne de commande

À l’invite de commandes, définissez l’une des commandes de contrôle de taux d’éclatement TCP suivantes sont configurées dans un profil nouveau ou existant.

Remarque : La valeur par défaut est DISABLED.

add tcpprofile <TCP Profile Name> -burstRateControl Disabled | Dynamic | Fixed

set tcpprofile <TCP Profile Name> -burstRateControl Disabled | Dynamic | Fixed

unset tcpprofile <TCP Profile Name> -burstRateControl Disabled | Dynamic | Fixed
<!--NeedCopy-->

Où,

Désactivé : si le contrôle de taux d’éclatement est désactivé, un appliance Citrix ADC n’effectue pas de gestion de rafale autre que le paramètre MaxBurst.

Corrigé — Si le contrôle de taux d’éclatement TCP est fixe, l’appliance utilise la valeur Taux d’envoi de charge utile de connexion TCP mentionnée dans le profil TCP.

Dynamique : si le contrôle de taux d’éclatement est « dynamique », la connexion est réglementée en fonction de diverses conditions réseau afin de réduire les éclats TCP. Ce mode fonctionne uniquement lorsque la connexion TCP est en mode ENDPOINT. Lorsque le contrôle Taux d’éclatement dynamique est activé, le paramètre MaxBurst du profil TCP n’est pas en vigueur.

add tcpProfile  profile1 -burstRateControl Disabled

set tcpProfile profile1 -burstRateControl Dynamic

unset tcpProfile profile1 -burstRateControl Fixed
<!--NeedCopy-->

Pour définir les paramètres TCP Rate Control à l’aide de l’interface de ligne de commande

À l’invite de commandes, tapez :

    set ns tcpprofile nstcp_default_profile –burstRateControl <type of burst rate control> –tcprate <TCP rate> -rateqmax <maximum bytes in queue>

    T1300-10-2> show ns tcpprofile nstcp_default_profile
            Name: nstcp_default_profile
            Window Scaling status:  ENABLED
            Window Scaling factor: 8
            SACK status: ENABLED
            MSS: 1460
            MaxBurst setting: 30 MSS
            Initial cwnd setting: 16 MSS
            TCP Delayed-ACK Timer: 100 millisec
            Nagle's Algorithm: DISABLED
            Maximum out-of-order packets to queue: 15000
            Immediate ACK on PUSH packet: ENABLED
            Maximum packets per MSS: 0
            Maximum packets per retransmission: 1
            TCP minimum RTO in millisec: 1000
            TCP Slow start increment: 1
            TCP Buffer Size: 8000000 bytes
            TCP Send Buffer Size: 8000000 bytes
            TCP Syncookie: ENABLED
            Update Last activity on KA Probes: ENABLED
            TCP flavor: BIC
            TCP Dynamic Receive Buffering: DISABLED
            Keep-alive probes: ENABLED
            Connection idle time before starting keep-alive probes: 900 seconds
            Keep-alive probe interval: 75 seconds
            Maximum keep-alive probes to be missed before dropping connection: 3
            Establishing Client Connection: AUTOMATIC
            TCP Segmentation Offload: AUTOMATIC
            TCP Timestamp Option: DISABLED
            RST window attenuation (spoof protection): ENABLED
            Accept RST with last acknowledged sequence number: ENABLED
            SYN spoof protection: ENABLED
            TCP Explicit Congestion Notification: DISABLED
            Multipath TCP: DISABLED
            Multipath TCP drop data on pre-established subflow: DISABLED
            Multipath TCP fastopen: DISABLED
            Multipath TCP session timeout: 0 seconds
            DSACK: ENABLED
            ACK Aggregation: DISABLED
            FRTO: ENABLED
            TCP Max CWND : 4000000 bytes
            FACK: ENABLED
            TCP Optimization mode: ENDPOINT
            TCP Fastopen: DISABLED
            HYSTART: DISABLED
            TCP dupack threshold: 3
            Burst Rate Control: Dynamic
            TCP Rate: 0
            TCP Rate Maximum Queue: 0
<!--NeedCopy-->

Pour configurer le contrôle de taux d’éclatement TCP à l’aide de l’interface graphique

  1. Accédez à Configuration > Système > Profils, puis cliquez sur Modifier pour modifier un profil TCP.
  2. Sur la page Configurer le profil TCP, sélectionnez l’option Contrôle de rafale TCP dans la liste déroulante :
    1. BurstRateCntrl
    2. CreditBytePrms
    3. RateBytePerms
    4. RateSchedulerQ
  3. Cliquez sur OK, puis sur Terminé.

Algorithme de protection contre la séquence enveloppée (PAWS)

Si vous activez l’option d’horodatage TCP dans le profil TCP par défaut, l’appliance Citrix ADC utilise l’algorithme Protection Against Wrapped Sequence (PAWS) pour identifier et rejeter les anciens paquets dont les numéros de séquence se trouvent dans la fenêtre de réception de la connexion TCP actuelle car la séquence a « enveloppé » ( atteint sa valeur maximale et redémarre à partir de 0).

Si la congestion réseau retarde un paquet de données non SYN et que vous ouvrez une nouvelle connexion avant l’arrivée du paquet, l’encapsulage de numéros de séquence peut entraîner la nouvelle connexion à accepter le paquet comme valide, entraînant une corruption des données. Mais si l’option d’horodatage TCP est activée, le paquet est ignoré.

Par défaut, l’option d’horodatage TCP est désactivée. Si vous l’activez, l’appliance compare l’horodatage TCP (Seg.tsval) dans l’en-tête d’un paquet à la valeur d’horodatage récent (TS.Recent). Si Seg.tsval est égal ou supérieur à TS.Recent, le paquet est traité. Sinon, l’appliance supprime le paquet et envoie un accusé de réception correctif.

Fonctionnement de PAWS

L’algorithme PAWS traite tous les paquets TCP entrants d’une connexion synchronisée comme suit :

  1. Si SEG.TSval < Ts.recent: Le paquet entrant n’est pas acceptable. PAWS envoie un accusé de réception (tel que spécifié dans RFC-793) et supprime le paquet. Remarque : L’envoi d’un segment ACK est nécessaire pour conserver les mécanismes TCP de détection et de récupération à partir de connexions semi-ouvertes.
  2. Si le paquet est en dehors de la fenêtre : PAWS rejette le paquet, comme dans le traitement TCP normal.
  3. Si SEG.TSval > Ts.recent: PAWS accepte le paquet et le traite.
  4. Si SEG.TSval <= Last.ACK.sent(segment d’arrivée satisfait) : PAWS doit copier SEG.TSval la valeur à Ts.recent (est-il copié dans Ts. Champ récent dans la base de données ?.
  5. Si le paquet est dans l’ordre : PAWS accepte le paquet.
  6. Si le paquet n’est pas dans l’ordre : le paquet est traité comme un segment TCP normal dans la fenêtre et hors séquence. Par exemple, il peut être mis en file d’attente pour une livraison ultérieure.
  7. Si la valeur Ts.recent est inactive pendant plus de 24 jours : la validité de Ts.recent est vérifiée si la vérification de l’horodatage PAWS échoue. Si la valeur TS.Recent n’est pas valide, le segment est accepté et le PAWS rule met à jour Ts.recent avec la valeur TSval du nouveau segment.

Pour activer ou désactiver l’horodatage TCP à l’aide de l’interface de ligne de commande

À l’invite de commandes, tapez :

`set nstcpprofile nstcp_default_profile -TimeStamp (ENABLED | DISABLED)`

Pour activer ou désactiver l’horodatage TCP à l’aide de l’interface graphique

Accédez à Système > Profil > Profil TCP, sélectionnez le profil TCP par défaut, cliquez sur Modifier, puis activez ou désactivez la case à cocher Horodatage TCP.

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.

Pour plus d’informations sur l’utilisation des attributs d’abonné pour effectuer l’optimisation TCP, consultez Profil TCP basé surdes règles.

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 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

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’ tcpprofiletobind option.

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

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>

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>

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 des stratégies à l’aide de l’interface graphique

Pour activer AppQoE à l’aide de l’interface graphique

  1. Accédez à Système > Paramètres.
  2. Dans le volet d’informations, cliquez sur Configurer les fonctionnalités avancées.
  3. Dans la boîte de dialogue Configurer les fonctionnalités avancées, activez la case à cocher AppQoE .
  4. Cliquez sur OK.

Pour configurer la stratégie AppQoE à l’aide de l’interface graphique

  1. Accédez à App-Expert > AppQoE > Actions .
  2. Dans le volet d’informations, effectuez l’une des opérations suivantes :
  3. Pour créer une action, cliquez sur Ajouter.
  4. Pour modifier une action existante, sélectionnez-la, puis cliquez sur Modifier.
  5. 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) :
    1. Name—name
    2. Type d’action—respondWith
    3. Priorité—priority
    4. Profondeur de la file d’attente des stratégies—polqDepth
    5. Profondeur de file d’attente—priqDepth
    6. Action DOS—dosAction
  6. Cliquez sur Créer.

Pour lier la stratégie AppQoE à l’aide de l’interface graphique

  1. Accédez à Gestion du trafic > Équilibrage de charge > Serveurs virtuels, sélectionnez un serveur, puis cliquez sur Modifier.
  2. Dans la section Stratégies et cliquez sur (+) pour lier une stratégie AppQoE.
  3. Dans le curseur Stratégies, procédez comme suit :
    1. Sélectionnez un type de stratégie comme AppQoE dans la liste déroulante.
    2. Sélectionnez un type de trafic dans la liste déroulante.
  4. Dans la section Liaison de la stratégie, procédez comme suit :
    1. Cliquez sur Nouveau pour créer une stratégie AppQoE.
    2. Cliquez sur Stratégie existante pour sélectionner une stratégie AppQoE dans la liste déroulante.
  5. Définissez la priorité de liaison et cliquez sur Lier à la stratégie au serveur virtuel.
  6. 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 de reconnaissance sélective (SACK) combiné à une politique sélective de retransmission répétée 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 ordre ne rentre pas dans le bloc de réassemblage, envoyez le paquet sous la forme SACK-0 et répétez les blocs SACK antérieurs. 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.

Le client renié

Une appliance Citrix ADC peut gérer la révocation du client lors de la restauration basée sur SACK.

Les vérifications de mémoire pour marquer end_point sur PCB ne prennent pas en compte la mémoire disponible totale

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

En mode non-point de terminaison, lorsque vous envoyez des DUPACKS, si des blocs SACK sont manquants pour quelques paquets hors ordre, déclenche davantage de retransmissions à partir du serveur.

SNMP pour les connexions contourné l’optimisation en raison de la surcharge

Les ID SNMP suivants ont été ajoutés à une appliance Citrix ADC pour suivre le nombre de connexions contournées optimisations TCP en raison d’une surcharge.

  1. 1.3.6.1.4.1.5951.4.1.1.46.131 (TCPopTimizationEnabled). Pour suivre le nombre total de connexions activées avec l’optimisation TCP.
  2. 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.

Algorithme de sonde de perte de queue

Un délai d’attente de retransmission (RTO) est une perte de segments à la fin d’une transaction. Un RTO se produit en cas de problèmes de latence d’application, en particulier dans les transactions Web courtes. Pour récupérer la perte de segments à la fin d’une transaction, TCP utilise l’algorithme TLP (Tail Loss Probe). TLP est un algorithme d’expéditeur uniquement. Si une connexion TCP ne reçoit aucun accusé de réception pendant une certaine période, TLP transmet le dernier paquet non accusé de réception (sonde de perte). Dans le cas d’une perte de queue lors de la transmission d’origine, l’accusé de réception de la sonde de perte déclenche une récupération SACK ou FACK.

Configuration de la sonde de perte de queue

Pour utiliser l’algorithme Tail Loss Probe (TLP), vous devez activer l’option TLP dans le profil TCP et définir le paramètre sur une valeur correspondant aux exigences de sécurité de ce profil.

Activer TLP à l’aide de la ligne de commande

À l’invite de commandes, tapez l’une des commandes suivantes pour activer ou désactiver TLP dans un profil nouveau ou existant.

Remarque :

La valeur par défaut est DISABLED.

add tcpprofile <TCP Profile Name> - taillossprobe ENABLED | DISABLED

set tcpprofile <TCP Profile Name> - taillossprobe ENABLED | DISABLED

unset tcpprofile <TCP Profile Name> - taillossprobe

Exemples :

add tcpprofile nstcp_default_profile – taillossprobe

set tcpprofile nstcp_default_profile –taillossprobe Enabled

unset tcpprofile nstcp_default_profile –taillossprobe

Configurer l’algorithme de sonde de perte de queue à l’aide de l’interface graphique Citrix ADC

  1. Accédez à Configuration > Système > Profils, puis cliquez sur Modifier pour modifier un profil TCP.
  2. Sur la page Configurer le profil TCP, activez la case à cocher Sonde de perte de queue.
  3. Cliquez sur OK, puis sur Terminé.
Optimisation TCP
August 20, 2021
Contribution de: 
C
August 20, 2021
Contribution de: 
C

Dans cet article

Commentaires sur le site | Confidentialité et mentions légales | Préférences de cookies | Consent Settings
© 1999- Citrix Systems, Inc. All rights reserved.