❦ 23 juillet 2013 09:29 CEST, Greg <greg-fr...@duchatelet.net> :
> net.ipv4.tcp_tw_recycle=1
> net.ipv4.tcp_tw_reuse=1
tcp_tw_recycle est très dangereux et peut causer divers problèmes
difficiles à diagnostiquer, notamment une impossibilité pour certains
clients d'établir la connexion.
> A ce moment commence les recherches sur Google, et tout ce que je trouve
> est ambigu : il vaut mieux activer les
> timestamps TCP pour des raisons de performances, mais il faut mieux les
> désactiver pour des problèmes de sécurité.
> Activé, l'attaquant peut récupérer l'uptime du serveur... Franchement osef
> nan ?
> Ce qui me gène plus, c'est qu'il est conseillé d'activer ce paramètre en
> cas de soucis de congestion TCP...
Les timestamps te permettent d'obtenir une meilleure estimation du RTT
qui est ensuite utilisé à pas mal d'endroits, notamment pour les
retransmissions et la gestion des SACK.
A mon avis, tu ne devrais pas changer autant de choses dans les sysctl.
> net.ipv4.tcp_sack = 1
> net.ipv4.tcp_fack = 1
> net.ipv4.tcp_window_scaling = 1
Ce sont les valeurs par défaut.
> net.ipv4.tcp_syncookies = 0
Si tu fais ça pour supprimer le message indiquant l'activation des
syncookies, tu empires juste le problème. Si tu as régulièrement un
message à propos des syncookies, cela signifie que ton application ne
suit pas derrière. Tu peux augmenter la listening queue au niveau de
l'application de ou de l'OS pour fixer ça si besoin, mais
fondamentalement, ça veut dire que y'a un soucis de charge sur
l'appli. Les syncookies permettent de mitiger l'effet. Sans les
syncookies, la connexion est simplement refusée.
> net.core.netdev_max_backlog = 4000
> net.ipv4.tcp_max_syn_backlog = 163840
Sans les syncookies, des valeurs aussi hautes, si elles sont ensuite
suivies par les applications, vont juste remplir ta table de session
avec des SYN_RECV.
> net.ipv4.ip_local_port_range = 1024 65000
OK pour ça.
> net.ipv4.tcp_synack_retries = 1
C'est plutôt agressif. Du point de vue de l'user, surtout s'il est sur
un réseau mobile, cela va se traduire par des pages inaccessibles ou des
images cassées.
> net.ipv4.tcp_fin_timeout = 10
Généralement, on a pas beaucoup de FIN qui traînent.
> net.ipv4.tcp_no_metrics_save = 1
Je le découvre. Vu le nom, je pense que cela signifie que Linux ne va
pas stocker les caractéristiques d'un peer et recommencer de 0. Cela me
semble une mauvaise idée.
> net.ipv4.tcp_max_tw_buckets = 400000
> net.ipv4.tcp_tw_recycle=1
> net.ipv4.tcp_tw_reuse=1
C'est les trucs typiques que l'on met quand on s'affole du nombre de
TIMEWAIT. La première valeur est calculée dynamiquement par le noyau. En
mettre une fixe, c'est prendre le risque de ne plus être adapté dans 2
ans. Si tu n'as pas d'erreur concernant un nombre excessif de timewait,
ce n'est pas la peine de changer cette valeur.
Pour résoudre le problème des TIMEWAIT, il ne faut pas tenter de les
réduire. Ils ne posent problème que quand tu as un nombre limité de
quadruplets. Genre un reverse proxy qui cause avec un backend sur le
port 80. Ça fait environ 65k quadruplets possibles. Avec le TIMEWAIT qui
dure une minute, ça te limite à 1000 connexions/s. Pour corriger ça, tu
peux utiliser différents ports ou différentes IP.
> net.core.somaxconn = 8192
À ne changer que si on a les messages sur les syncookies de manière
régulière. Nécessite aussi une modif côté applicatif.
> fs.file-max = 1310720
Oui.
--
Don't compare floating point numbers just for equality.
- The Elements of Programming Style (Kernighan & Plauger)
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
