Appendix B. Duplicates from Earlier Connection Incarnations (Duplicatas d'incarnations de connexion antérieures)

Appendix B: Duplicates from Earlier Connection Incarnations (Duplicatas d'incarnations de connexion antérieures)

Deux cas doivent être considérés: (1) un système qui plante (et perd l'état de connexion) et redémarre, et (2) la même connexion étant fermée et rouverte sans perte d'état d'hôte. Ceux-ci seront décrits dans les deux sections suivantes.

B.1 System Crash with Loss of State (Crash système avec perte d'état)

Le temps de silence TCP d'un MSL au démarrage du système gère la perte d'état de connexion lors d'un crash/redémarrage du système. Pour une explication, voir par exemple "When to Keep Quiet" dans la spécification du protocole TCP [Postel81]. Le MSL requis ici ne dépend pas de la vitesse de transfert. Le MSL TCP actuel de 2 minutes semble acceptable comme compromis opérationnel, car de nombreux systèmes hôtes prennent ce temps pour démarrer après un crash.

Cependant, l'option timestamp peut être utilisée pour assouplir les exigences MSL (ou pour fournir une sécurité supplémentaire contre la corruption des données). Si les timestamps sont utilisés et si l'horloge timestamp peut être garantie comme monotone sur un crash/redémarrage du système, c'est-à-dire si la première valeur de l'horloge timestamp de l'expéditeur après un crash/redémarrage peut être garantie comme étant supérieure à la dernière valeur avant le redémarrage, alors un temps de silence sera inutile.

Pour se passer totalement du temps de silence nécessiterait que l'horloge hôte soit synchronisée avec une source de temps stable sur la période de crash/redémarrage, avec une précision d'un tick d'horloge timestamp ou mieux. Nous pouvons reculer de cette exigence stricte pour profiter d'une synchronisation d'horloge approximative. Supposons que l'horloge soit toujours resynchronisée à N ticks d'horloge timestamp près et que le démarrage (étendu avec un temps de silence, si nécessaire) prenne plus de N ticks. Cela garantira la monotonie des timestamps, qui peuvent ensuite être utilisés pour rejeter les anciens duplicatas même sans un MSL appliqué.

B.2 Closing and Reopening a Connection (Fermeture et réouverture d'une connexion)

Lorsqu'une connexion TCP est fermée, un délai de 2*MSL dans l'état TIME-WAIT immobilise la paire de sockets pendant 4 minutes (voir Section 3.5 de [Postel81]). Les applications construites sur TCP qui ferment une connexion et en ouvrent une nouvelle (par exemple, une connexion de transfert de données FTP utilisant le mode Stream) doivent choisir une nouvelle paire de sockets à chaque fois. Le délai TIME-WAIT remplit deux objectifs différents:

(a) Implement the full-duplex reliable close handshake of TCP. (Implémenter la poignée de main de fermeture fiable en duplex intégral de TCP)

Le temps approprié pour retarder l'étape de fermeture finale n'est pas vraiment lié au MSL; il dépend plutôt du RTO pour les segments FIN et donc du RTT du chemin. (On pourrait soutenir que le côté qui envoie un FIN sait quel degré de fiabilité il nécessite, et par conséquent il devrait être en mesure de déterminer la longueur du délai TIME-WAIT pour le destinataire du FIN. Cela pourrait être accompli avec une option TCP appropriée dans les segments FIN.)

Bien qu'il n'y ait pas de limite supérieure formelle sur le RTT, la pratique courante de l'ingénierie réseau rend un RTT supérieur à 1 minute très improbable. Ainsi, le délai de 4 minutes dans l'état TIME-WAIT fonctionne de manière satisfaisante pour fournir une fermeture TCP en duplex intégral fiable. Notez à nouveau que ceci est indépendant de l'application du MSL et de la vitesse du réseau.

L'état TIME-WAIT pourrait causer un problème de performance indirect si une application devait fermer à plusieurs reprises une connexion et en ouvrir une autre à une très haute fréquence, car le nombre de ports TCP disponibles sur un hôte est inférieur à 2**16. Cependant, les vitesses réseau élevées ne sont pas le principal contributeur à ce problème; le RTT est le facteur limitant la rapidité avec laquelle les connexions peuvent être ouvertes et fermées. Par conséquent, ce problème ne sera pas pire à des vitesses de transfert élevées.

(b) Allow old duplicate segments to expire. (Permettre l'expiration des anciens segments dupliqués)

Pour remplacer cette fonction de l'état TIME-WAIT, un mécanisme devrait fonctionner à travers les connexions. PAWS est défini strictement au sein d'une seule connexion; le dernier timestamp TS.Recent est conservé dans le bloc de contrôle de connexion et supprimé lorsqu'une connexion est fermée.

Un mécanisme supplémentaire pourrait être ajouté au TCP, un cache par hôte du dernier timestamp reçu de n'importe quelle connexion. Cette valeur pourrait alors être utilisée dans le mécanisme PAWS pour rejeter les anciens segments dupliqués d'incarnations antérieures de la connexion, si l'horloge timestamp peut être garantie avoir fait au moins un tick depuis que l'ancienne connexion était ouverte. Cela nécessiterait que le délai TIME-WAIT plus le RTT ensemble soient au moins un tick de l'horloge timestamp de l'expéditeur. Une telle extension ne fait pas partie de la proposition de ce RFC.

Notez qu'il s'agit d'une variante du mécanisme proposé par Garlick, Rom et Postel [Garlick77], qui exigeait que chaque hôte maintienne des enregistrements de connexion contenant les numéros de séquence les plus élevés sur chaque connexion. En utilisant plutôt des timestamps, il est seulement nécessaire de conserver une quantité par hôte distant, quel que soit le nombre de connexions simultanées vers cet hôte.