linux - conexiones - netstat time_wait

Desconexión de conexiones con tcp_tw_recycle

Question

resumen del problema

tenemos una configuración en la que hay mucho (800 a 2400 por segundo (de conexiones entrantes a una caja de Linux y tenemos un dispositivo NAT entre el cliente y el servidor. Por lo tanto, quedan muchos zócalos TIME_WAIT en el sistema. Para superar esto, había establecido tcp_tw_recycle en 1, pero eso provocó que se cayeran las conexiones. Después de navegar por la red, encontramos las referencias de por qué sucede la eliminación de marcos con tcp_tw_recycle y dispositivo NAT.

resolución intentada

Luego intentamos configurando tcp_tw_reuse en 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 usarse cuando las Conexiones que pasan por nodos TCP conscientes del estado, como firewalls, dispositivos NAT o balanceadores de carga, pueden ver marcos descartados. Cuantas más conexiones haya, más probable es que veas este problema.

Consultas

1) ¿Se puede usar tcp_tw_reuse en este tipo de escenarios? 2) si no, ¿qué parte del código de linux impide que se use tcp_tw_reuse para tal escenario? 3) en general, ¿cuál es la diferencia entre tcp_tw_recycle y tcp_tw_reuse?

Answer 1

De forma predeterminada, cuando tanto tcp_tw_reuse como tcp_tw_recycle están deshabilitados, el kernel se asegurará de que los sockets en el estado TIME_WAIT permanezcan en ese estado el tiempo suficiente, lo suficiente para asegurarse de que los paquetes que pertenecen a futuras conexiones no se confundirán con los paquetes tardíos de antigua conexion

Cuando habilita tcp_tw_reuse , se pueden usar sockets en el estado TIME_WAIT antes de que caduquen, y el núcleo intentará asegurarse de que no haya colisión con respecto a los números de secuencia TCP. Si habilita tcp_timestamps (también conocido como PAWS, para Protección contra números de secuencia envueltos), se asegurará de que esas colisiones no puedan ocurrir. Sin embargo, necesita que las marcas de tiempo TCP estén habilitadas en ambos extremos (al menos, eso es lo que yo entiendo). Vea la definición de 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 ha aumentado 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á de forma silenciosa 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, la definición de tcp_timewait_state_process podría ser un buen punto de partida.

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

• el host se reinicia (pero luego, cuando vuelva a TIME_WAIT , el socket TIME_WAIT probablemente habrá caducado, por lo que no será un problema);
• la dirección IP se reutiliza rápidamente por algo más (las conexiones TIME_WAIT se mantendrán un poco, pero TCP RST probablemente conectará otras conexiones y eso liberará algo de espacio);
• la traducción de direcciones de red (o un cortafuegos de smarty-pants) está involucrada en la mitad 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, dichas marcas de tiempo están aleatorizadas en cada conexión por el firewall). En ese caso, algunos hosts no podrán conectarse al azar, ya que están asignados a un puerto para el cual el grupo TIME_WAIT del servidor tiene una marca de tiempo más nueva. Es por eso que los documentos le dicen que "los dispositivos NAT o los 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 bajar tcp_fin_timeout . Estoy de acuerdo :-)