Quand une connexion TCP est-elle considérée comme inactive?
J'ai besoin d'activer TCP keepalive sur toutes les connexions et maintenant j'ai du mal avec les résultats de notre cas de test. Je pense que c'est parce que je ne comprends pas vraiment quand la première sonde keepalive est envoyée . J'ai lu ce qui suit dans la documentation de tcp_keepalive_time sous Linux:
l'intervalle entre le dernier paquet de données envoyé (les ACK simples ne sont pas considérés comme des données) et la première sonde keepalive; une fois que la connexion est marquée comme devant être maintenue, ce compteur n'est plus utilisé
Certaines autres sources indiquent que c'est le moment où une connexion est inactive, mais elles ne définissent pas davantage ce que cela signifie. J'ai également examiné Stevens pour trouver une définition plus formelle de cela, car je me demande ce que signifie réellement "le dernier paquet de données envoyé" lorsque l'on envisage des retransmissions.
Dans mon cas de test, j'ai une connexion où les données ne sont envoyées d'un serveur à un client qu'à des taux plutôt élevés. Pour tester keepalive, nous avons débranché le câble sur la carte réseau du client. Je peux maintenant voir que la pile réseau essaie d'envoyer les données et entre dans l'état de retransmission, mais aucune sonde Keep Alive n'est envoyée. Est-il exact que les sondes de maintien en vie ne sont pas envoyées pendant la retransmission?
J'ai une connexion où les données ne sont envoyées d'un serveur à un client qu'à des taux plutôt élevés.
Ensuite, vous ne verrez jamais de Keepalives. Des Keepalives sont envoyés quand il y a "silence sur le fil". RFC1122 a quelques explications sur les Keepalives.
Un mécanisme "keep-alive" sonde périodiquement l'autre extrémité d'une connexion lorsque la connexion est par ailleurs inactive , même lorsqu'il n'y a pas de données à envoyer
Retour à votre question:
Certaines autres sources indiquent que c'est le moment où une connexion est inactive, mais elles ne définissent pas davantage ce que cela signifie.
C'est combien de temps TCP attendra avant de pousser le pair "hoy! Toujours vivant?".
$ cat /proc/sys/net/ipv4/tcp_keepalive_time
7200
En d'autres termes, vous avez utilisé une connexion TCP et cela a été formidable. Cependant, au cours des 2 dernières heures, il n'y a rien eu à envoyer. Est-il raisonnable de supposer que la connexion est toujours en vie? Est-il raisonnable de supposer que tous les boîtiers de médiation au milieu ont encore un état concernant votre connexion? Les opinions varient et les Keepalives ne font pas partie de la RFC793.
La spécification TCP n'inclut pas de mécanisme de maintien en vie qu'elle pourrait: (1) entraîner la rupture de bonnes connexions pendant les défaillances transitoires d'Internet; (2) consommer une bande passante inutile ("si personne n'utilise la connexion, peu importe si c'est encore bon? ")
Pour tester keepalive, nous avons débranché le câble sur la carte réseau du client.
Ce n'est pas un test de keepalive. Il s'agit de tester votre stratégie de retransmission TCP, c'est-à-dire combien de fois et à quelle fréquence TCP essaiera de faire passer votre message. Sur une boîte Linux, cela (probablement) finit par tester net.ipv4.tcp_retries2 :
Comment peut-on réessayer avant de tuer vivant TCP. RFC 1122 dit que la limite doit être supérieure à 100 s. C'est un nombre trop petit. La valeur par défaut 15 correspond à 13-30min selon RTO .
Mais RFC5482 - TCP Option de délai d'expiration utilisateur fournit plus de façons de l'influencer.
Le délai d'attente de l'utilisateur TCP contrôle la durée pendant laquelle les données transmises peuvent rester non acquittées avant la fermeture forcée d'une connexion.
Retour à la question:
Est-il exact que les sondes de maintien en vie ne sont pas envoyées pendant la retransmission
Cela a du sens: TCP essaie déjà d'obtenir une réponse de l'autre pair, un keepalive vide serait superflu.
Spécifique à Linux (2.4+) options pour influencer keepalive
TCP_KEEPCNTLe nombre maximum de sondes keepalive TCP doit envoyer avant de couper la connexion).
TCP_KEEPIDLELe temps (en secondes) pendant lequel la connexion doit rester inactive avant TCP commence à envoyer des sondes keepalive, si l'option socketSO_KEEPALIVEa été défini sur ce socket
TCP_KEEPINTVLLe temps (en secondes) entre les sondes Keepalive individuelles
Spécifique à Linux (2.6.37+) option pour influencer TCP Timeout utilisateur
TCP_USER_TIMEOUTLa durée maximale en millisecondes pendant laquelle les données transmises peuvent rester non acquittées avant TCP fermera la connexion de force.
Ainsi, par exemple, votre application pourrait utiliser cette option pour déterminer la durée de vie de la connexion en l'absence de connectivité (similaire à votre exemple de déconnexion de carte réseau). Par exemple. si vous avez des raisons de croire que le client reviendra (peut-être qu'il a fermé le couvercle de l'ordinateur portable? accès sans fil inégal?), vous pouvez spécifier un délai de 12 heures et quand il reviendra, la connexion fonctionnera toujours.