Durée de connexion TCP

Question

Combien de temps puis-je m'attendre à ce qu'une connexion TCP client / serveur reste à l'état sauvage?

Je veux qu'il reste connecté en permanence, mais il se passe des choses, le client doit donc se reconnecter. À quel moment dois-je dire qu'il y a un problème dans le code plutôt que dans certains équipements externes?

Answer 1

Je suis d'accord avec Zan Lynx. Il n'y a aucune garantie, mais vous pouvez maintenir une connexion active presque indéfiniment en envoyant des données dessus, en l'absence de problèmes de connectivité ou de bande passante.

Généralement, j’ai opté pour l’approche Keep-Alive au niveau de l’application, bien qu’elle soit généralement appliquée dans les spécifications du client et que j’ai donc dû le faire. Mais envoyez simplement quelques brèves données toutes les minutes ou toutes les deux, auxquelles vous attendez une sorte d'accusé de réception.

Il vous appartient de décider si vous avez ou non accusé réception d'un échec. En règle générale, c’est ce que j’ai fait par le passé, même si j’ai attendu trois retombées infructueuses pour abandonner la connexion, car l’application située à l’autre extrémité de la connexion était extrêmement instable et ne répondait pas. il? " demandes.

Si la connexion échoue, ce qui sera probablement le cas à un moment donné, même avec des machines du même réseau, essayez simplement de la rétablir. Si cela échoue plusieurs fois, vous avez un problème. Si votre connexion échoue de manière persistante après une connexion de longue date, vous avez un problème. Probablement dans les deux cas, il s'agit probablement d'un problème de réseau, plutôt que de votre code, ou peut-être d'un problème lié à la pile TCP / IP sur votre machine (cela est connu: j'ai rencontré des problèmes avec cela sur une ancienne version de QNX - juste tomber au hasard). Cela dit, il se peut que vous rencontriez un problème logiciel et que le seul moyen de savoir avec certitude consiste souvent à attacher un débogueur ou à se connecter. Par exemple. Si vous pouvez toujours vous connecter avec succès, mais après un certain temps, vous arrêtez de recevoir des ACK, même après une reconnexion, votre serveur est peut-être dans une impasse ou est bloqué dans une boucle ou quelque chose du genre.

Ce qui est vraiment utile, c’est de mettre en place une série de tests de longue durée dans diverses conditions de chargement, du simple envoi de la demande de maintien en vie (êtes-vous là?) à l’achat absolu du serveur. Cela vous donnera généralement plus de confiance en vos composants logiciels et peut s'avérer très utile pour résoudre certains problèmes vraiment étranges qui ne poseront pas forcément problème avec votre connexion, même s'ils peuvent entraîner des problèmes lors des transactions en cours. Par exemple, j’étais en train d’écrire un serveur d’applications télécoms qui fournissait des services tels que la traduction de chiffres, et nous le laissions fonctionner pendant des jours. Le fait était que samedi, pendant toute la journée, il rejetterait toutes les demandes d’appel reçues, ce qui représentait des millions d’appels, et nous ne savions pas pourquoi. Cela s’est avéré être dû à une seule faute de frappe dans un code de conversion de date qui ne posait problème que le samedi.

L’espoir que cela aide.

Answer 2

Je pense que l'idée la plus importante ici est la théorie contre la pratique.

La théorie de départ était que les connexions n’avaient aucune durée de vie. Si vous aviez une connexion, celle-ci restait ouverte pour toujours, même en l'absence de trafic, jusqu'à ce qu'un événement provoque sa fermeture.

La nouvelle théorie est que la plupart des versions de système d’exploitation ont activé le minuteur persistant. Cela signifie que les connexions dureront éternellement, tant que le système à l'autre extrémité répond à un échange occasionnel au niveau TCP.

En réalité, de nombreuses connexions se termineront avec le temps, avec une variété de critères et de situations.

Deux très bons exemples sont les suivants: le client distant utilise DHCP, le bail expire et l'adresse IP change.

Un autre exemple est celui des pare-feu, qui semblent de plus en plus intelligents et peuvent identifier le trafic persistant par rapport aux données réelles et fermer les connexions en fonction de critères de haut niveau, en particulier le temps d'inactivité.

La manière dont vous souhaitez implémenter la logique de reconnexion dépend en grande partie de votre architecture, de l'environnement de travail et de vos objectifs de performance.

Answer 3

Cela ne devrait pas vraiment avoir d'importance, vous devez concevoir votre code pour qu'il se reconnecte automatiquement si tel est le comportement souhaité.

Answer 4

Il n'y a vraiment aucun moyen de le savoir. Rien dans le protocole TCP n’entraînerait la perte de la connexion après un certain temps. Une personne sur une connexion fiable peut avoir des années de disponibilité, alors qu'une personne sur une connexion différente peut devoir se reconnecter toutes les 5 minutes. Il n'y a aucun moyen de dire ou même de deviner.

Answer 5

Vous aurez besoin de données régulièrement sur la connexion pour la garder active - de nombreux systèmes d’exploitation ou pare-feu abandonneront une connexion inactive.

Answer 6

Choisissez une valeur. Une goutte par heure, c'est probablement bien. Dix connexions inattendues en 5 minutes indiquent probablement un problème.

Les connexions TCP dureront généralement environ deux heures sans trafic. Chaque extrémité peut envoyer des paquets persistants, qui, je pense, ne sont qu'un ACK sur le dernier paquet reçu. Cela peut généralement être défini par socket ou par défaut sur chaque connexion TCP.

Un niveau d'application persistant est également possible. Pour un protocole de type telnet tel que FTP, SMTP, POP ou IMAP, par exemple envoyer un retour, une nouvelle ligne et récupérer une invite de commande.