web-dev-qa-db-fra.com

Suppression de connexions avec tcp_tw_recycle

résumé du problème

nous avons une configuration dans laquelle beaucoup (800 à 2400 par seconde (de connexions entrantes vers une boîte linux et nous avons un appareil NAT entre le client et le serveur. donc il y a tellement de sockets TIME_WAIT) laissé dans le système. Pour surmonter cela, nous avions défini tcp_tw_recycle sur 1, mais cela a conduit à une baisse des connexions entrantes. après avoir parcouru le réseau, nous avons trouvé les références pour lesquelles la suppression de trames avec tcp_tw_recycle et NAT se produit.

résolution essayée

nous avons ensuite essayé en mettant tcp_tw_reuse à 1, cela a bien fonctionné sans aucun problème avec la même installation et configuration.

Mais la documentation indique que tcp_tw_recycle et tcp_tw_reuse ne doivent pas être utilisés lorsque les connexions qui passent par TCP nœuds sensibles à l'état, tels que les pare-feu, NAT périphériques ou équilibreurs de charge) il peut y avoir des pertes d'images. Plus il y a de connexions, plus vous verrez ce problème.

Requêtes

1) tcp_tw_reuse peut-il être utilisé dans ce type de scénarios? 2) sinon, quelle partie du code linux empêche tcp_tw_reuse d'être utilisé pour un tel scénario? 3) quelle est généralement la différence entre tcp_tw_recycle et tcp_tw_reuse?

linuxtcp-ip
27
user1153755

Par défaut, lorsque les deux tcp_tw_reuse et tcp_tw_recycle sont désactivés, le noyau s'assurera que les sockets dans TIME_WAIT l'état restera dans cet état assez longtemps - assez longtemps pour être sûr que les paquets appartenant aux connexions futures ne seront pas confondus avec les paquets tardifs de l'ancienne connexion.

Lorsque vous activez tcp_tw_reuse, sockets dans TIME_WAIT state peut être utilisé avant leur expiration, et le noyau essaiera de s'assurer qu'il n'y a pas de collision concernant les numéros de séquence TCP. Si vous activez tcp_timestamps (alias PAWS, pour la protection contre les numéros de séquence enveloppés), il s'assurera que ces collisions ne peuvent pas se produire. Cependant, vous avez besoin de TCP pour être activé sur les deux extrémités (du moins, c'est ce que je comprends). Voir la définition de tcp_twsk_unique pour les détails sanglants.

Lorsque vous activez tcp_tw_recycle, le noyau devient beaucoup plus agressif et fera des hypothèses sur les horodatages utilisés par les hôtes distants. Il suivra le dernier horodatage utilisé par chaque hôte distant ayant une connexion dans TIME_WAIT state), et permettre de réutiliser un socket si l'horodatage a correctement augmenté. Cependant, si l'horodatage utilisé par l'hôte change (c'est-à-dire qu'il se déforme dans le temps), le paquet SYN sera silencieusement abandonné et la connexion ne s'établira pas (vous verrez une erreur similaire à "timeout de connexion"). ). Si vous voulez plonger dans le code du noyau, la définition de tcp_timewait_state_process pourrait être un bon point de départ.

Maintenant, les horodatages ne devraient jamais remonter dans le temps; sauf si:

  • l'hôte est redémarré (mais au moment où il revient, TIME_WAIT socket aura probablement expiré, donc ce ne sera pas un problème);
  • l'adresse IP est rapidement réutilisée par autre chose (TIME_WAIT les connexions resteront un peu, mais d'autres connexions seront probablement frappées par TCP RST et cela libérera de l'espace);
  • la traduction d'adresse réseau (ou un pare-feu smarty-pants) est impliquée au milieu de la connexion.

Dans ce dernier cas, vous pouvez avoir plusieurs hôtes derrière la même adresse IP, et donc, différentes séquences d'horodatages (ou, ces horodatages sont randomisés à chaque connexion par le pare-feu). Dans ce cas, certains hôtes ne pourront pas se connecter de manière aléatoire, car ils sont mappés sur un port pour lequel le TIME_WAIT le compartiment du serveur a un horodatage plus récent. C'est pourquoi les documents vous indiquent que "les périphériques NAT ou les équilibreurs de charge peuvent commencer à supprimer des images en raison du paramètre".

Certaines personnes recommandent de quitter tcp_tw_recycle seul, mais activez tcp_tw_reuse et inférieur tcp_fin_timeout. Je suis d'accord :-)

50
jpetazzo