caída de las conexiones con tcp_tw_recycle

Question

resumen del problema

estamos teniendo una configuración en la que una gran cantidad (800 a 2400 por segundo (de las conexiones entrantes a una máquina Linux y tenemos un dispositivo NAT entre el cliente y el servidor. por lo que quedan tantos sockets TIME_WAIT en el sistema. Para superar eso, habíamos configurado tcp_tw_recycle en 1, pero eso llevó a una caída en las conexiones entrantes. después de navegar a través de la red encontramos las referencias de por qué fotogramas con tcp_tw_recycle y ocurre el dispositivo NAT.

resolución intentado

luego intentamos establecer tcp_tw_reuse a 1 funcionó bien sin ningún problema con la misma configuración y configuración.

Pero la documentación dice que tcp_tw_recycle y tcp_tw_reuse no deben utilizarse cuando las conexiones que pasan por nodos de estado de TCP, como firewalls, dispositivos NAT o balanceadores de carga pueden ver fotogramas perdidos. Cuantas más conexiones haya, es más probable que vea este problema.

consultas

1) pueden tcp_tw_reuse usarse en este tipo de escenarios? 2) En caso negativo, ¿qué parte del código de linux impide que tcp_tw_reuse se utilice para dicha situación? 3) en general, ¿cuál es la diferencia entre tcp_tw_recycle y tcp_tw_reuse?

Answer 1

Por defecto, cuando ambos tcp_tw_reuse y tcp_tw_recycle están desactivados, el núcleo se asegurará de que las tomas en TIME_WAIT estado permanecerán en ese estado el tiempo suficiente - el tiempo suficiente para asegurarse de que los paquetes que pertenecen a las conexiones futuras no ser confundido paquetes retrasados ​​de la conexión anterior.

Cuando habilita tcp_tw_reuse, los sockets en el estado TIME_WAIT se pueden usar antes de que caduquen, y el núcleo intentará asegurarse de que no haya ninguna colisión con respecto a los números de secuencia TCP. Si habilita tcp_timestamps (a.k.a PAWS, para Protección contra números de secuencia envueltos), se asegurará de que esas colisiones no puedan suceder. Sin embargo, necesita que las marcas de tiempo TCP estén habilitadas en ambos extremos (al menos, eso es lo que entiendo). Ver el definition of tcp_twsk_unique para los detalles sangrientos.

Cuando habilita tcp_tw_recycle, el kernel se vuelve mucho más agresivo y hará suposiciones sobre las marcas de tiempo utilizadas por los hosts remotos. Rastreará la última marca de tiempo utilizada por cada host remoto que tenga una conexión en el estado TIME_WAIT), y permitirá reutilizar un socket si la marca de tiempo se ha incrementado correctamente. Sin embargo, si la marca de tiempo utilizada por el host cambia (es decir, se deforma en el tiempo), el paquete SYN se eliminará en silencio y la conexión no se establecerá (verá un error similar a "tiempo de espera de conexión"). Si desea sumergirse en el código del kernel, el definition of tcp_timewait_state_process podría ser un buen punto de partida.

Ahora, las marcas de tiempo nunca deben retroceder en el tiempo; a menos que:

• se reinicia el host (pero entonces, por el momento se trata de una copia de seguridad, TIME_WAIT toma probablemente habrá expirado, por lo que será un asunto no);
• la dirección IP es reutilizada rápidamente por otra cosa (TIME_WAIT las conexiones se mantendrán un poco, pero otras conexiones probablemente serán afectadas por TCP RST y eso liberará algo de espacio);
• traducción de dirección de red (o un firewall de smarty-pants) está involucrado en el medio de la conexión.

En este último caso, puede tener varios hosts detrás de la misma dirección IP, y por lo tanto, diferentes secuencias de marcas de tiempo (o, dicho de marcas de tiempo son asignados al azar en cada conexión por el servidor de seguridad). En ese caso, algunos hosts no podrán conectarse al azar porque están asignados a un puerto para el que el contenedor TIME_WAIT del servidor tiene una marca de tiempo más nueva. Es por eso que los documentos indican que "los dispositivos NAT o balanceadores de carga pueden comenzar a soltar marcos debido a la configuración".

Algunas personas recomiendan dejar tcp_tw_recycle solo, pero habilitar tcp_tw_reuse y inferior. Estoy de acuerdo :-)