¿Qué es el keepalive de MQTT y el ciclo PINGREQ/PINGRESP?
El keepalive es el mecanismo que permite a un broker MQTT decidir que un cliente silencioso realmente se fue y no solo está callado. Para un ingeniero de control que corre RTUs por celular, es el ajuste que gobierna qué tan rápido se nota un enlace caído y cuánta plática ociosa carga el enlace. Esta página explica qué negocia el intervalo de keepalive, cómo funcionan los paquetes PINGREQ y PINGRESP, y cómo elegir un valor que sobreviva un enlace de telemetría medido y de alta latencia.
Keepalive de MQTT en una línea: El keepalive de MQTT es un intervalo por cliente, acordado en el paquete CONNECT, que fija el hueco más largo permitido entre dos paquetes cualesquiera de ese cliente. Si el cliente no tiene nada más que enviar, debe mandar un PINGREQ antes de que venza el intervalo, y el broker contesta con un PINGRESP. Si el broker no ve paquete alguno en aproximadamente 1.5 veces el intervalo, trata al cliente como desconectado y publica su testamento (last will).
Qué negocia el intervalo de keepalive
El valor de keepalive es un número de 16 bits en segundos que el cliente coloca en su paquete CONNECT, y es un contrato sobre el silencio del cliente, no sobre el tráfico en general. Dice: pase lo que pase, no dejaré transcurrir este intervalo sin enviarle algo al broker. Cualquier paquete cuenta para reiniciar el temporizador, así que un cliente que publica telemetría activamente puede no necesitar nunca un ping dedicado. El ping solo llena los huecos cuando el cliente estaría ocioso.
El mecanismo existe porque una conexión TCP simple puede morir en silencio. Un módem celular pierde cobertura, una entrada NAT del operador expira o un firewall descarta un flujo ocioso, y ningún extremo recibe un FIN limpio. Ambos lados creen que el socket está abierto, un estado a menudo llamado conexión semiabierta. El keepalive le da al broker una fecha límite: si el tráfico prometido deja de llegar, la conexión se presume muerta sin importar lo que crea la pila TCP. Esto es lo que vuelve confiable al testamento (last will), porque el testamento solo se dispara cuando el broker declara muerto al cliente.
Un keepalive de cero desactiva el mecanismo por completo, que casi nunca es lo que usted quiere en un enlace de campo. Con el keepalive apagado, un módem que desaparece deja una sesión zombi en el broker hasta que el propio timeout TCP del sistema operativo la recoja, lo que puede tardar muchos minutos, y el testamento nunca se dispara con prontitud. Para la telemetría SCADA el punto entero es la detección rápida y determinista de nodos muertos, así que un keepalive distinto de cero es efectivamente obligatorio.
Cómo funcionan PINGREQ, PINGRESP y la regla de 1.5x
Cuando el cliente se acerca al final de su intervalo de keepalive sin nada que enviar, emite un PINGREQ, un paquete de control de dos bytes sin carga. El broker responde con un PINGRESP igualmente mínimo. Ese viaje redondo prueba tanto que el cliente está vivo como que la ruta entre ellos todavía lleva tráfico en ambas direcciones. El intercambio es deliberadamente diminuto porque en un plan celular medido cada byte de encabezado es un byte que usted paga, una preocupación que esta página comparte con el overhead de protocolo en telemetría.
El lado del broker de la fecha límite se define como una y media veces el intervalo de keepalive. Si un cliente fija el keepalive en 60 segundos, el broker espera hasta 90 segundos de silencio total antes de declararlo muerto. Esa gracia de 1.5x existe para que un solo ping ligeramente tardío, demorado por un enlace congestionado, no dispare una desconexión falsa. El cliente, por su parte, debe enviar su ping con holgura antes de que expire el intervalo, no en el último momento posible, para que un viaje redondo lento aún caiga dentro de la ventana.
Vale la pena ser preciso sobre la dirección. El keepalive detecta a un cliente que dejó de hablarle al broker; es el cliente quien debe enviar el PINGREQ. El broker no hace ping al cliente. Si usted necesita que el cliente note rápido un broker muerto, eso viene del timeout de lectura del propio cliente y de su expectativa de recibir un PINGRESP, no de sonda alguna iniciada por el broker. Un cliente que envía un PINGREQ y nunca ve un PINGRESP dentro de su propio timeout debe derribar el socket y reconectar, lo que se relaciona con evitar un bucle de reconexión.
Dimensionar el keepalive para un enlace de telemetría celular
Elegir el intervalo es una disyuntiva entre qué tan rápido quiere detectar un nodo muerto y cuánto tráfico ocioso y batería está dispuesto a gastar. Un keepalive corto, digamos 30 segundos, significa que el broker declara muerta a una RTU perdida en unos 45 segundos y el testamento se dispara rápido, lo que es bueno para alarmar. El costo es un viaje redondo de ping por cada 30 segundos de ocio, que en un sitio a batería con presupuesto solar es una carga real, y en un plan medido es un goteo constante de paquetes facturables.
Un keepalive largo, de varios minutos, es amable con el enlace y la batería pero lento para notar una falla, así que un operador puede quedarse mirando un valor viejo por minutos antes de que el punto se marque como malo. También hay un techo duro impuesto por la red que usted no controla: los timeouts de inactividad del NAT del operador y de los firewalls descartan en silencio un flujo que se queda callado demasiado tiempo. Si ese timeout es, por ejemplo, de cuatro minutos, un keepalive más largo que eso garantiza que la red mate la conexión antes de que su ping siquiera se dispare, y el cliente reconecta una y otra vez sin razón visible.
La regla práctica es fijar el keepalive más corto que el timeout de inactividad más corto de la ruta, con margen, y no más corto de lo que exija su requisito de detección de nodos muertos. En un APN privado bien portado puede correr minutos; en celular público a través de NAT agresivo de operador a menudo hay que quedarse por debajo de un par de minutos para mantener el flujo abierto. Como una plataforma SCADA en la nube como Merobix grafica el estado de conexión de cada nodo, usted puede ver qué sitios están rebotando y ajustar el keepalive por sitio en lugar de adivinar un valor para toda la flota.
Preguntas frecuentes
¿Todo cliente MQTT tiene que enviar PINGREQ periódicamente?
Solo cuando de otro modo estaría ocioso. Cualquier paquete que el cliente envía, incluida una publicación, reinicia el temporizador de keepalive, así que un cliente que publica telemetría más seguido que su intervalo de keepalive puede no enviar nunca un PINGREQ dedicado. El ping existe puramente para llenar los huecos de silencio de modo que el broker nunca vea más que el intervalo acordado sin tráfico. Los publicadores parlanchines hacen ping rara vez; un nodo que solo reporta por cambio o en horario lento hace ping seguido.
¿Qué pasa cuando el broker no recibe el keepalive de un cliente?
Si el broker no recibe paquete de ningún tipo en aproximadamente 1.5 veces el intervalo de keepalive negociado, considera al cliente desconectado. Cierra la conexión de red y, si ese cliente registró un testamento (last will), publica el mensaje de testamento en el tópico correspondiente. Para un nodo de borde Sparkplug el testamento es su NDEATH, así que un keepalive perdido es exactamente lo que impulsa la notificación de nodo fuera de línea que llega al host SCADA.
¿El keepalive es lo mismo que el intervalo de reconexión?
No. El keepalive gobierna cómo el broker detecta que una conexión establecida se quedó en silencio. El intervalo de reconexión es un ajuste del lado del cliente para cuánto espera antes de intentar reconectarse tras la caída del enlace. Interactúan, porque un cliente debería reconectarse más rápido de lo que su keepalive importaría, pero son ajustes separados y confundirlos es causa común de un cliente que inunda al broker con reconexiones o tarda demasiado en volver.
Fuentes y lecturas
Referencias primarias de los organismos de normas y reguladores que definen este tema:
- MQTT Version 5.0 Specification - OASIS
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.