ALGUNA TEORÍA
He estado leyendo un poco sobre tcp TIME-WAIT(aquíyallá) y lo que leí es que es un valor establecido en 2 x MSL(vida máxima del segmento) que mantiene una conexión en la "tabla de conexiones" por un tiempo para garantizar eso,"antes de que se te permita crear una conexión con la misma tupla, todos los paquetes pertenecientes a encarnaciones anteriores de esa tupla estarán muertos".
Dado que los segmentos recibidos (aparte de SYN en circunstancias específicas) mientras una conexión está activa TIME-WAITo ya no existe se descartarían, ¿por qué no cerrar la conexión de inmediato?
P1: ¿Es porque hay menos procesamiento involucrado al tratar con segmentos de conexiones antiguas y menos procesamiento para crear una nueva conexión en la misma tupla TIME-WAIT(es decir, hay beneficios de rendimiento)?
Si la explicación anterior no es válida, la única razón por la que veo que TIME-WAITes útil sería si un cliente envía un mensaje SYNpara una conexión antes de enviar los segmentos restantes para una conexión anterior en la misma tupla, en cuyo caso el receptor volvería a abrir el conexión pero luego obtiene segmentos defectuosos y tendría que terminarla.
P2: ¿Es correcto este análisis?
P3: ¿Existen otros beneficios al usar TIME-WAIT?
ALGUNA PRÁCTICA
He estado mirando los gráficos de munin en un servidor de producción que administro. Acá hay uno:
Como puedes ver hay más conexiones en TIME-WAIT, ESTABLISHEDalrededor del doble la mayor parte del tiempo, en algunas ocasiones cuatro veces más.
P4: ¿Esto tiene un impacto en el rendimiento?
P5: Si es así, ¿es prudente/recomendable reducir el TIME-WAITvalor (y qué hacer)?
P6: ¿Es normal esta relación de TIME-WAIT/ ESTABLISHEDconexiones? ¿Podría esto estar relacionado con intentos de conexión maliciosos?
Respuesta1
En resumen, no te preocupes TIME_WAIT. Los gastos generales son casi nulos y normalmente no plantean problemas.
En un servidor ocupado, es posible que se agoten los puertos y, en ese caso, existe la opción sysctl de net.ipv4.tcp_tw_reuse = 1, que permite al kernel reutilizar puertos antiguos que todavía están disponibles TIME_WAITsegún sea necesario.
TIME_WAIT es parte de la especificación TCP y está ahí para capturar paquetes que aún pueden estar en tránsito (recuerde, no todas las conexiones son confiables, y eso es lo que TCP pretendía resolver). El valor del tiempo de espera puede ser muy alto para la mayoría de los usos modernos, pero normalmente no interfiere con nada más que la salida de netstat.
Si usted mismo tiene el control del socket y está seguro de que no está esperando datos (por ejemplo, es el remitente final o no le importa una respuesta), puede cerrar el socket después de configurar la SO_NOLINGERopción, que terminará la conexión con un RSTe inmediatamente descartará el socket.
Entonces tus preguntas:
P1, P2, P3: está ahí para recopilar paquetes tardíos, "por si acaso", porque los enlaces pueden no ser confiables. Es parte de la especificación, evita la pérdida de paquetes y ajustarlo no tiene ningún beneficio real.
P4: No
P5: No te preocupes, tienes la opción de forzar la reutilización de estos enchufes si es necesario.
P5: TIME_WAITy ESTABLISHEDno están correlacionados, aparte de que cuantas más conexiones de corta duración tenga, mayor será esa relación. Podría deberse a algo malicioso, pero no es un indicador más de lo que lo sería una "actividad excesiva de la red".
Respuesta2
Algunas respuestas de mi experiencia limitada con TIME_WAIT:
1/2/3) Ver estoEntonces preguntayesta páginapara una buena explicación de TIME_WAIT. Es menos un problema de rendimiento y más una calidad de servicio garantizar que todos los paquetes TCP en una conexión se reciban correctamente.
4/5) Un problema de rendimiento relacionado con TIME_WAIT es que en un servidor muy ocupado, eventualmente puedes quedarte sin conexiones disponibles si tienes demasiadas en el estado TIME_WAIT. Si se encuentra con este problema, puede intentar reducir el valor de TIME_WAIT, pero esto puede caer en la categoría de ajuste "Sé lo que estoy haciendo". Veresta pregunta SOpara algunos detalles más.
6) El valor predeterminado de TIME_WAIT "debería" ser de alrededor de 240 (o el doble del MSL del paquete de 120). Por lo tanto, la proporción de conexiones establecidas/en espera dependerá de su tasa de conexión entrante y de cuánto tiempo permanecen abiertas. Por ejemplo, verifiqué algunos de mis servidores ocupados y la proporción osciló entre 1,3 y 400, todo lo cual consideraría normal según el servidor y el tráfico que recibe.