Hispanopedia Wiki
Articulo de referencia

Mantener vivo

Un keepalive ( KA ) es un mensaje que un dispositivo envía a otro para comprobar que el enlace entre ambos está funcionando o para evitar que se interrumpa. Descripción Una vez ...

Hispanopedia WikiContenido en espanolLectura gratuita

Un keepalive ( KA ) es un mensaje que un dispositivo envía a otro para comprobar que el enlace entre ambos está funcionando o para evitar que se interrumpa.

Descripción

Una vez establecida una conexión TCP , esta se considera válida hasta que una de las partes la cierre. Una vez que la conexión entra en estado de conexión, teóricamente puede permanecer conectada indefinidamente. En realidad, la conexión no dura indefinidamente. Muchos sistemas de firewall o NAT cierran una conexión si no ha habido actividad durante un cierto período de tiempo. La señal Keep Alive se puede usar para evitar que los hosts intermedios cierren la conexión por inactividad. También es posible que un host deje de estar escuchando (por ejemplo, debido a un fallo de la aplicación o del sistema ). En este caso, la conexión se cierra, pero no FINse envía ningún paquete KeepAlive. En este caso, se puede usar un paquete KeepAlive para consultar la conexión y comprobar si sigue intacta.

La señal de mantenimiento de conexión se envía a intervalos predefinidos y desempeña un papel importante en Internet . Si tras el envío de la señal no se recibe respuesta, se asume que el enlace está caído y los datos futuros se enrutarán por otra ruta hasta que se restablezca la conexión. La señal de mantenimiento de conexión también puede utilizarse para indicar a la infraestructura de Internet que debe mantenerse la conexión. Sin esta señal, los enrutadores intermedios con NAT habilitado pueden interrumpir la conexión tras un tiempo de espera agotado.

Dado que su único propósito es detectar enlaces que no funcionan o indicar conexiones que deben mantenerse, los mensajes keepalive suelen ser cortos y no consumen mucho ancho de banda . Sin embargo, su formato preciso y sus términos de uso dependen del protocolo de comunicación .

TCP keepalive

Las funciones de mantenimiento de conexión del Protocolo de Control de Transmisión (TCP) son opcionales y, si se incluyen, deben estar desactivadas por defecto. [ 1 ]

Sondear paquetes TCP

Un paquete keepalive adecuado (a veces llamado sonda ) no contiene datos. Excepcionalmente se tolera habilitar opcionalmente el uso de 1 "octeto basura" en el paquete keepalive, pero esto es solo para cumplir con implementaciones TCP erróneas. [ 1 ] En una red Ethernet , los paquetes keepalive dan como resultado tramas de tamaño mínimo (64 bytes [ 2 ] ).

Algoritmo y configuración de Keepalive

En cuanto a TCP keepalive, RFC 1122 solo describe las condiciones bajo las cuales se puede enviar un paquete keepalive, qué contiene el paquete, cómo debe comportarse el host de destino ( respuesta ACK ) al recibirlo y que la transmisión de paquetes ACK sin datos no es confiable, incluso en TCP (lo que implica que una conexión puede seguir operativa, pero que un intermediario podría estar descartando paquetes ACK sin datos). Sin embargo, además de un intervalo configurable (o al menos 2 horas por defecto) en el que se pueden enviar paquetes keepalive, no se prescribe ningún algoritmo en particular. [ 1 ] En consecuencia, los sistemas operativos varían en la forma en que implementan TCP keepalive. Por ejemplo, Windows Server 2008 y Windows Vista utilizan una implementación simple compatible con RFC que envía un paquete keepalive en un único intervalo de tiempo configurable; [ 3 ] no hacen distinción de intervalo de tiempo entre el primer paquete keepalive enviado en la conexión y los enviados posteriormente si no se recibió respuesta del host de destino. Mientras que en Linux, se utilizan tres parámetros [ 4 ] para configurar TCP keepalive:

  • Un retardo de mantenimiento de conexión que indica después de cuánto tiempo se enviará el primer paquete de mantenimiento de conexión en una conexión aparentemente inactiva.
  • Un intervalo de mantenimiento de conexión, que es la duración entre dos retransmisiones sucesivas de mantenimiento de conexión, si no se recibe la confirmación de la transmisión anterior.
  • Un contador de sondeos keepalive, que es el número máximo de paquetes keepalive consecutivos sin respuesta antes de declarar que el extremo remoto no está disponible.

Comportamiento general

Cuando dos hosts están conectados a través de una red mediante TCP/IP , los paquetes TCP keepalive se pueden utilizar para determinar si la conexión sigue siendo válida y finalizarla si es necesario.

La mayoría de los hosts que admiten TCP también admiten TCP keepalive. Cada host (o par) envía periódicamente un paquete TCP a su par para solicitar una respuesta. Si se envían varios paquetes keepalive y no se recibe respuesta ( ACK ), el host emisor finalizará la conexión. Si una conexión se ha finalizado debido a un tiempo de espera agotado de TCP keepalive y el otro host envía un paquete para la conexión anterior, el host que finalizó la conexión enviará un paquete con el indicador RST activado para indicar al otro host que la conexión anterior ya no está activa. Esto obligará al otro host a finalizar su conexión para que se pueda establecer una nueva.

Comportamiento predeterminado en el mundo real

Normalmente, los paquetes TCP keepalive se envían cada 45 o 60 segundos en una conexión TCP inactiva, y la conexión se cierra después de que se pierden 3 ACK consecutivos. Esto varía según el host; por ejemplo, por defecto, los PC con Windows envían el primer paquete TCP keepalive después de 7200000 ms (2 horas), y luego envían 5 keepalives a intervalos de 1000 ms, cerrando la conexión si no hay respuesta a ninguno de los paquetes keepalive . Los hosts Linux envían el primer paquete TCP Keepalive después de 2 horas (por defecto desde Linux 2.2), y luego envían 9 sondas keepalive (por defecto desde Linux 2.2) a intervalos de 75 segundos (por defecto desde Linux 2.4), cerrando la conexión si no hay respuesta a ninguno de los paquetes Keepalive. [ 5 ]

Mantenerse con vida en capas superiores

Dado que la función keep-alive de TCP es opcional, varios protocolos (por ejemplo, SMB [ 6 ] y TLS [ 7 ] ) implementan su propia función keep-alive sobre TCP. También es común que los protocolos que mantienen una sesión sobre un protocolo sin conexión , por ejemplo, OpenVPN sobre UDP [ 8 ], implementen su propia función keep-alive.

Conceptos similares

Mantenimiento de la conexión HTTP

El Protocolo de Transferencia de Hipertexto (HTTP) utiliza la palabra clave keep-aliveen el Connectionencabezado para indicar que la conexión debe mantenerse abierta para mensajes posteriores (este es el valor predeterminado en HTTP 1.1, pero en HTTP 1.0 el valor predeterminado era usar una nueva conexión para cada par de solicitud/respuesta). [ 9 ] A pesar del nombre similar, esta función no tiene ninguna relación.

Véase también

Referencias

  1. 1 2 3 Braden, Robert T. (octubre de 1989). Braden, R. (ed.). "Requisitos para hosts de Internet: capas de comunicación" . IETF . doi : 10.17487/RFC1122 . Recuperado el 8 de noviembre de 2013 .
  2. ↑ Norma IEEE para Ethernet . Norma IEEE para Ethernet, 802.3-2015 – sección uno. 2016. pág. 108. doi : 10.1109/IEEESTD.2016.7428776 . ISBN  978-1-5044-0078-7.
  3. ↑ "Entradas adicionales del registro" . learn.microsoft.com . 5 de septiembre de 2011. Consultado el 13 de julio de 2025 .
  4. ↑ "Uso de TCP keepalive en Linux" . tldp.org . Consultado el 29 de julio de 2016 .
  5. ↑ "tcp(7) - Página del manual de Linux" . Consultado el 14 de agosto de 2024 .
  6. ↑ "Estándar de protocolo para un servicio NetBIOS en un transporte TCP/UDP: conceptos y métodos" . IETF . Marzo de 1987. doi : 10.17487/RFC1001 . Consultado el 18 de junio de 2015 .
  7. ↑ Williams, Michael; Tüxen, Michael; Seggelmann, Robin (febrero de 2012). "Extensión de latido de seguridad de la capa de transporte (TLS) y seguridad de la capa de transporte de datagramas (DTLS)" . IETF . doi : 10.17487/RFC6520 . Consultado el 18 de junio de 2015 .
  8. ↑ "Página del manual de OpenVPN" . Consultado el 18 de junio de 2015 .
  9. ↑ "Discurso sobre HTTP Keep Alive por Jim Driscoll" . Archivado del original el 13 de agosto de 2010.