¿Cuánto tiempo puedo esperar que una conexión TCP cliente/servidor dure en la naturaleza?Vida de conexión TCP
quiero que se quede permanentemente conectada, pero las cosas suceden, por lo que el cliente tendrá que volver a conectar. ¿En qué punto digo que hay un problema en el código en lugar de que haya algún problema con algún equipo externo?
Estoy de acuerdo con Zan Lynx. No hay garantía, pero puede mantener viva una conexión casi indefinidamente enviando datos sobre ella, suponiendo que no haya problemas de conectividad o de ancho de banda.
lo general he ido para el enfoque de mantener activa a nivel de aplicación, aunque esto no tiene por lo general debido a que ha estado en la especificación del cliente así que he tenido que hacerlo. Pero solo envíe algunos datos breves cada minuto o dos, a los que espera algún tipo de reconocimiento.
Ya sea que cuentes una falta de reconocimiento de que la conexión de haber fracasado depende de usted. En general, esto es lo que hice en el pasado, aunque hubo un caso en el que tuve que esperar tres respuestas fallidas seguidas para desconectar la conexión porque la aplicación al otro extremo de la conexión estaba extremadamente inestable al responder "¿estás ahí? ? " peticiones.
Si falla la conexión, que en algún momento es probable que, incluso con las máquinas en la misma red, a continuación, sólo tratar de restablecerla. Si eso falla una cantidad determinada de veces, entonces tienes un problema. Si su conexión falla persistentemente después de haber sido conectada por un tiempo, entonces nuevamente, usted tiene un problema. Lo más probable es que en ambos casos sea probablemente un problema de red, en lugar de su código, o tal vez un problema con la pila TCP/IP en su máquina (se ha sabido: encontré problemas con esto en una versión anterior de QNX; simplemente caer al azar). Una vez dicho esto, es posible que tenga un problema de software, y la única manera de saberlo con seguridad es adjuntar un depurador o iniciar sesión allí. P.ej. si siempre puedes conectarte con éxito, pero después de un tiempo dejas de recibir ACK, incluso después de volver a conectarte, entonces tal vez tu servidor esté bloqueado o se quede atascado en un bucle o algo así.
Lo que es realmente útil es configurar una serie de pruebas de larga duración bajo una variedad de condiciones de carga, desde simplemente enviar el mantenimiento vivo ¿está usted allí?/Ack solicitudes y respuestas, para golpear absolutamente el servidor.En general, esto le dará más confianza sobre los componentes de su software, y puede ser realmente útil para eliminar algunos problemas realmente extraños que no necesariamente causarán un problema con su conexión, aunque pueden ocasionar problemas con las transacciones que se llevan a cabo. Por ejemplo, una vez escribí un servidor de aplicaciones de telecomunicaciones que proporcionaba servicios, como la traducción de números, y simplemente lo dejábamos en funcionamiento durante días. El caso es que cuando llegara el sábado, durante todo el día, rechazaría todas las solicitudes de llamadas que llegaran, lo que representaba millones de llamadas, y no teníamos idea de por qué. Resultó ser debido a un único error tipográfico en algún código de conversión de fecha que solo causaba un problema los sábados.
Espero que ayude.
No debe realmente importa, debe diseñar su código para volver a conectar automáticamente si ese es el comportamiento deseado.
Realmente no hay manera de saberlo. No hay nada inherente a TCP que haga que la conexión simplemente caiga después de una cierta cantidad de tiempo. Alguien con una conexión confiable podría tener años de actividad, mientras que alguien con una conexión diferente podría tener que reconectarse cada 5 minutos. No hay forma de decir o incluso adivinar.
Elija un valor. Una gota cada hora probablemente esté bien. Diez caídas de conexión inesperadas en 5 minutos probablemente indiquen un problema.
Las conexiones TCP generalmente durarán unas dos horas sin tráfico. Cualquiera de los extremos puede enviar paquetes keep-alive, que son, creo, solo un ACK en el último paquete recibido. Esto generalmente se puede establecer por socket o por defecto en cada conexión TCP.
También es posible mantener el nivel de aplicación. Para un protocolo de estilo de telnet como FTP, SMTP, POP o IMAP, algo como enviar de regreso, nueva línea y obtener un símbolo del sistema.
TCP keepalive es un temporizador que varía por Sistema operativo, por lo que las 2 horas pueden variar en entornos específicos. – benc
Se necesita algo de los datos que van por la conexión periódicamente para mantenerlo vivo - muchos sistemas operativos o cortafuegos dejará caer una conexión inactiva.
Creo que la idea más importante aquí es la teoría frente a la práctica.
La teoría original de que las conexiones no tenían vidas. Si tenía una conexión, permanecía abierta para siempre, incluso si no había tráfico, hasta que un evento hacía que se cerrara.
La nueva teoría es que la mayoría de las versiones del sistema operativo se han convertido en el temporizador de mantenimiento de conexión. Esto significa que las conexiones durarán para siempre, siempre que el sistema en el otro extremo responda a un intercambio ocasional de nivel TCP.
En realidad, muchas conexiones se dará por terminado después de un tiempo, con una variedad de criterios y situaciones.
Dos muy buenos ejemplos son: El cliente remoto se utiliza DHCP, que vence el contrato, y los cambios de dirección IP.
Otro ejemplo son los cortafuegos, que parecen ser cada vez más inteligentes, y pueden identificar el tráfico de mantenimiento frente a datos reales y las conexiones cercanas basadas en cualquier criterio de alto nivel, especialmente el tiempo de inactividad.
Cómo desea implementar la lógica de reconexión depende mucho de su arquitectura, el ambiente de trabajo y sus objetivos de rendimiento.
para siempre si tiene el intervalo KeepAlive correcto, relacionado: http://stackoverflow.com/questions/3907537/keep-alive-tcp-ip-connected-sockets-over-the-internet-when-how-and- how-mucho/5149662 # 5149662 – markmnl
Lo que las personas respondieron en 1999: https://ask.slashdot.org/story/99/09/19/2150236/longest-open-tcp-connection – user3041714