Auteur Sujet: NAT-box : fonctionnement de TCP  (Lu 3692 fois)

0 Membres et 1 Invité sur ce sujet

corrector

  • Invité
NAT-box : fonctionnement de TCP
« le: 03 juin 2011 à 16:01:10 »
Est-ce que les NAT-box traitent le TCP :
  • comme une sorte d'UDP : en réécrivant juste les numéros de ports et ce qui s'ensuit (le checksum évidement)
  • comme un flux d'octets : en reconstituant complètement le flux à partir des segments et en re-fabriquant d'autres segments, comme un proxy transparent
Bien sûr les protocoles spécifiques comme FTP doivent entrer dans le second cas; je pose la question pour ce qui est géré comme du pur protocole TCP (pas de match plus spécifique que TCP).

Est-ce que le deuxième choix pourrait être avantageux dans le cas d'un réseau local perdant beaucoup de paquets (Wifi ou CPL perturbé)?

vivien

  • Administrateur
  • *
  • Messages: 47 088
    • Twitter LaFibre.info
NAT-box : fonctionnement de TCP
« Réponse #1 le: 03 juin 2011 à 16:46:42 »
Pour éviter la fragmentation quand le réseau ne supporte pas une MTU à 1500 (cas des box en PPPoE), la box change dynamiquement le paramètre dans les paquets SYN faisant croire que chaque PC ne supporte pas plus de 1492 octets.

Donc pas de fragmentation à réaliser pas de paquet a ré-assembler.

corrector

  • Invité
Adaptation aux différents MTU
« Réponse #2 le: 12 juin 2011 à 02:09:02 »
  • comme un flux d'octets : en reconstituant complètement le flux à partir des segments et en re-fabriquant d'autres segments, comme un proxy transparent
Bien sûr les protocoles spécifiques comme FTP doivent entrer dans ce dernier cas
Non, pas forcèment.

Sous linux, la connexion de contrôle FTP est gérée un segment à la fois : dans le cas précis TCP est traité comme une sorte protocole de remise garantie de datagrammes!

Pour éviter la fragmentation quand le réseau ne supporte pas une MTU à 1500 (cas des box en PPPoE), la box change dynamiquement le paramètre dans les paquets SYN faisant croire que chaque PC ne supporte pas plus de 1492 octets.
Ce qui ne règle que le problème du MTU sur le lien de collecte (pour TCP); si le MTU diminue après, il faudra bien que le système gère cela correctement.

Donc pas de fragmentation à réaliser pas de paquet a ré-assembler.
Quelles implèmentations TCP récentes envoient des trames fragmentables?