Recientemente tuvimos un servidor apache que respondía muy lentamente debido a las inundaciones de SYN. La solución para esto era habilitar tcp_syncookies ( net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf).
Publiqué una pregunta sobre esto aquí si quieres más información.
Después de habilitar las syncookies, comenzamos a ver el siguiente mensaje en / var / log / messages aproximadamente cada 60 segundos:
[84440.731929] possible SYN flooding on port 80. Sending cookies.
Vinko Vrsalovic me informó que esto significa que el backlog de sincronización se está llenando, así que elevé tcp_max_syn_backlog a 4096. En algún momento también bajé tcp_synack_retries a 3 (en lugar del valor predeterminado de 5) al emitir sysctl -w net.ipv4.tcp_synack_retries=3. Después de hacer esto, la frecuencia pareció disminuir, y el intervalo de mensajes varió entre aproximadamente 60 y 180 segundos.
A continuación, emití sysctl -w net.ipv4.tcp_max_syn_backlog=65536, pero sigo recibiendo el mensaje en el registro.
A lo largo de todo esto, he estado observando la cantidad de conexiones en estado SYN_RECV (ejecutando watch --interval=5 'netstat -tuna |grep "SYN_RECV"|wc -l'), y nunca supera los 240, mucho más que el tamaño de la acumulación. Sin embargo, tengo un servidor Red Hat que ronda los 512 (el límite en este servidor es el predeterminado de 1024).
¿Hay alguna otra configuración de TCP que limitaría el tamaño del trabajo atrasado o estoy ladrando el árbol equivocado? ¿Debería netstat -tunacorrelacionarse el número de conexiones SYN_RECV con el tamaño de la acumulación?
Actualizar
Lo mejor que puedo decir es que estoy lidiando con conexiones legítimas aquí, netstat -tuna|wc -lronda los 5000. He estado investigando esto hoy y encontré esta publicación de un empleado de last.fm, que ha sido bastante útil.
También descubrí que tcp_max_syn_backlog no tiene efecto cuando las syncookies están habilitadas (según este enlace )
Entonces, como paso siguiente, configuro lo siguiente en 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
Luego configuré mi prueba de tiempo de respuesta, ejecuté sysctl -py deshabilité syncookies por sysctl -w net.ipv4.tcp_syncookies=0.
Después de hacer esto, el número de conexiones en el estado SYN_RECV aún permanecía alrededor de 220-250, pero las conexiones comenzaban a retrasarse nuevamente. Una vez que noté estos retrasos, volví a habilitar las syncookies y los retrasos se detuvieron.
Creo que lo que estaba viendo todavía era una mejora con respecto al estado inicial, sin embargo, algunas solicitudes aún se retrasaron, lo que es mucho peor que tener habilitadas las sincookies. Por lo tanto, parece que estoy atascado con ellos habilitados hasta que podamos obtener algunos servidores más en línea para hacer frente a la carga. Incluso entonces, no estoy seguro de ver una razón válida para deshabilitarlos nuevamente, ya que solo se envían (aparentemente) cuando los búferes del servidor se llenan.
¡Pero la acumulación de sincronización no parece estar llena con solo ~ 250 conexiones en el estado SYN_RECV! ¿Es posible que el mensaje de inundación SYN sea una pista falsa y sea algo más que el syn_backlog que se está llenando?
Si alguien tiene otras opciones de ajuste que aún no he probado, estaría encantado de probarlas, pero estoy empezando a preguntarme si la configuración syn_backlog no se aplica correctamente por alguna razón.