MQTT o HTTP: cuándo usar cada uno

01 · Punto de partida

Dos protocolos, dos modelos

HTTP es un protocolo de pedido y respuesta: el cliente (el dispositivo) pregunta y el servidor contesta. El servidor nunca puede hablar primero. MQTT es de publicación y suscripción: ambos extremos se conectan a un broker y cualquiera puede enviar un mensaje en cualquier momento, en cualquier sentido, a todos los interesados.

De esa diferencia de modelo se derivan casi todas las demás: cuánto cuesta cada mensaje, cuánto tarda en llegar una orden, cuántos dispositivos soporta un servidor y qué hay que mantener abierto. En el tema 25 comparamos los dos en bytes y en batería para la telemetría; acá agregamos las órdenes del servidor, la escala y la operación, que son las que terminan decidiendo.

Los resultados del laboratorio salen del modelo de energía y de bytes de los temas anteriores (mismos valores didácticos); podés reproducirlos con el código del tema.

02 · Las diferencias

Comparación punto por punto

03 · Decidir

El árbol de decisión

Cuatro preguntas ordenan casi todos los casos. La primera es la más importante: ¿el servidor necesita iniciar la comunicación con el dispositivo? Si no, el dispositivo solo informa, y la diferencia entre protocolos es pequeña. Si sí, importa cuánto retraso se tolera y de dónde sale la energía.

04 · El caso decisivo

El caso decisivo: las órdenes

Con HTTP, el servidor no puede avisarle al dispositivo que hay una orden: tiene que esperar a que el dispositivo pregunte. Eso se llama sondeo (polling): cada cierto intervalo el dispositivo hace un GET a /ordenes y, si hay algo, lo ejecuta. El intervalo fija el retraso: una orden espera en promedio la mitad del intervalo y, en el peor caso, un intervalo entero.

Con MQTT, el dispositivo mantiene una suscripción a casa/camara07/cmd y el broker le entrega la orden apenas llega, en una fracción de segundo. A cambio, tiene que mantener la conexión abierta. Cada protocolo desplaza el costo a un lugar distinto:

• Sondeo: pagás en peticiones. Para bajar el retraso a la mitad hay que duplicar las peticiones, la mayoría para escuchar «no hay nada».
• Empuje: pagás en conexión abierta. Un mensaje cuesta lo mismo, no importa cuántas órdenes lleguen, pero la radio queda atenta todo el día.

Con red eléctrica, el costo del empuje es despreciable y el del sondeo crece con la flota. Con pila, es al revés: la radio atenta es lo más caro y el sondeo espaciado es barato. De ahí que la misma pregunta tenga respuestas opuestas según cómo se alimente el dispositivo.

La tercera fila marca el límite práctico: con un sondeo cada 5 minutos, la pila dura 1,1 años. Más frecuente que eso, la batería baja del año, y a un segundo se agota en un día y medio (más rápido que con MQTT abierto). Con pila, «instantáneo» y «a batería» no pueden convivir con ninguno de los dos protocolos.

05 · Energía

Con pila, casi siempre HTTP

Parece paradójico: el protocolo «liviano» pierde con pila. La razón es lo que se mantiene abierto, no lo que se envía. Un dispositivo de telemetría que duerme entre envíos y se despierta una vez por hora gasta lo mismo con cualquiera de los dos: la conexión nueva (TCP y TLS) domina el costo, y publicar un mensaje MQTT de 69 bytes o hacer un POST de 270 bytes es una diferencia menor. Las dos primeras filas de la tabla lo muestran: 120 KB contra 119 KB por día y 8,6 años en ambos casos.

MQTT empieza a ser conveniente con pila cuando se mantiene la conexión abierta para recibir órdenes, y ahí la radio atenta (20 mA todo el día) deja la batería en 4,2 días. Existen atajos para dispositivos con pila que necesitan responder rápido: radios de despertar, modos de ahorro del módem (PSM y eDRX en redes celulares, tema 16) que mantienen la sesión sin radio atenta, o servidores que guardan la orden hasta la próxima conexión programada. Son parte de elegir la red y el módulo, no del protocolo.

06 · Flotas grandes

La escala y el servidor

Con red eléctrica la energía deja de importar, y lo que decide es la carga del servidor. Cada sondeo es una petición completa: acepta, procesa y responde. Con 10.000 dispositivos que sondean cada segundo el servidor recibe 10.000 peticiones por segundo, casi todas vacías. El mismo servicio con MQTT maneja los 167 mensajes por segundo de la telemetría (una publicación por minuto de cada dispositivo) más latidos, y las órdenes viajan solo cuando existen.

La contrapartida es que un broker es un componente con estado: mantiene decenas de miles de conexiones abiertas, sesiones y mensajes retenidos, y su escalado exige un clúster de brokers o un servicio gestionado. HTTP escala agregando servidores idénticos detrás de un balanceador, algo que todo equipo web ya sabe hacer. Para flotas chicas o medianas, y sin necesidad de órdenes rápidas, esa simplicidad operativa pesa más que cualquier ahorro de bytes.

Una regla útil: si el servidor necesita hablar primero y hay más de unos cientos de dispositivos, MQTT; si solo escuchan, HTTP. El laboratorio de este tema usa un límite didáctico de 1000 peticiones por segundo para decidir cuándo el sondeo deja de ser viable.

07 · Combinar

Usar los dos en el mismo producto

La pregunta «¿MQTT o HTTP?» suele tener la respuesta «los dos, cada uno en lo suyo». Un reparto frecuente:

El patrón típico de actualización remota ilustra la combinación: el servicio publica por MQTT una orden corta, {"a":"actualizar","v":"1.3.0","url":"https://…"}; el dispositivo la recibe al instante y descarga el binario por HTTPS, con reanudación si se corta, y luego informa el resultado por MQTT. Cada protocolo hace lo que mejor sabe.

08 · Más allá de los dos

Otras opciones

• WebSocket (tema 24): una conexión larga bidireccional sobre HTTP. Resuelve el empuje de órdenes con la infraestructura web, pero sin los tópicos, la calidad de servicio ni las sesiones de MQTT: esas hay que construirlas.
• MQTT sobre WebSocket: permite que un navegador se suscriba directamente al broker, y atraviesa cortafuegos por el puerto 443.
• CoAP: un protocolo de pedido y respuesta pensado para dispositivos muy limitados, sobre UDP, con un encabezado de 4 bytes. Tiene una extensión de observación (el servidor avisa los cambios de un recurso). Es la base de LwM2M, un estándar de gestión de dispositivos.
• AMQP: un protocolo de mensajería empresarial, más pesado, habitual entre servicios del lado de la nube más que en el dispositivo.
• Protocolos propietarios de cada plataforma: las nubes de IoT suelen ofrecer MQTT, HTTP o ambos; elegir sus puertas de entrada estándar evita quedar atado.

Si dudás, MQTT y HTTP cubren la inmensa mayoría de los casos, y casi todas las plataformas los soportan.

09 · Analogía con programación

Un recomendador en Python

El programa convierte el árbol de decisión en una función. Para un tipo de dispositivo (con pila o con red eléctrica), un retraso máximo aceptable para las órdenes (0 si no hay), el ritmo de telemetría y el tamaño de la flota calcula, para HTTP con sondeo y para MQTT: datos por día, miliamperios-hora por día (si hay pila), retraso medio de una orden y peticiones o mensajes por segundo que recibe el servidor. Luego decide cuáles son viables (con pila, que la batería dure al menos un año; con red eléctrica, que el servidor no supere 1000 peticiones por segundo) y recomienda. Usa los mismos valores didácticos de los temas 25 a 28.

# Elegir entre HTTP (con sondeo para las órdenes) y MQTT según los requisitos del dispositivo.
BATERIA_MAH = 2000
SUENO_MAH_DIA = 0.24
MAH_CONEXION = 100 * 0.6 / 3600          # conexión nueva: 0,6 s de radio a 100 mA
RADIO_ATENTA_MAH_DIA = 480               # conexión abierta: 20 mA durante 24 h
IP_TCP = 40
APRETON_B = 4700                         # TCP y TLS 1.3
HTTP_B = 270                             # petición y respuesta con cabeceras mínimas
PING_S = 60
CARGA = 40
LATENCIA_MQTT_S = 0.1                    # valor didáctico: una orden llega casi al instante
MAX_PETICIONES_S = 1000                  # capacidad didáctica del servidor
TOPICO = "casa/camara07/temperatura"


def largo_publish(carga):
    cuerpo = 2 + len(TOPICO) + carga
    return 1 + (1 if cuerpo < 128 else 2) + cuerpo


def http(pila, ordenes_s, tel_s, flota):
    """ordenes_s: retraso máximo aceptable para una orden (0 = no hay órdenes)."""
    intervalo = min(tel_s, ordenes_s) if ordenes_s else tel_s
    ciclos = 86400 / intervalo
    if pila:                                            # una conexión nueva en cada ciclo
        datos = ciclos * (APRETON_B + HTTP_B + CARGA)
        mah = SUENO_MAH_DIA + ciclos * MAH_CONEXION
    else:                                               # conexión abierta con red eléctrica
        datos = ciclos * (HTTP_B + CARGA + 2 * IP_TCP) + 86400 / PING_S * 2 * IP_TCP
        mah = None
    return {"datos": datos, "mah": mah, "retraso": intervalo / 2 if ordenes_s else None,
            "carga": flota * ciclos / 86400}


def mqtt(pila, ordenes_s, tel_s, flota):
    envios = 86400 / tel_s
    publicar = largo_publish(CARGA) + IP_TCP
    if ordenes_s or not pila:                           # conexión abierta
        datos = envios * publicar + 86400 / PING_S * 2 * (2 + IP_TCP)
        mah = RADIO_ATENTA_MAH_DIA if pila else None
    else:                                               # sin órdenes y con pila: se reconecta en cada envío
        sobre = 22 + 4 + 2 + 3 * IP_TCP                 # CONNECT, CONNACK, DISCONNECT
        datos = envios * (APRETON_B + sobre + publicar)
        mah = SUENO_MAH_DIA + envios * MAH_CONEXION
    return {"datos": datos, "mah": mah, "retraso": LATENCIA_MQTT_S if ordenes_s else None,
            "carga": flota * envios / 86400}


def viable(pila, r):
    if pila:
        return BATERIA_MAH / r["mah"] >= 365
    return r["carga"] <= MAX_PETICIONES_S


def recomendar(pila, ordenes_s, tel_s, flota):
    h, m = http(pila, ordenes_s, tel_s, flota), mqtt(pila, ordenes_s, tel_s, flota)
    vh, vm = viable(pila, h), viable(pila, m)
    if vh and vm:
        veredicto = "MQTT" if ordenes_s and ordenes_s <= 60 else "HTTP alcanza"
    elif vh:
        veredicto = "HTTP"
    elif vm:
        veredicto = "MQTT"
    else:
        veredicto = "Ninguno alcanza"
    return veredicto, h, m


CASOS = [
    ("pila, sin órdenes, cada hora",       True,  0,    3600, 1000),
    ("pila, orden en 1 h, cada hora",      True,  3600, 3600, 1000),
    ("pila, orden en 5 min, cada hora",    True,  300,  3600, 1000),
    ("pila, orden en 1 s",                 True,  1,    3600, 1000),
    ("red, sin órdenes, cada minuto",      False, 0,    60,   1000),
    ("red, orden en 5 min, 1000",          False, 300,  60,   1000),
    ("red, orden en 1 s, 100",             False, 1,    60,   100),
    ("red, orden en 1 s, 10.000",          False, 1,    60,   10_000),
]
print(f"{'caso':<36} {'HTTP':>9} {'MQTT':>9}   {'vida HTTP':>10} {'vida MQTT':>10} {'retraso HTTP':>13}  recomendación")
for nombre, pila, o, t, f in CASOS:
    v, h, m = recomendar(pila, o, t, f)
    vida = lambda r: "red" if r["mah"] is None else (f"{BATERIA_MAH / r['mah'] / 365:.1f} años" if BATERIA_MAH / r["mah"] >= 365 else f"{BATERIA_MAH / r['mah']:.1f} días")
    ret = "—" if h["retraso"] is None else f"{h['retraso']:.1f} s"
    print(f"{nombre:<36} {h['datos'] / 1000:>7.0f} KB {m['datos'] / 1000:>7.0f} KB   {vida(h):>10} {vida(m):>10} {ret:>13}  {v}")

print()
v, h, m = recomendar(False, 1, 60, 10_000)
print(f"Red, orden en 1 s, 10.000 dispositivos: HTTP {h['carga']:,.0f} peticiones/s, MQTT {m['carga']:,.0f} mensajes/s")

Resultado con los valores iniciales. Con pila y telemetría cada hora: sin órdenes, HTTP y MQTT cuestan lo mismo (120 y 119 KB por día, 8,6 años) y se recomienda HTTP; con una orden en 1 hora, HTTP dura 8,6 años contra 4,2 días de MQTT; con una en 5 minutos, HTTP baja a 1,1 años (1443 KB) y MQTT sigue en 4,2 días; con una en 1 segundo, HTTP llega a 1,4 días, MQTT a 4,2 y ninguno alcanza. Con red eléctrica y telemetría cada minuto: sin órdenes o con una en 5 minutos alcanza HTTP (677 KB contra 278 KB de MQTT por día); con una en 1 segundo, el sondeo HTTP consume 33.811 KB por día y la recomendación es MQTT, con 100 peticiones por segundo para 100 dispositivos. La última línea muestra que, para 10.000 dispositivos, HTTP recibiría 10.000 peticiones por segundo y MQTT 167 mensajes.

Dos observaciones. La recomendación depende de los datos, no del gusto: el mismo dispositivo pasa de «HTTP» a «MQTT» cambiando solo el retraso aceptable o la alimentación. Y el costo del sondeo es una función del retraso que se pide: pasar de 1 hora a 5 minutos cuesta casi 8 veces en batería (8,6 contra 1,1 años), un número que conviene mostrarle al responsable del producto antes de aceptar un requisito de «respuesta inmediata».

10 · Exploración interactiva

Elegir el protocolo, de extremo a extremo

Este laboratorio aplica el mismo modelo del código anterior. Elegí cómo se alimenta el dispositivo, cuánto retraso se acepta para una orden, cada cuánto publica su telemetría y cuántos dispositivos hay. Mostrará los datos por día, la duración de la batería, el retraso medio de una orden y la carga del servidor para HTTP con sondeo y para MQTT, con los valores separados por una barra («HTTP / MQTT»), y una recomendación.

Recorrido guiado

1. Con los valores iniciales (pila, orden en 5 minutos, telemetría cada hora, 1000 dispositivos), calculá. HTTP envía 1443 KB por día y dura 1,1 años, con un retraso medio de 2,5 minutos para las órdenes; MQTT envía 124 KB pero dura 4,2 días. Recomendación: HTTP.
2. Pasá el retraso a 1 hora: HTTP baja a 120 KB y dura 8,6 años (retraso medio de 30 minutos). Cada vez que se relaja el requisito, el sondeo se abarata.
3. Pasá a 1 segundo: HTTP llega a 432.864 KB por día y a 1,4 días de batería; MQTT, a 4,2 días. «Ninguno alcanza»: el requisito no es compatible con una pila.
4. Cambiá a red eléctrica, telemetría cada minuto y 100 dispositivos con retraso de 1 segundo: HTTP recibiría 100 peticiones por segundo y cada dispositivo movería 33.811 KB por día; MQTT, 278 KB y 1,7 mensajes por segundo. Recomendación: MQTT.
5. Subí a 10.000 dispositivos: HTTP llega a 10.000 peticiones por segundo, diez veces el límite didáctico; MQTT se queda en 167 mensajes.
6. Probá con red eléctrica, 5 minutos y 1000 dispositivos: ambos son viables (17 peticiones o mensajes por segundo) y se recomienda «HTTP alcanza»: el retraso medio de 30 segundos es aceptable y HTTP es más simple de operar.

11 · Método de trabajo

Método de elección

1. Escribí los requisitos con números: alimentación, ritmo de telemetría, retraso aceptable de las órdenes (y si existen), cantidad de dispositivos.
2. ¿Hay órdenes del servidor? Si no, empezá por HTTP: es lo más simple.
3. Si las hay, calculá el costo del sondeo con el retraso pedido: batería (con pila) o peticiones por segundo (con red eléctrica).
4. Calculá el costo de la conexión abierta de MQTT: radio atenta con pila, tamaño del broker con muchos dispositivos.
5. Descartá lo no viable y, si quedan dos opciones, elegí la más simple de operar salvo que el retraso pedido sea de segundos.
6. Si ninguna es viable, relajá el requisito, cambiá la alimentación o la red, o buscá un atajo (radio de despertar, modos de ahorro del módem).
7. Repartí los usos: telemetría y órdenes por MQTT, archivos y APIs por HTTP.
8. Verificá la red real: puertos permitidos, proxies, TLS; MQTT sobre WebSocket si el 8883 está bloqueado.
9. Documentá la decisión con los números, para revisarla cuando cambien los requisitos.

12 · Comprensión

Confusiones frecuentes

13 · Práctica guiada

Predecí antes de comprobar

1. Sensor sin órdenes

Un sensor de humedad del suelo, a pila de 2000 mAh, publica cada 10 minutos y no recibe órdenes. ¿HTTP o MQTT? ¿Cuánto dura la pila?

2. Una cerradura a pila

Una cerradura con pila debe abrir en menos de 2 segundos desde la aplicación. ¿Puede resolverse con HTTP o MQTT?

3. Flota en red eléctrica

5000 dispositivos en red eléctrica sondean cada 5 segundos para recibir órdenes. ¿Cuántas peticiones por segundo recibe el servidor y qué retraso medio tienen las órdenes? ¿Qué cambia con MQTT?

4. Actualizar el firmware

¿Cómo se entrega un firmware de 1 MB a un dispositivo que ya usa MQTT para todo lo demás?

5. Un panel web

Querés mostrar en una página web la temperatura de cada cámara actualizada en vivo. ¿Qué usás entre el navegador y el sistema?

6. El precio de un requisito

El responsable del producto pasa el requisito de retraso de una orden de 1 hora a 5 minutos para un dispositivo a pila. ¿Cuánto cuesta en batería?

14 · Síntesis

Ideas para recordar

¿Listo para el tema 31?

Antes de avanzar, tomá un producto IoT que conozcas y escribí sus requisitos (alimentación, telemetría, retraso de las órdenes, flota). Corré el recomendador con esos valores y anotá qué protocolo resulta para cada parte. Después cambiá el requisito de retraso y mirá cómo cambia la recomendación.

En el próximo tema empezamos el bloque de procesamiento local, almacenamiento y telemetría con Procesamiento local: decidir en el dispositivo, filtrando, resumiendo y reaccionando sin esperar a la nube.