La latencia de un broker MQTT por región importa porque la distancia física entre tus dispositivos y el broker fija un mínimo que ningún ajuste puede eliminar. Esta guía explica de dónde viene la latencia MQTT, muestra cómo medir los tiempos de ida y vuelta desde tus propias sedes con un script breve y ofrece un método práctico para elegir dónde debe ejecutarse tu broker.
De dónde viene la latencia MQTT
La latencia de extremo a extremo de un mensaje MQTT, desde que un sensor publica hasta que un suscriptor lo recibe, es la suma de varias partes:
| Componente | Qué es | Depende de |
|---|---|---|
| Red de acceso | Del dispositivo a internet: Wi-Fi, Ethernet, celular, satélite | Condiciones de radio, operador, hardware de la pasarela |
| Propagación | La luz viajando por fibra hasta el broker y de vuelta | Distancia física y ruta |
| Enrutamiento y peering | Saltos entre redes | Interconexiones entre ISP y proveedor cloud |
| Procesamiento del broker | Análisis, autorización, comparación con suscripciones, entrega | Carga del broker, plan, fan-out |
| Ruta del suscriptor | Del broker a la aplicación consumidora | Dónde se ejecuta el suscriptor |
| Comportamiento del cliente | Buffering, agrupación, acuses de QoS | Configuración de la librería y tu código |
La elección de región afecta sobre todo a la propagación y al enrutamiento. La luz en la fibra óptica viaja aproximadamente a dos tercios de su velocidad en el vacío, lo que equivale a alrededor de 1 milisegundo de tiempo de ida y vuelta por cada 100 kilómetros de recorrido de fibra, antes de cualquier desvío de enrutamiento. Las rutas de red reales rara vez son líneas rectas, así que los tiempos medidos son mayores. Un dispositivo en un continente que habla con un broker en otro siempre pagará esa distancia en cada ida y vuelta.
El establecimiento de la conexión multiplica las idas y vueltas
La latencia duele más al conectar. Antes de que fluya el primer mensaje, un cliente MQTT protegido con TLS necesita un handshake TCP, un handshake TLS y un intercambio MQTT CONNECT/CONNACK. TLS 1.3 necesita una ida y vuelta para su handshake; TLS 1.2, normalmente dos. Eso supone varias idas y vueltas antes de la primera publicación, algo que se nota en los dispositivos que despiertan del modo de sueño profundo, se conectan, publican y se desconectan. En los dispositivos siempre conectados, el coste del establecimiento se paga una vez y pesa más el tiempo de ida y vuelta en régimen estable.
El QoS añade idas y vueltas de confirmación
Una publicación QoS 0 es de tipo "disparar y olvidar". QoS 1 espera un PUBACK y QoS 2 necesita un intercambio de cuatro pasos. El mensaje llega a los suscriptores más o menos al mismo tiempo, pero el publicador pasa más tiempo esperando, lo que importa en clientes con ventanas de mensajes en tránsito limitadas. Nuestro artículo sobre los niveles de QoS de MQTT cubre estos compromisos.
Cómo medir la latencia MQTT desde tus sedes
Los mapas genéricos de latencia son un punto de partida útil, pero lo que cuenta son tus propias mediciones desde tus propias sedes. Mide en tres niveles.
Nivel 1: tiempo de ida y vuelta de la red
Desde una máquina en la sede de los dispositivos, ejecuta:
# Ida y vuelta ICMP (algunas redes pueden bloquearlo)
ping -c 20 broker.connectmq.com
# Vista salto a salto de la ruta, útil para detectar desvíos
mtr --report --report-cycles 20 broker.connectmq.com
# Tiempo de conexión TCP al puerto TLS de MQTT
time nc -z -w 5 broker.connectmq.com 8883
La línea de nc solo mide una conexión TCP en bruto; el script a nivel MQTT que viene a continuación da las cifras más útiles de TLS y del protocolo.
Nivel 2: conexión MQTT e ida y vuelta de una publicación
Este script en Python, con paho-mqtt 2.x, mide el tiempo hasta el CONNACK sobre TLS y después la ida y vuelta de mensajes publicados y recibidos por el mismo cliente. Ejecútalo desde cada sede que te interese.
# mqtt_rtt.py - mide el tiempo de conexión MQTT y la ida y vuelta publicar/recibir
import statistics
import sys
import threading
import time
import uuid
import paho.mqtt.client as mqtt
HOST = sys.argv[1] if len(sys.argv) > 1 else "broker.connectmq.com"
PORT = 8883
SAMPLES = 30
run_id = uuid.uuid4().hex[:8]
TOPIC = f"connectmq/demo/{run_id}/rtt"
connected = threading.Event()
received = threading.Event()
rtts = []
sent_at = 0.0
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(TOPIC, qos=0)
def on_subscribe(client, userdata, mid, reason_codes, properties):
connected.set()
def on_message(client, userdata, msg):
rtts.append((time.perf_counter() - sent_at) * 1000)
received.set()
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"rtt-{run_id}", protocol=mqtt.MQTTv5)
# Para un broker privado, añade las credenciales:
# client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.on_connect = on_connect
client.on_subscribe = on_subscribe
client.on_message = on_message
t0 = time.perf_counter()
client.connect(HOST, PORT, keepalive=30)
client.loop_start()
if not connected.wait(15):
sys.exit("could not connect and subscribe")
print(f"connect + TLS + subscribe: {(time.perf_counter() - t0) * 1000:.0f} ms")
for i in range(SAMPLES):
received.clear()
sent_at = time.perf_counter()
client.publish(TOPIC, str(i), qos=0)
if not received.wait(5):
print("timeout on sample", i)
time.sleep(0.2) # muy por debajo de 10 msg/s en el broker público
client.loop_stop()
client.disconnect()
if rtts:
rtts.sort()
print(f"publish->receive RTT over {len(rtts)} samples: "
f"median {statistics.median(rtts):.1f} ms, "
f"p90 {rtts[int(len(rtts) * 0.9) - 1]:.1f} ms, max {rtts[-1]:.1f} ms")
Como el mismo cliente publica y recibe, el resultado es una ida y vuelta completa a través del broker, lo que es una buena aproximación de la latencia entre dispositivo y backend cuando tu backend está cerca del broker. El script usa el servidor MQTT público gratuito con un topic aleatorio, así que funciona sin cuenta; úsalo solo para pruebas, no para datos de producción.
Nivel 3: regiones candidatas que controlas
Para comparar ubicaciones antes de comprometerte, arranca una pequeña máquina virtual en cada región cloud candidata, instala Mosquitto con TLS y ejecuta el mismo script contra cada una desde cada sede. Así obtienes una matriz de cifras reales en lugar de suposiciones.
Cómo convertir las mediciones en una decisión
Recoge los resultados en una tabla como esta, usando medianas y un percentil alto en lugar de pings sueltos:
| Sede | Región A mediana / p90 | Región B mediana / p90 | Región C mediana / p90 | Número de dispositivos |
|---|---|---|---|---|
| Planta 1 | ... | ... | ... | ... |
| Planta 2 | ... | ... | ... | ... |
| Almacén | ... | ... | ... | ... |
| Servicios backend | ... | ... | ... | n/a |
Después aplica estas reglas:
- Pondera por importancia, no solo por número de dispositivos. Un lazo de control en una sede puede importar más que cientos de dashboards en otra.
- Incluye tu backend. Si las bases de datos y los servicios se ejecutan en una región cloud, un broker lejos de ellos añade latencia a cada mensaje consumido.
- Mira el p90 y el máximo, no solo la mediana. El jitter importa en todo lo interactivo.
- Comprueba los requisitos de residencia. Las normas de protección de datos pueden decidir la región antes que la latencia; consulta residencia de datos en MQTT.
- Plantéate particionar. Si las sedes están repartidas por varios continentes y necesitan baja latencia, brokers separados por región pueden superar a un único broker central.
- Recuerda que la latencia rara vez es el único factor. El coste, la residencia y la sencillez operativa suelen pesar más que unos pocos milisegundos en telemetría que leen personas.
Cómo elegir la ubicación de un despliegue de ConnectMQ
ConnectMQ ofrece varios modelos de despliegue, y la ubicación funciona de forma distinta en cada uno:
- Serverless (Free y Paid): tu broker se ejecuta en el clúster compartido de ConnectMQ. Ejecuta el script de medición desde tus sedes contra él para ver si el tiempo de ida y vuelta cumple tus necesidades.
- Dedicated: un clúster aislado para tu carga de trabajo. Comenta las opciones de ubicación con el equipo y lleva tu tabla de mediciones.
- BYOC: el broker se ejecuta en tu propia cuenta cloud, así que puede estar en la región donde ya residen tus otros sistemas. Confirma con el equipo los proveedores y regiones soportados al planificar; nuestra guía del broker MQTT BYOC cubre el modelo.
- Self Managed Enterprise: lo colocas donde ejecutes tu propia infraestructura.
Para la mayoría de las cargas de telemetría y monitorización, basta con un broker bien ubicado en la misma zona geográfica general que los dispositivos. Para los lazos de control exigentes, mantenlos en local en el edge y usa el broker en la nube para supervisión, informes e integración. Nuestro artículo sobre la latencia de los gemelos digitales en tiempo real analiza esa división con más detalle.
Errores habituales con la latencia
- Medir una sola vez desde la oficina. Mide desde las redes reales de los dispositivos, sobre todo en sedes con conexión celular.
- Culpar al broker de los problemas del Wi-Fi. Ejecuta primero las pruebas de red; las redes de acceso suelen aportar más retardo que la distancia.
- Reconectar para cada mensaje. Los dispositivos con sueño profundo pagan varias idas y vueltas en cada despertar; mantén las sesiones abiertas cuando la energía lo permita.
- Colocar los suscriptores lejos del broker. Un backend en otra región duplica la distancia que recorre cada mensaje.
- Ignorar el DNS. Los resolvers lentos añaden retardo a cada nueva conexión; cachea los resultados en las pasarelas.
Mide tu latencia con ConnectMQ
ConnectMQ es un broker MQTT gestionado con opciones de despliegue Serverless, Dedicated y BYOC, para que puedas ajustar la ubicación a tus sedes y sistemas. Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, ejecuta el script desde tus sedes y usa los resultados para elegir tu configuración de producción. La guía del broker MQTT en la nube cubre el resto de la decisión de alojamiento, y cómo escalar un broker MQTT cubre la capacidad.
Preguntas frecuentes
¿Cuánto afecta la elección de región a la latencia MQTT?
La distancia fija un tiempo de ida y vuelta mínimo de aproximadamente 1 milisegundo por cada 100 kilómetros de fibra, y las rutas reales añaden más. Para dispositivos en otro continente, la elección de región suele dominar la parte de red de la latencia.
¿Cuál es la mejor forma de medir la latencia de un broker MQTT?
Ejecuta desde la sede de los dispositivos una prueba a nivel MQTT que cronometre la conexión, TLS y una ida y vuelta de publicar a recibir, y recoge medianas y percentiles altos sobre muchas muestras.
¿Hace TLS que MQTT sea más lento?
TLS añade idas y vueltas al conectar, pero muy poco coste por mensaje después. Mantén las conexiones abiertas siempre que puedas para pagar el handshake una sola vez.
¿Puedo elegir dónde se ejecuta mi broker de ConnectMQ?
Con BYOC el broker se ejecuta en tu propia cuenta cloud, así que eliges la región dentro de las opciones que admite el equipo. Para los despliegues Dedicated, comenta la ubicación con el equipo.
