ADC

Optimisation TCP

Le protocole 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 lors de la transmission de données.

Stratégies de contrôle de la congestion

Le protocole TCP est utilisé depuis longtemps pour établir et gérer des connexions Internet, gérer les erreurs de transmission et connecter facilement des applications Web aux appareils clients. Mais le trafic réseau est devenu plus difficile à contrôler, car la perte de paquets ne dépend pas uniquement de la congestion du réseau, et la congestion n’entraîne 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 sur la bande passante.

Algorithme PRR (Proportional Rate Recovery)

Les mécanismes de restauration rapide TCP réduisent la latence Web causée par les pertes de paquets. Le nouvel algorithme PRR (Proportional Rate Recovery) est un algorithme de restauration rapide qui évalue les données TCP lors d’une restauration après perte. Il est calqué sur la réduction de moitié du débit, en utilisant la fraction appropriée pour la fenêtre cible choisie par l’algorithme de contrôle de congestion. Cela minimise l’ajustement de la fenêtre et la taille réelle de la fenêtre à la fin de la restauration est proche du seuil de démarrage lent (ssthresh).

Ouverture rapide TCP (TFO)

Le protocole TCP Fast Open (TFO) est un mécanisme TCP qui permet un échange de données rapide et sécurisé entre un client et un serveur lors de l’établissement de connexion initial du protocole 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 (cookie de sécurité) généré par l’appliance Citrix ADC 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 lors de courts transferts TCP.

Comment fonctionne TFO

Lorsqu’un client essaie d’établir une connexion TFO, il inclut un cookie TCP Fast Open avec le segment SYN initial pour s’authentifier. Si l’authentification aboutit, 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 dernier segment ACK de la liaison tridirectionnelle. Cela permet d’économiser jusqu’à un aller-retour complet par rapport à une connexion TCP normale, qui nécessite une liaison à trois voies avant de pouvoir é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 l’établissement de connexion TCP initial.

  1. Si le client ne dispose pas d’un cookie TCP Fast Open pour s’authentifier, il envoie une demande de cookie d’ouverture rapide dans le paquet SYN au serveur virtuel de 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 par un SYN-ACK qui inclut le cookie d’ouverture 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 essaie d’établir une connexion TFO avec le même serveur virtuel, il envoie un SYN qui inclut le cookie Fast Open 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 aboutit, 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 elle essaie 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 possède déjà un cookie pour la paire d’adresses IP de destination donnée, elle 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 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.
  6. Le serveur principal accuse réception de l’événement à l’aide de données et d’un SYN.

Remarque : si le serveur accuse réception de l’événement avec uniquement un segment SYN, l’appliance Citrix ADC renvoie immédiatement le paquet de données après avoir supprimé le segment SYN et les options TCP du paquet d’origine.

Configuration de l’ouverture rapide du protocole TCP

Pour utiliser la fonctionnalité TCP Fast Open (TFO), activez l’option TCP Fast Open dans le profil TCP concerné et définissez le paramètre TFO Cookie Timeout sur une valeur qui répond 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 commande, 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. Sur la page Configurer le profil TCP, cochez la case TCP Fast Open .
  3. Cliquez sur OK, puis sur Terminé.

Accédez à Configuration > Système > Paramètres > Modifier les paramètresTCP, puis à la page Configurer les paramètresTCP pour définir la valeur du délai d’expiration du cookie d’ouverture rapide TCP.

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 terminer (ssthresh). Il permet une transition vers la prévention de la congestion sans pertes importantes de paquets. Ce nouveau paramètre est désactivé par défaut.

Si une congestion est détectée, HyStart entre dans une phase d’évitement de la congestion. Son activation vous permet d’obtenir un meilleur débit sur les réseaux à haut débit présentant de fortes pertes de paquets. Cet algorithme permet de maintenir une bande passante proche de la limite maximale lors du traitement des transactions. Il peut donc améliorer le débit.

Configuration de TCP HyStart

Pour utiliser la fonctionnalité HyStart, activez l’option Cubic HyStart 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 -hystart ENABLED
    set tcpprofile profile1 -hystart ENABLED
    unset tcprofile profile1 -hystart
<!--NeedCopy-->

Pour configurer le support 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, cochez la case Cubic Hystart .
  3. Cliquez sur OK, puis sur Terminé.

Contrôle du débit de rafale TCP

Il a été observé que les mécanismes de contrôle TCP peuvent entraîner un flux de trafic intense sur les réseaux mobiles à haut débit, 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 groupés à l’expéditeur, déclenchant une transmission en rafale. Ces groupes de paquets consécutifs envoyés avec un court intervalle entre paquets sont appelés rafales de paquets TCP. Pour surmonter l’augmentation du trafic, l’appliance Citrix ADC utilise une technique de contrôle du taux de rafale TCP. Cette technique répartit les données de manière uniforme sur le réseau pendant toute la durée d’un aller-retour afin que les données ne soient pas envoyées en rafale. En utilisant cette technique de contrôle de la fréquence de rafale, vous pouvez obtenir un meilleur débit et des taux de perte de paquets plus faibles.

Comment fonctionne le contrôle de la fréquence de rafale TCP

Dans une appliance Citrix ADC, cette technique répartit uniformément la transmission d’un paquet sur toute la durée de l’aller-retour (RTT). Cela est possible grâce à l’utilisation d’une pile TCP et d’un planificateur de paquets réseau qui identifie les différentes conditions du réseau afin de générer des paquets pour les sessions TCP en cours afin de réduire les rafales.

Au niveau de 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 répartir au débit défini par le planificateur (configuration dynamique) ou par le profil TCP (configuration fixe).

Configuration du contrôle du débit de rafale TCP

Pour utiliser l’option TCP Burst Rate Control dans le profil TCP approprié et définir les paramètres de contrôle du débit de rafale.

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

À l’invite de commandes, définissez l’une des commandes TCP Burst Rate Control suivantes qui 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 la fréquence de rafale est désactivé, une appliance Citrix ADC n’effectue aucune gestion de rafale autre que le paramètre MaxBurst.

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

Dynamique : si le contrôle du débit de rafale est « dynamique », la connexion est régulée en fonction de diverses conditions du réseau afin de réduire les rafales TCP. Ce mode fonctionne uniquement lorsque la connexion TCP est en mode ENDPOINT. Lorsque le contrôle Dynamic Burst Rate est activé, le paramètre MaxBurst du profil TCP n’est pas actif.

add tcpProfile  profile1 -burstRateControl Disabled

set tcpProfile profile1 -burstRateControl Dynamic

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

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

À l’invite de commande, 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 du débit de rafale 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 TCP Burst Control dans la liste déroulante :
    1. BurstRateCntrl
    2. CreditBytePrms
    3. RateBytePerms
    4. RateSchedulerQ
  3. Cliquez sur OK, puis sur Terminé.

Protection contre l’algorithme PAWS (Wrapped Sequence)

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 en cours car la séquence est « encapsulée » (a atteint sa valeur maximale et a redémarré à partir de 0).

Si la congestion du réseau retarde un paquet de données non SYN et que vous ouvrez une nouvelle connexion avant l’arrivée du paquet, l’encapsulation par numéro de séquence peut amener la nouvelle connexion à accepter le paquet comme valide, ce qui entraîne une corruption des données. Mais si l’option d’horodatage TCP est activée, le paquet est supprimé.

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 avec la valeur de l’horodatage récent (ts.Recent). Si Seg.tsVal est égal ou supérieur à ts.Recent, le paquet est traité. Dans le cas contraire, l’appliance abandonne le paquet et envoie un accusé de réception correctif.

Comment fonctionne 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 (comme spécifié dans la 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 restauration des connexions semi-ouvertes.
  2. Si le paquet se trouve en dehors de la fenêtre : PAWS rejette le paquet, comme dans un traitement TCP normal.
  3. Si SEG.TSval > Ts.recent: PAWS accepte le paquet et le traite.
  4. Si SEG.TSval <= Last.ACK.sent(segment entrant satisfait) : PAWS copie la valeur SEG.TSval dans Ts.recent.
  5. Si le paquet est en séquence : PAWS accepte le paquet.
  6. Si le paquet n’est pas en séquence : 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 Ts.recent valeur 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 s’avère non valide, le segment est accepté et 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 commande, 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 > ProfilTCP, sélectionnez le profilTCP par défaut, cliquez surModifier, puis cochez ou décochez la caseHorodatage TCP .

Techniques d’optimisation

TCP utilise les techniques et méthodes d’optimisation suivantes pour optimiser les contrôles de flux.

Sélection de profils TCP basée sur des règles

Le trafic réseau d’aujourd’hui est plus diversifié et plus gourmand en bande passante que jamais. Avec l’augmentation du trafic, l’effet de la qualité de service (QoS) sur les performances du protocole TCP est significatif. Pour améliorer la QoS, 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 afin d’associer un profil TCP optimisé pour un type de trafic particulier, tel que la 3G, la 4G, le LAN ou le 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 règles comprend 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 du profil TCP basée sur AppQoE. Pour implémenter la sélection de profils 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 commande, tapez la commande d’action AppQoe suivante avec l’option tcpprofiletobind.

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 commande, 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 commande, 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 règles à 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 de détails, cliquez sur Configurer les fonctionnalités avancées.
  3. Dans la boîte de dialogue Configurer les fonctionnalités avancées, cochez la case 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 de configuration de l’action AppQoE » comme suit (un astérisque indique un paramètre obligatoire) :
    1. Nom—nom
    2. Type d’action — respondWith
    3. Priorité — priority
    4. Profondeur de la file d’attente de stratégies — polqDepth
    5. Profondeur de file d’attente — priqDepth
    6. Action DOS — dosAction
  6. Cliquez sur Create.

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, cliquez sur (+) pour lier une stratégie AppQoE.
  3. Dans le curseur Stratégies, effectuez les opérations suivantes :
    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 Policy Binding, 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 du protocole 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 répétée sélective permet de surmonter cette limitation. Pour chaque paquet entrant hors service, vous devez générer un bloc SACK.

Si le paquet hors ordre entre dans le bloc de la file d’attente de réassemblage, insérez les informations du paquet dans le bloc et définissez les informations du bloc complètes sur SACK-0. Si un paquet en panne ne rentre pas dans le bloc de réassemblage, envoyez le paquet au format SACK-0 et répétez les blocs SACK précédents. Si un paquet hors ordre est un doublon et que les informations du paquet sont définies comme SACK-0, alors D-SACK le bloc.

Remarque : Un paquet est considéré comme D-SACK s’il s’agit d’un paquet accusé de réception ou d’un paquet hors service déjà reçu.

Le client renie

Une appliance Citrix ADC peut gérer le renoncement du client lors d’une restauration basée sur SACK.

Les contrôles de mémoire pour marquer le point de terminaison sur un circuit imprimé ne prennent pas en compte la quantité totale de mémoire 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 l’absence de blocs SACK

En mode hors point de terminaison, lorsque vous envoyez des DUPACKS, si des blocs SACK sont absents pour quelques paquets hors service, cela déclenche d’autres retransmissions depuis le serveur.

Le protocole SNMP pour les connexions a contourné l’optimisation en raison d’une surcharge

Les identifiants SNMP suivants ont été ajoutés à une appliance Citrix ADC pour suivre le nombre de connexions qui ont contourné les 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 grâce à 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, optimisez TCP.

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 Tail Loss Probe

Un délai de retransmission (RTO) est une perte de segments à la fin d’une transaction. Un RTO se produit en cas de problèmes de latence des applications, en particulier lors de transactions Web courtes. Pour récupérer les segments perdus à la fin d’une transaction, TCP utilise l’algorithme Tail Loss Probe (TLP). TLP est un algorithme réservé aux expéditeurs. Si une connexion TCP ne reçoit aucun accusé de réception pendant un certain temps, TLP transmet le dernier paquet non reconnu (sonde de perte). En cas de perte de la queue lors de la transmission initiale, un accusé de réception émis par la sonde de perte déclenche une reprise du SACK ou du FACK.

Configuration de la sonde Tail Loss

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

Activez 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 Tail Loss Probe à 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, cochez la case Tail Loss Probe .
  3. Cliquez sur OK, puis sur Terminé.