Récemment, nous avions un serveur apache qui répondait très lentement en raison des inondations SYN. La solution de contournement était d'activer tcp_syncookies ( net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf).
J'ai posté une question à ce sujet ici si vous voulez plus d'informations.
Après avoir activé les syncookies, nous avons commencé à voir le message suivant dans / var / log / messages toutes les 60 secondes environ:
[84440.731929] possible SYN flooding on port 80. Sending cookies.
Vinko Vrsalovic m'a informé que cela signifie que le backlog de synchronisation est plein, j'ai donc augmenté tcp_max_syn_backlog à 4096. À un moment donné, j'ai également abaissé tcp_synack_retries à 3 (contre 5 par défaut) en émettant sysctl -w net.ipv4.tcp_synack_retries=3. Après cela, la fréquence a semblé baisser, l'intervalle des messages variant entre environ 60 et 180 secondes.
Ensuite, j'ai émis sysctl -w net.ipv4.tcp_max_syn_backlog=65536, mais je reçois toujours le message dans le journal.
Tout au long de tout cela, j'ai regardé le nombre de connexions dans l'état SYN_RECV (en exécutant watch --interval=5 'netstat -tuna |grep "SYN_RECV"|wc -l'), et il ne dépasse jamais environ 240, beaucoup plus bas que la taille du backlog. Pourtant, j'ai un serveur Red Hat qui oscille autour de 512 (la limite sur ce serveur est la valeur par défaut de 1024).
Existe-t-il d'autres paramètres TCP qui limiteraient la taille du backlog ou suis-je en train d'aboyer la mauvaise arborescence? Le nombre de connexions SYN_RECV doit-il être en netstat -tunacorrélation avec la taille du backlog?
Mise à jour
Du mieux que je puisse dire, j'ai affaire à des connexions légitimes ici, netstat -tuna|wc -lautour de 5000. J'ai fait des recherches sur ce sujet aujourd'hui et j'ai trouvé ce post d'un employé de last.fm, qui a été plutôt utile.
J'ai également découvert que tcp_max_syn_backlog n'a aucun effet lorsque les syncookies sont activés (selon ce lien )
Donc, comme étape suivante, j'ai défini ce qui suit dans sysctl.conf:
net.ipv4.tcp_syn_retries = 3
# default=5
net.ipv4.tcp_synack_retries = 3
# default=5
net.ipv4.tcp_max_syn_backlog = 65536
# default=1024
net.core.wmem_max = 8388608
# default=124928
net.core.rmem_max = 8388608
# default=131071
net.core.somaxconn = 512
# default = 128
net.core.optmem_max = 81920
# default = 20480
J'ai ensuite configuré mon test de temps de réponse, exécuté sysctl -pet désactivé les syncookies par sysctl -w net.ipv4.tcp_syncookies=0.
Après cela, le nombre de connexions dans l'état SYN_RECV est resté autour de 220-250, mais les connexions ont recommencé à retarder. Une fois que j'ai remarqué ces retards, j'ai réactivé les syncookies et les retards se sont arrêtés.
Je pense que ce que je voyais était toujours une amélioration par rapport à l'état initial, mais certaines demandes ont toujours été retardées, ce qui est bien pire que l'activation des syncookies. Il semble donc que je suis bloqué avec eux activés jusqu'à ce que nous puissions obtenir plus de serveurs en ligne pour faire face à la charge. Même alors, je ne suis pas sûr de voir une raison valable de les désactiver à nouveau car ils ne sont envoyés (apparemment) que lorsque les tampons du serveur sont pleins.
Mais le backlog de synchronisation ne semble pas être plein avec seulement ~ 250 connexions dans l'état SYN_RECV! Est-il possible que le message d'inondation SYN soit un hareng rouge et que ce soit autre chose que le syn_backlog qui se remplit?
Si quelqu'un a d'autres options de réglage que je n'ai pas encore essayées, je serais plus qu'heureux de les essayer, mais je commence à me demander si le paramètre syn_backlog n'est pas appliqué correctement pour une raison quelconque.