Re: Delai IDLE trop grand conntrack
Je m'en doutais. L'état TIME_WAIT indique que la connexion s'est
terminée récemment. Il permet d'accepter pendant un délai de grâce (2
minutes par défaut) d'éventuels segments retardataires arrivés en
désordre après la séquence FIN avant effacement de la connexion de la
table de suivi.
La connexion vers l'exterieur est elle fermée ou bien encore ouverte,
finalement ?
Parce que si elle a été fermée par l'hôte, j'ai pas envie que ma
passerelle garde (même pour deux minutes), la connexion.
Mon opérateur ne m'octroie pas plus de 700 connexions.
Une connection TIME_WAIT est-elle une connexion ouverte ?
> Par contre elles sont tous ASSURED
Cet indicateur est positionné quand la connexion a eu suffisamment de
trafic dans les deux sens, donc toute connexion TCP qui est ou a été
ESTABLISHED reste ASSURED même lorsqu'elle est en cours de fermeture.
Son rôle, ainsi que celui de l'état TIME_WAIT, est expliqué là en
français (forcer le charset Latin-1 ou 9 pour un affichage correct) :
<http://iptables-tutorial.frozentux.net/fr/x1391.html>
Intéressant !
>> Si je comprends bien, ton upstream comptabilise des connexions qui sont
>> considérées comme non ESTABLISHED par ta machine, et donc il arrive
>> qu'il bloque les nouvelles connexions qui ont été autorisées par
>> celle-ci ?
>> Mais dans ce cas je ne vois pas trop en quoi réduire le délai
>> d'expiration des connexions ESTABLISHED sur ta machine aiderait à
>> résoudre le problème.
>
> Donc la modification que j'ai fait n'a pas pour but d'éradiquer les
> TIME_WAIT ?
Ah non, la réduction de ip_conntrack_tcp_timeout_established a pour
conséquence de virer plus vite les connexion établies (ESTABLISHED)
inactives. Aucun effet a priori sur les connexions récemment terminées
(TIME_WAIT). Et inutile de chercher à jouer sur
ip_conntrack_tcp_timeout_time_wait, puisque 'connlimit' ne comptabilise
pas les connexions dans cet état.
Oui, mais si ca me limite le nombre de connexions TIME_WAIT ouvertes,
on va passer de 2 minutes à 20 secondes !
Comme expliqué plus haut, l'état TIME_WAIT signale les connexions qui
ont été fermées proprement récemment. Et un navigateur, ça peut générer
beaucoup de connexions de courte durée pour charger tous les éléments
d'une page web. Chaque connexion dure quelques dixièmes de seconde dans
l'état ESTABLISHED puis reste dans l'état TIME_WAIT pendant 2 minutes
avant d'être effacée. Ça pourrait expliquer la proportion de connexions
dans cet état. Cependant normalement HTTP/1.1 permet de réutiliser une
même connexion pour faire plusieurs requêtes HTTP consécutives, à
condition que le navigateur et le serveur le supportent. C'est ce qu'on
appelle une connexion persistante.
D'accord.
Si les connexions TIME_WAIT sont majoritairement dues à la navigation
web, la mise en place d'un proxy HTTP pourrait peut-être améliorer les
choses.
Le fichier de conf de squid me donne des aigreurs d'estomac.
Si ton but est de faire en sorte que 'connlimit' comptabilise les
connexions en cours à peu près de la même façon que l'upstream, il
faudrait modifier ipt_connlimit.c pour qu'il n'exclue pas les connexions
dans l'état TIME_WAIT. Ça présenterait au moins l'avantage de ne
pénaliser que les clients qui produisent beaucoup de ces connexions et
pas les autres.
C'est quoi l'upstream ? Le flux montant ?
Bah si les clients peuvent pas ouvrir plus de 20 connections par
periode de 120 secondes, je crois que vais me faire tuer :-)
++
Ben
Reply to: