TCP Fast Open
Échange de données plus efficace via TCP Fast Open
TCP Fast Open (TFO) est une mise à jour de TCP qui permet d’économiser jusqu’à un temps d’aller-retour complet (RTT) par rapport à l’établissement de liaison de connexion standard à trois voies pendant une session TCP. Le support de TFO est pour MS-MPC et MS-MIC.
L’établissement de liaison de connexion tridirectionnel standard implique trois ensembles de messages d’envoi et de réception entre deux hôtes et l’échange suivant de paquets SYN (synchroniser) et ACK (accusé) :
L’hôte A envoie un paquet TCP SYN à l’hôte B. L’hôte B le reçoit.
L’hôte B envoie un paquet SYN-ACK à l’hôte A. L’hôte A le reçoit.
L’hôte A envoie un paquet ACK à l’hôte B. L’hôte B le reçoit.
En TCP standard, bien que les données puissent être transportées dans des paquets SYN, ces données ne peuvent pas être livrées tant que l’établissement de liaison à trois voies n’est pas terminé. TFO supprime cette contrainte et permet aux données des paquets SYN d’être livrées à l’application, ce qui améliore considérablement la latence.
Le composant clé de TFO est le cookie d’ouverture rapide (cookie), qui est une balise de code d’authentification de message (MAC) générée par le serveur. Le client demande un cookie dans une connexion TCP standard, puis l’utilise pour de futures connexions TCP afin d’échanger des données pendant l’établissement de liaison.
L’option TFO est utilisée pour demander ou envoyer un cookie TFO. Lorsqu’un cookie n’est pas présent ou est vide, le client utilise la possibilité de demander un cookie au serveur. Lorsque le cookie est présent, l’option est utilisée pour passer le cookie du serveur au client ou du client au serveur.
La liste suivante décrit comment le client demande un témoin TFO :
Le client envoie un SYN avec une option TFO dont le champ de cookie est vide.
Le serveur génère un cookie et l’envoie via l’option TFO d’un paquet SYN-ACK.
Le client met le cookie en cache pour les futures connexions TFO.
Par la suite, les deux appareils effectuent un échange TFO :
Le client envoie un SYN avec les données et le cookie dans l’option TFO.
Le serveur valide le cookie :
Si le cookie est valide, le serveur envoie un SYN-ACK reconnaissant à la fois le SYN et les données.
Le serveur transmet ensuite les données à l’application.
Sinon, le serveur abandonne les données et envoie un SYN-ACK accusant réception uniquement du numéro de séquence SYN.
Le reste de la connexion se déroule comme une connexion TCP normale. Le client peut répéter de nombreuses opérations TFO une fois qu’il a acquis un cookie (jusqu’à ce que le cookie soit expiré par le serveur). Ainsi, TFO est utile pour les applications dans lesquelles un même client se reconnecte plusieurs fois au même serveur et échange des données.
Voir aussi
Configuration de TFO
Dans cette rubrique, les trois modes d’ouverture rapide TCP (TFO) sont décrits et des exemples sont donnés. Le cas de l’utilisation de NAT avec TFO est également couvert.
Trois modes pour TFO
Aucune configuration n’est requise pour utiliser TFO. TFO est activé par défaut. En mode par défaut, tous les paquets TFO sont transférés par le PIC de service. Outre la valeur par défaut, vous pouvez configurer deux autres modes TFO via la CLI :
Drop TFO : si ce mode est défini, aucun paquet TFO n’est transféré.
Désactiver TFO : si ce mode est défini, tout paquet SYN ou SYN ACK transportant des données TFO, ou les deux, sera dépouillé du TFO et des données avant d’être transféré.
L’option TFO est activée par ensemble de services. Il peut s’agir d’un ensemble de services de saut suivant ou d’un ensemble de services de type interface. Voici un exemple de configuration d’ensemble de services de style interface :
[edit]
services {
service-set ss2 {
stateful-firewall-rules sfw_rule;
interface-service {
service-interface ms-2/3/0;
}
}
stateful-firewall {
rule sfw_rule {
match-direction input-output;
term 0 {
from {
source-address {
any-ipv4;
}
destination-address {
any-ipv4;
}
then {
accept;
}
}
}
}
}
}
Dans ce cas, TFO est activé par défaut (pas de configuration TFO). La sortie de la show services service-sets statistics tcp commande est la suivante :
user@host> show services service-sets statistics tcp
Interface: ms-2/3/0
Service set: ss2
TCP open/close statistics:
TCP first packet non-syn: 0
TCP first packet reset: 0
TCP first packet FIN: 0
TCP non syn discard: 0
TCP extension alloc fail: 0
TFO SYN with cookie request: 1
TFO SYN with cookie: 0
TFO SYN ACK with cookie: 0
TFO packets forwarded: 0
TFO packets dropped: 1
TFO packets stripped: 0
Si vous supprimez des paquets activés TFO, vous disposez de la configuration et de la sortie suivantes :
[edit]
services {
service-set ss2 {
service-set-options {
tcp-fast-open drop;
}
stateful-firewall-rules sfw_rule;
interface-service {
service-interface ms-2/3/0;
}
}
}
user@host> show services service-sets statistics tcp
Interface: ms-2/3/0
Service set: ss2
TCP open/close statistics:
TCP first packet non-syn: 0
TCP first packet reset: 0
TCP first packet FIN: 0
TCP non syn discard: 0
TCP extension alloc fail: 0
TFO SYN with cookie request: 1
TFO SYN with cookie: 0
TFO SYN ACK with cookie: 0
TFO packets forwarded: 0
TFO packets dropped: 1
TFO packets stripped: 0
Si vous supprimez l’option TFO, la configuration et la sortie changent en conséquence :
[edit]
services {
service-set ss2 {
service-set-options {
tcp-fast-open disabled;
}
stateful-firewall-rules sfw_rule;
interface-service {
service-interface ms-2/3/0;
}
}
}
user@host> show services service-sets statistics tcp
Interface: ms-2/3/0
Service set: ss2
TCP open/close statistics:
TCP first packet non-syn: 0
TCP first packet reset: 0
TCP first packet FIN: 0
TCP non syn discard: 0
TCP extension alloc fail: 0
TFO SYN with cookie request: 1
TFO SYN with cookie: 0
TFO SYN ACK with cookie: 0
TFO packets forwarded: 0
TFO packets dropped: 0
TFO packets stripped: 1
En utilisant le NAT et le TFO
Si NAT est configuré dans l’ensemble de services et que vous utilisez TFO, vous devez configurer la mise en commun d’adresses appariée (APP). APP permet de mapper une adresse IP privée à la même adresse IP publique à partir d’un pool NAT pour toutes ses sessions.
Si vous ne configurez pas APP, NAT peut donner une adresse IP différente au client à partir du même pool NAT que celle qu’il a envoyée au serveur auparavant. Le serveur ne reconnaît pas l’adresse IP, abandonne l’option TFO et répond avec SYN ACK et les données envoyées par le client ne sont pas acquittées. Par conséquent, même si la connexion réussit et qu’aucun paquet n’est perdu, le bénéfice de TFO est perdu. Mais si le client revient avec la même adresse IP, le serveur la reconnaît et reconnaît les données. Par conséquent, activez toujours l’application avec une valeur de délai d’expiration de mappage élevée avec TFO.
Pour configurer l’application :
Configuration du contrôle de fragmentation pour les interfaces de service MS-DPC et MS-PIC
Deux options de configuration sont disponibles pour éviter une consommation excessive de cycles CPU de calcul sur un PIC de services causée par la gestion d’un grand nombre de paquets fragmentés. Cette gestion des fragments peut être exploitée dans les attaques DOS. L’option fragment-limit établit un nombre maximal de fragments pour un paquet. Lorsque ce nombre est dépassé, le paquet est abandonné. Spécifie reassembly-timeout le délai maximal à compter de la réception du premier et du dernier fragment d’un paquet. Lorsque le nombre est dépassé, le paquet est abandonné.
Pour configurer le contrôle de la fragmentation pour les interfaces de service MS-DPC et MS-PIC :
Services de traçage Opérations PIC
Les opérations de traçabilité permettent de suivre toutes les opérations des services adaptatifs et de les enregistrer dans un fichier journal. Les descriptions d’erreurs consignées fournissent des informations détaillées pour vous aider à résoudre les problèmes plus rapidement.
Par défaut, aucun événement n’est tracé. Si vous incluez l’instruction traceoptions au niveau de la [edit services adaptive-services-pics] hiérarchie ou [edit services logging] , le comportement de suivi par défaut est le suivant :
Les événements importants sont consignés dans un fichier appelé
servicedsitué dans le répertoire /var/log .Lorsque le fichier desservi atteint 128 kilo-octets (Ko), il est renommé serviced.0, puis serviced.2, et ainsi de suite, jusqu’à ce qu’il y ait trois fichiers de trace. Ensuite, le fichier de trace le plus ancien (serviced.2) est écrasé. (Pour plus d’informations sur la façon dont les fichiers journaux sont créés, voir l’Explorateur de journaux système.)
Seuls les utilisateurs qui ont configuré l’opération de suivi accèdent aux fichiers journaux.
Vous ne pouvez pas modifier le répertoire (/var/log) dans lequel se trouvent les fichiers de trace. Toutefois, vous pouvez personnaliser les autres paramètres du fichier de trace en incluant les instructions suivantes :
file filename <files number> <match regular-expression> <size size> <world-readable | no-world-readable>;
flag {
all;
command-queued;
config;
handshake;
init;
interfaces;
mib;
removed-client;
show;
}
Vous incluez ces instructions au niveau de la [edit services adaptive-services-pics traceoptions] hiérarchie ou [edit services logging traceoptions] .
Ces déclarations sont décrites dans les sections suivantes :
- Configuration du nom du fichier journal Adaptive Services
- Configuration du nombre et de la taille des fichiers journaux Adaptive Services
- Configuration de l’accès au fichier journal
- Configuration d’une expression régulière pour les lignes à enregistrer
- Configuration des opérations de traçage
Configuration du nom du fichier journal Adaptive Services
Par défaut, le nom du fichier qui enregistre la sortie de trace est pris en charge. Vous pouvez spécifier un nom différent en incluant l’instruction file au niveau de la [edit services adaptive-services-pics traceoptions] hiérarchie ou [edit services logging traceoptions] :
file filename;
Configuration du nombre et de la taille des fichiers journaux Adaptive Services
Par défaut, lorsque la taille du fichier de trace atteint 128 kilo-octets (Ko), il est renommé filename.0, puis filename.1, et ainsi de suite, jusqu’à ce qu’il y ait trois fichiers de trace. Ensuite, le fichier de trace le plus ancien (filename.2) est écrasé.
Vous pouvez configurer les limites du nombre et de la taille des fichiers de suivi en incluant les instructions suivantes au niveau de la [edit services adaptive-services-pics traceoptions] hiérarchie ou [edit services logging traceoptions] :
file <filename> files number size size;
Par exemple, définissez la taille maximale des fichiers sur 2 Mo et le nombre maximal de fichiers sur 20. Lorsque le fichier qui reçoit la sortie de l’opération de suivi (filename) atteint 2 Mo, filename est renommé filename.0 et un nouveau fichier appelé filename est créé. Lorsque le nouveau filename atteint 2 Mo, filename.0 est renommé filename.1 et filename est renommé filename.0. Ce processus se répète jusqu’à ce qu’il y ait 20 fichiers de trace. Ensuite, le fichier le plus ancien (filename.19) est écrasé par le fichier le plus récent (filename.0).
Le nombre de fichiers peut être compris entre 2 et 1000. La taille de chaque fichier peut être comprise entre 10 Ko et 1 gigaoctet (Go).
Configuration de l’accès au fichier journal
Par défaut, seuls les utilisateurs qui ont configuré l’opération de suivi accèdent aux fichiers journaux.
Pour spécifier qu’un utilisateur peut lire tous les fichiers journaux, incluez l’instruction file world-readable au niveau de la [edit services adaptive-services-pics traceoptions] hiérarchie ou [edit services logging traceoptions] :
file <filename> world-readable;
Pour définir explicitement le comportement par défaut, incluez l’instruction file no-world-readable au niveau de la [edit services adaptive-services-pics traceoptions] hiérarchie ou [edit services logging traceoptions] :
file <filename> no-world-readable;
Configuration d’une expression régulière pour les lignes à enregistrer
Par défaut, la sortie de l’opération de traçage inclut toutes les lignes pertinentes pour les événements consignés.
Vous pouvez affiner la sortie en incluant l’instruction match au niveau de la [edit services adaptive-services-pics traceoptions file filename] hiérarchie ou [edit services logging traceoptions] et en spécifiant une expression régulière (regex) à mettre en correspondance :
file <filename> match regular-expression;
Configuration des opérations de traçage
Par défaut, si la configuration est présente, seuls les traceoptions événements importants sont enregistrés. Vous pouvez configurer les opérations de traçage à journaliser en incluant les instructions suivantes au niveau de la [edit services adaptive-services-pics traceoptions] hiérarchie ou [edit services logging traceoptions] :
flag {
all;
configuration;
routing-protocol;
routing-socket;
snmp;
}
Le Tableau 1 décrit la signification des indicateurs de suivi des services adaptatifs.
Drapeau |
Descriptif |
Paramètre par défaut |
|---|---|---|
|
Tracez toutes les opérations. |
Désactivé |
|
La commande de traçage met les événements en file d’attente. |
Désactivé |
|
Lecture du journal de la configuration au niveau de la |
Désactivé |
|
Tracez les événements d’établissement de liaison. |
Désactivé |
|
Suivre les événements d’initialisation. |
Désactivé |
|
Suivre les événements d’interface. |
Désactivé |
|
Tracez les événements MIB SNMP GGSN. |
Désactivé |
|
Suivre les événements de nettoyage des clients. |
Désactivé |
|
Service de commande Trace CLI. |
Désactivé |
Pour afficher la fin du journal, exécutez la show log serviced | last commande mode opérationnel :
[edit] user@host# run show log serviced | last