Ouverture rapide TCP
Échange de données plus efficace à l’aide de 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 à trois voies standard au cours d’une session TCP. La prise en charge de TFO concerne 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é de réception) :
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.
Dans le protocole TCP standard, bien que les données puissent être transportées sous forme de paquets SYN, ces données ne peuvent pas être transmises tant que l’établissement de liaison à trois voies n’est pas terminé. TFO supprime cette contrainte et permet de livrer les données des paquets SYN à l’application, ce qui permet d’améliorer considérablement la latence.
L’élément clé de TFO est le cookie d’ouverture rapide (cookie), qui est une balise MAC (Message Authentication Code) générée par le serveur. Le client demande un cookie lors d’une connexion TCP normale, puis l’utilise pour les futures connexions TCP afin d’échanger des données pendant l’établissement de liaison.
L’option TFO permet de demander ou d’envoyer un cookie TFO. Lorsqu’un cookie n’est pas présent ou est vide, l’option est utilisée par le client pour demander un cookie au serveur. Lorsque le cookie est présent, l’option est utilisée pour transmettre le cookie du serveur au client ou du client au serveur.
La liste suivante décrit la façon dont 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.
Dans le cas contraire, 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 le 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 de TCP Fast Open (TFO) sont décrits et des exemples 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. En plus de la valeur par défaut, il existe deux autres modes pour TFO que vous configurez via l’interface de ligne de commande :
Drop TFO : si ce mode est défini, aucun paquet TFO n’est transféré.
Disable TFO—Si ce mode est défini, tout paquet SYN ou SYN ACK transportant TFO, des données, 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’un 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). Le résultat de la show services service-sets statistics tcp commande est le suivant :
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 les paquets compatibles TFO, vous avez la configuration et 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
Utilisation de NAT et TFO
Si NAT est configuré dans l’ensemble de services et que vous utilisez TFO, vous devez configurer l’appariement du regroupement d’adresses (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 l’application, NAT peut donner une adresse IP différente au client 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 est réussie 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 accuse réception des données. Par conséquent, activez toujours l’application avec une valeur de délai d’attente 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 la consommation excessive de cycles de calcul du processeur sur un PIC de services causée par la gestion d’un grand nombre de paquets fragmentés. Une telle 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é. Le reassembly-timeout spécifie le délai maximal entre la réception du premier et du dernier fragment d’un paquet. Lorsque ce nombre est dépassé, le paquet est abandonné.
Pour configurer le contrôle de fragmentation pour les interfaces de service MS-DPC et MS-PIC :
Services de traçage Opérations PIC
Opérations de suivi Suivez toutes les opérations des services adaptatifs et enregistrez-les dans un fichier journal. Les descriptions des 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 géré 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, reportez-vous à l’Explorateur de journaux système.)
Les fichiers journaux ne sont accessibles qu’à l’utilisateur qui configure l’opération de suivi.
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 traité. 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 en nombre et en taille des fichiers de trace 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 du fichier 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 il 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 fichiers. 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 fichiers journaux sont accessibles à l’utilisateur qui configure l’opération de suivi.
Pour spécifier que n’importe quel 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) à faire correspondre :
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 consignés. Vous pouvez configurer les opérations de suivi à consigner 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 |
Description |
Paramètre par défaut |
|---|---|---|
|
Tracez toutes les opérations. |
De |
|
Événements de mise en file d’attente de la commande Trace. |
De |
|
Lecture du journal de la configuration au niveau de la |
De |
|
Tracez les événements d’établissement de liaison. |
De |
|
Tracez les événements d’initialisation. |
De |
|
Tracez les événements de l’interface. |
De |
|
Tracez les événements MIB GGSN SNMP. |
De |
|
Tracez les événements de nettoyage du client. |
De |
|
Service des commandes Trace CLI. |
De |
Pour afficher la fin du journal, exécutez la commande mode show log serviced | last opérationnel :
[edit] user@host# run show log serviced | last