Configuración DEL TIEMPO DE ESPERA TCP

Estamos tratando de ajustar una aplicación que acepta mensajes a través de TCP y también utiliza TCP para algunos de sus mensajes internos. Durante las pruebas 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 muchas conexiones TCP en estado TIME_WAIT y alguien sugirió bajar la variable de entorno TIME_WAIT de su valor predeterminado de 60 segundos a 30.

De lo que entiendo , la configuración TIME_WAIT establece esencialmente el tiempo que un recurso TCP se pone a disposición del sistema de nuevo después de que se cierra la conexión.

No soy un "chico de la red" y sé muy poco sobre estas cosas. Necesito mucho de lo que hay en ese post enlazado, pero "atónito" un poco.

  • Creo que entiendo por qué el valor TIME_WAIT no se puede establecer en 0, pero ¿se puede establecer de forma segura en 5? ¿Qué hay de 10? ¿Qué determina un ajuste "seguro" para este valor?
  • ¿Por qué es el valor predeterminado para esto ¿valor 60? Supongo que la gente mucho más inteligente que yo tenía una buena razón para seleccionar esto como un defecto razonable.
  • ¿Qué más debo saber sobre los riesgos y beneficios potenciales de anular este valor?
Author: Mr Fooz, 2008-12-03
Source

7 answers

Una conexión TCP es 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 apagado de la sesión es porque todavía puede haber paquetes vivos en la red en su camino a usted (o de usted que puede solicitar una respuesta de algún tipo). Si tuviera que volver a crear esa misma tupla y uno de esos paquetes apareciera, se trataría como un paquete válido para su conexión (y probablemente causaría un error debido a la secuenciación).

Así que el tiempo 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 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 pertenecientes a encarnaciones anteriores de esa tupla estarán muertos.

Que generalmente dicta el valor mínimo que debe usar. La edad máxima de paquetes es dictada por la red propiedades, un ejemplo es que los tiempos de vida de los satélites son más altos que los tiempos de vida de LAN, ya que los paquetes tienen mucho más que ir.

 89
Author: paxdiablo,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-06-14 01:43:35

Normalmente, solo el endpoint que emite un 'cierre activo' debe entrar en el estado TIME_WAIT. Por lo tanto, si es posible, haga que sus clientes emitan el cierre activo que dejará el TIME_WAIT en el cliente y NO en el servidor.

Ver 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 más detalles (el posterior también explica por qué no siempre es posible debido al diseño del protocolo que no toma TIME_WAIT en consideración).

 19
Author: Len Holgate,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-06-24 17:36:49

Pax tiene razón sobre las razones de TIME_WAIT, y por qué debe tener cuidado al bajar 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 haga esto, realmente no le importará el tiempo de espera para los enchufes individuales.

Para los sockets de escucha, puede usar SO_REUSEADDR para permitir que el socket de escucha se vincule a pesar de que los sockets TIME_WAIT estén sentados alrededor.

 9
Author: Darron,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-12-03 14:05:28

En Windows, usted puede cambiarlo a través del registro : 

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

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters]
"TcpTimedWaitDelay"=dword:0000001E
 3
Author: Synetech,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-05-10 23:07:59

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

Eliminar el valor, particularmente para los usuarios conectados a VPN, puede resultar en la recreación constante de túneles proxy en la conexión saliente. Con la configuración predeterminada de Netscaler (XenServer), que es menor que la configuración predeterminada de Linux, Chrome a veces tendrá que volver a crear el túnel proxy una docena de veces para recuperar una página web. Las aplicaciones que no se reintentan, como Maven y Eclipse P2, simplemente fallan.

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

 2
Author: andrew glynn,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-06-02 19:38:10

He estado probando una aplicación de servidor (en linux) usando un programa de prueba con 20 hilos.

En 959.000 ciclos de conexión / cierre tuve 44.000 conexiones fallidas y muchos miles de sockets en TIME_WAIT.

Puse SO_LINGER a 0 antes de la llamada de cierre y en las ejecuciones posteriores del programa de prueba no tenía fallos de conexión y menos de 20 sockets en TIME_WAIT.

 0
Author: Michael Taylor,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-04-28 06:54:48

TIME_WAIT podría no ser el culpable. 

int listen(int sockfd, int backlog);

De acuerdo con Unix Network Programming Volume1, backlog se define como la suma de la cola de conexión completada y la cola de conexión incompleta.

Digamos que el backlog es 5. Si tiene 3 conexiones completadas (estado ESTABLECIDO) 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 está causando la degradación.

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

 -1
Author: yogman,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-12-03 18:04:41