Aller au contenu principal

2. Vue d'ensemble du protocole (Protocol Overview)

Ce chapitre décrit le flux de travail complet de TCP Fast Open, incluant les processus de demande, d'octroi et d'utilisation du cookie.

Lors de la première connexion à un serveur, le client doit d'abord obtenir un cookie TFO.

Flux de messages​

Client                                Serveur
   |                                    |
   |  SYN + demande cookie TFO (vide)   |
   |---------------------------------->|
   |                                    |
   |  SYN-ACK + cookie TFO             |
   |<----------------------------------|
   |                                    |
   |  ACK                               |
   |---------------------------------->|
   |                                    |
   |  Données applicatives              |
   |<--------------------------------->|

Format de l'option TCP​

Option de demande de cookie :

  • Kind : 34 (TCP Fast Open)
  • Length : 2 (en-tête d'option uniquement, sans données de cookie)
  • Cookie : vide (indique une demande de cookie)

Points clés​

  1. Transparence : les serveurs ne supportant pas TFO ignorent cette option, la connexion s'établit normalement
  2. Compatibilité : le client DOIT être prêt à revenir à la triple poignée de main TCP standard
  3. Mise en cache du cookie : le client DEVRAIT mettre en cache le cookie reçu pour les connexions ultérieures

Après réception d'une demande de cookie, le serveur génère et retourne le cookie.

Le serveur utilise les informations suivantes pour générer le cookie :

  • Adresse IP du client
  • Clé secrète du serveur (Server Secret)
  • Horodatage (Timestamp) (pour l'expiration du cookie)

Exemple de fonction de chiffrement :

Cookie = AES-128(ServerSecret, ClientIP || Timestamp)

Format de l'option TCP​

Option d'octroi de cookie :

  • Kind : 34
  • Length : 6 à 18 (2 octets d'en-tête + 4 à 16 octets de cookie)
  • Cookie : jeton chiffré généré par le serveur

Comportement du serveur​

  1. DOIT : inclure l'option cookie TFO dans le SYN-ACK
  2. DEVRAIT : utiliser un algorithme de chiffrement suffisamment robuste pour générer le cookie
  3. DOIT : renouveler périodiquement la clé secrète du serveur pour renforcer la sécurité

2.3. Connexion TCP Fast Open (Fast Open Connection)​

Le client utilise le cookie mis en cache lors des connexions suivantes pour réaliser le Fast Open.

Flux de messages​

Client                                Serveur
   |                                    |
   |  SYN + cookie TFO + données        |
   |---------------------------------->|
   |                                    | (vérification du cookie)
   |                                    | (traitement des données)
   |  SYN-ACK + données                |
   |<----------------------------------|
   |                                    |
   |  ACK                               |
   |---------------------------------->|
   |                                    |
   |  Données supplémentaires           |
   |<--------------------------------->|

Avantages clés​

Économie de latence :

  • TCP traditionnel : 1 RTT (poignée de main) + 1 RTT (requête-réponse) = 2 RTT
  • TCP Fast Open : 1 RTT (poignée de main + requête-réponse) = économie de 1 RTT

Limitation des données SYN​

Pour prévenir les attaques par amplification, les données dans le paquet SYN sont limitées :

  1. Longueur maximale des données :

    • Implémentation Linux : limite par défaut au MSS (Maximum Segment Size)
    • Valeur typique : environ 1460 octets (MTU Ethernet 1500 - en-têtes IP/TCP)

  2. Exigences sur les données :

    • DOIT : les données doivent être idempotentes (peuvent être retransmises en toute sécurité)
    • DEVRAIT : les données devraient constituer une requête complète (par exemple, une requête HTTP complète)

Flux de validation du serveur​

Lorsque le serveur reçoit un SYN Fast Open :

1. Vérification du cookie TFO
   ├─ Valide → accepter les données SYN, entrer dans l'état SYN-RECEIVED
   └─ Invalide → rejeter les données SYN, traiter selon la poignée de main TCP standard

2. Si le cookie est valide
   ├─ Transmettre les données SYN à la couche applicative
   ├─ L'application peut traiter immédiatement et générer une réponse
   └─ Transporter les données de réponse dans le SYN-ACK (optionnel)

3. Compléter la triple poignée de main
   └─ Après réception de l'ACK, la connexion entre dans l'état ESTABLISHED

Gestion de la validité :

  • Durée de validité typique : de quelques heures à quelques jours
  • Stratégie de mise à jour : le client peut demander périodiquement un nouveau cookie
  • Gestion de l'expiration : après expiration du cookie, le serveur refuse le Fast Open, le client revient à la poignée de main standard

Le cookie peut devenir invalide dans les situations suivantes :

  1. Expiration temporelle : dépassement de la durée de validité définie par le serveur
  2. Rotation de la clé du serveur : le serveur fait tourner sa clé de chiffrement
  3. Changement d'adresse IP : l'adresse IP du client change (réseau mobile)
  4. Politique du serveur : le serveur révoque activement le cookie (raisons de sécurité)

Stratégie de mise en cache côté client​

Fonctionnalités que le client DEVRAIT implémenter :

  • Mettre en cache un cookie distinct pour chaque IP:Port de serveur
  • Implémenter la gestion de l'expiration des cookies
  • Redemander automatiquement un cookie lorsque celui-ci expire
  • Gérer les cookies pour plusieurs serveurs

Mécanisme de repli​

Lorsque le Fast Open échoue, le client DOIT pouvoir revenir en arrière :

Tentative de Fast Open
   ├─ Succès → continuer à utiliser
   ├─ Cookie rejeté → compléter la poignée de main standard, demander un nouveau cookie
   └─ Délai d'attente → retransmettre SYN (éventuellement sans données)

2.5. Résumé des interactions du protocole (Protocol Interaction Summary)​

Cycle de vie complet​

Phase 1 : Initialisation
   Client ──SYN(demande cookie)──> Serveur
   Client <──SYN-ACK(cookie)─── Serveur
   Client ──ACK──────────────> Serveur
   [Client met en cache le cookie]

Phase 2 : Fast Open (plusieurs fois)
   Client ──SYN(cookie+données)──> Serveur
   Client <──SYN-ACK(données)───── Serveur
   Client ──ACK──────────────> Serveur
   [Économie de 1 RTT]

Phase 3 : Mise à jour du cookie (si nécessaire)
   Répéter la phase 1

Indicateurs de performance​

Type de connexionDébut de transmission des donnéesPerformance relative
TCP standard1,5 RTTRéférence
TFO (première fois)1,5 RTTIdentique au TCP standard
TFO (suivantes)0,5 RTTAmélioration de 66 %

Matrice de compatibilité​

ClientServeurRésultat
Supporte TFOSupporte TFOFast Open réussi
Supporte TFONe supporte pas TFORepli vers TCP standard
Ne supporte pas TFOSupporte TFOTCP standard
Ne supporte pas TFONe supporte pas TFOTCP standard

Section suivante : 3. Détails du protocole (Protocol Details) présentera en profondeur le format des options TFO, la machine à états et les détails d'implémentation.

Dernière mise à jour le