Configuración TIME_WAIT TCP

Question

Estamos tratando de sintonizar una aplicación que acepte mensajes a través de TCP y que también use TCP para algunos de sus mensajes internos. Durante la prueba de carga, notamos que el tiempo de respuesta se degrada significativamente (y luego se detiene por completo) a medida que se realizan más solicitudes simultáneas al sistema. Durante este tiempo, vemos una gran cantidad de conexiones TCP en TIME_WAIT de estado y alguien sugirió la reducción de la variable TIME_WAIT medio ambiente desde que es por defecto de 60 segundos a 30.

De what I understand, el ajuste TIME_WAIT esencialmente establece el tiempo se pone a disposición un recurso TCP al sistema nuevamente después de que se cierra la conexión.

No soy un "chico de la red" y sé muy poco acerca de estas cosas. Necesito mucho de lo que está en esa publicación vinculada, pero "embrutecerme" un poco.

• creo que entiendo por qué el valor TIME_WAIT no puede ajustarse a 0, pero puede que con seguridad se establece en 5? ¿Qué hay de 10? ¿Qué determina una configuración "segura" para este valor?
• ¿Por qué el valor predeterminado es 60? Supongo que la gente mucho más inteligente que yo tenía buenas razones para seleccionar esto como un incumplimiento razonable.
• ¿Qué más debería saber sobre los posibles riesgos y beneficios de anular este valor?

Answer 1

Una conexión TCP está especificada por la tupla (IP de origen, puerto de origen, IP de destino, puerto de destino).

La razón por la que hay un estado TIME_WAIT después del cierre de la sesión es porque todavía puede haber paquetes en vivo en la red en su camino hacia usted (o de usted que puede solicitar una respuesta de algún tipo). Si tuviera que volver a crear la misma tupla y apareciera uno de esos paquetes, sería tratado como un paquete válido para su conexión (y probablemente cause un error debido a la secuencia).

Por lo tanto, la hora TIME_WAIT generalmente se establece para duplicar la edad máxima de los paquetes. Este valor es la edad máxima a la que se les permitirá llegar a sus paquetes antes de que la red los descarte.

Eso garantiza que, antes de que se le permita crear una conexión con la misma tupla, todos los paquetes que pertenecen a las encarnaciones previas de esa tupla estarán muertos.

Eso generalmente dicta el valor mínimo que debe usar. La máxima duración del paquete viene dictada por las propiedades de la red, un ejemplo es que los tiempos de vida de los satélites son más altos que los tiempos de vida de la LAN, ya que los paquetes tienen mucho más que recorrer.

Answer 2

Pax es correcto acerca de los motivos de TIME_WAIT, y por qué debe tener cuidado con la reducción de la configuración predeterminada.

Una mejor solución es variar los números de puerto utilizados para el extremo de origen de sus sockets. Una vez que hagas esto, no te importará el tiempo de espera para los sockets individuales.

Para sockets de escucha, puede usar SO_REUSEADDR para permitir que el zócalo de escucha se vincule a pesar de los zócalos TIME_WAIT que están alrededor.

Answer 3

Normalmente, solo el punto final que emite un 'cierre activo' debe pasar al estado TIME_WAIT. Entonces, si es posible, haga que sus clientes emitan el cierre activo que dejará el TIME_WAIT en el cliente y NO en el servidor.

Consulte aquí: http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html y http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/ para obtener más información (la última también explica por qué no siempre es posible debido al diseño de protocolo que no toma en cuenta TIME_WAIT).

Answer 4

TIME_WAIT podría no ser el culpable.

int listen(int sockfd, int backlog); 

De acuerdo a la programación Unix Red Volumen 1, la cartera se define como la suma de cola de conexión completa y cola de conexión incompleta.

Digamos que el backlog es 5. Si tiene 3 conexiones completadas (estado ESTABLISHED), y 2 conexiones incompletas (estado SYN_RCVD), y hay otra solicitud de conexión con SYN. La pila TCP simplemente ignora el paquete SYN, sabiendo que será retransmitido en otro momento. Esto podría estar causando la degradación.

Al menos eso es lo que he estado leyendo. ;)

Answer 5

En Windows, can change que through the registry:

; Set the TIME_WAIT delay to 30 seconds (0x1E) 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters] 
"TcpTimedWaitDelay"=dword:0000001E 

Answer 6

he sido pruebas de carga de una aplicación de servidor (en Linux) mediante el uso de un programa de prueba con 20 hilos.

En 959,000 ciclos de conexión/cierre tuve 44,000 conexiones fallidas y muchos miles de tomas en TIME_WAIT.

Establecí SO_LINGER en 0 antes de la llamada de cierre y en las ejecuciones posteriores del programa de prueba no hubo fallas de conexión y menos de 20 sockets en TIME_WAIT.

Answer 7

configurar el tcp_reuse es más útil que cambiar time_wait, siempre que tenga el parámetro (kernels 3.2 y superior, desafortunadamente que descalifica todas las versiones de RHEL y XenServer).

Al soltar el valor, especialmente para usuarios conectados a VPN, puede tener como resultado la recreación constante de túneles proxy en la conexión de salida. Con la configuración predeterminada de Netscaler (XenServer), que es inferior a la configuración predeterminada de Linux, Chrome a veces tendrá que volver a crear el túnel proxy hasta una docena de veces para recuperar una página web. Las aplicaciones que no se vuelven a intentar, como Maven y Eclipse P2, simplemente fallan.

El motivo original para el parámetro (evitar la duplicación) fue hecho redundante por un TCP RFC que especifica la inclusión de la marca de tiempo en todas las solicitudes TCP.