Laboratorio 4 — Evidencia de funcionamiento de los 3 protocolos
MQTT · AMQP 1.0 · CoAP hacia Azure IoT Central — medición real ejecutada en la VM.
1. Telemetría publicada por protocolo
| Protocolo | Device | Endpoint destino | Puerto | n | Latencia prom. | mín | máx | Bytes/msg |
|---|---|---|---|---|---|---|---|---|
| MQTT TCP + TLS 1.2/1.3 · TLS: sí · TLS 1.2/1.3 |
mqtt-baseline-01 python/mqtt_baseline.py |
Azure IoT Central (nativo) | 8883 | 392 | 110.8 ms | 102.9 | 169.1 | 60 B |
| AMQP 1.0 TCP + TLS (AMQP 1.0 binario) · TLS: sí · TLS 1.2/1.3 |
amqp-lab4-01 python/amqp_sdk.py |
Azure IoT Central / IoT Hub (nativo) | 5671 | 392 | 112.7 ms | 101.0 | 461.6 | 60 B |
| CoAP (UDP) UDP (sin TLS en el salto CoAP) · TLS: no en el salto CoAP · sí en el puente |
coap-gateway-01 python/coap_client.py + python/coap_gateway.py |
gateway propio en la VM → puente MQTT → Central | 5683/udp | 394 | 118.9 ms | 104.2 | 166.1 | 60 B |
AMQP: el primer mensaje (461.6 ms) incluye el handshake completo (TLS + CBS + attach); en estado estacionario el promedio es 111.8 ms. · CoAP: RTT del datagrama promedio 118.9 ms; el forwarding del gateway hacia Central promedió 117.4 ms (n=394); el salto CoAP/UDP local es submilisegundo.
2. Gráficas de la captura
3. Tabla comparativa (teórico vs observado)
| Criterio | MQTT | AMQP 1.0 | CoAP (UDP) |
|---|---|---|---|
| Modelo de comunicación | pub/sub por topics | peer-to-peer (links + créditos) | request/response (mensajes CON) |
| Puerto / transporte | 8883 TCP+TLS | 5671 TCP+TLS | 5683 UDP (sin TLS en el salto) |
| Latencia observada (VM) | 110.8 ms | 112.7 ms (steady 111.8 ms) | 118.9 ms RTT + 117.4 ms forwarding |
| Fiabilidad | PUBACK QoS 1 | disposition SendComplete | 2.04 Changed + retransmisión CON |
| Overhead | cabecera MQTT mínima (2 B fijos) + TLS | handshake pesado: TLS + CBS + attach (≈ 430 ms la 1ª vez) | cabecera CoAP mínima (4 B) + UDP sin TLS |
| Firewall / NAT | 8883 a veces bloqueado (443/WS) | 5671 / 443 AMQP-WS | UDP 5683 suele pasar, sin garantía |
| Microcontrolador (ESP32) | soporte maduro (paho/Arduino) | poco usado en MCU | ideal para constrained (RFC 7252) |
| Integración con IoT Central | nativa | nativa | requiere gateway propio |
| Facilidad de debug | muy fácil | media (frames binarios) | media-fácil |
| Caso de uso ideal | telemetría ligera de sensores | mensajería entre servicios Azure | nodo constrained en red local |
4. Arquitectura real desplegada
5. Reporte generado (listo para pegar)
# Evidencia Lab 4 — captura 2026-10-05 00:18:31 -05
- **App IoT Central:** `clima-salones-app-jose.azureiotcentral.com`
- **VM:** vmtalleresjose · 52.237.172.24 · North Central US · `Linux-6.17.0-1022-azure-x86_64-with-glibc2.39`
- **Estudiante:** José Alejandro Téllez Prada
- **Captura (UTC):** 2026-10-05T05:18:31Z
- **Intervalo de publicación:** 3.0 s
- **Nota:** captura final: HTTPS + pagina didactica
## 1. Telemetría publicada por protocolo (datos de esta captura)
| Protocolo | Device | Dónde corre | Endpoint destino | Puerto | Transporte | TLS | n | Latencia prom | min | max | Bytes/msg |
|---|---|---|---|---|---|---|---|---|---|---|---|
| **MQTT** | `mqtt-baseline-01` | VM | Azure IoT Central (nativo) | 8883 | TCP + TLS 1.2/1.3 | sí · TLS 1.2/1.3 | 392 | **110.8 ms** | 102.9 | 169.1 | 60 B |
| **AMQP 1.0** | `amqp-lab4-01` | VM | Azure IoT Central / IoT Hub (nativo) | 5671 | TCP + TLS (AMQP 1.0 binario) | sí · TLS 1.2/1.3 | 392 | **112.7 ms** | 101.0 | 461.6 | 60 B |
| **CoAP (UDP)** | `coap-gateway-01` | VM | gateway propio en la VM → puente MQTT → Central | 5683/udp | UDP (sin TLS en el salto CoAP) | no en el salto CoAP · sí en el puente | 394 | **118.9 ms** | 104.2 | 166.1 | 60 B |
> **AMQP:** el primer mensaje (461.6 ms) incluye el handshake (TLS + CBS + attach). En estado estacionario: **111.8 ms**.
> **CoAP:** RTT del datagrama promedio **118.9 ms**; el *forwarding* del gateway hacia Central promedió **117.4 ms** (n=394). El salto CoAP/UDP local es submilisegundo.
## 2. Variables y formato del mensaje
Los tres clientes publican las MISMAS 3 variables de la plantilla `consola-unab-ambiental`, con el mismo formato JSON plano (1 decimal, 60 B):
```json
{"Temperature": 20.1, "Humidity": 47.5, "Iluminance": 400.3}
```
## 3. Ciclo de comunicación observado
- **MQTT:** CONNECT + TLS → CONNACK → PUBLISH QoS1 → PUBACK ← hub
- **AMQP 1.0:** TCP + TLS → CBS put-token ($cbs) → attach link de envío → TRANSFER → disposition accepted
- **CoAP (UDP):** POST CON (UDP 60 B) → gateway recibe + valida → puente MQTT → Central (ack) → 2.04 Changed ← gateway
## 3b. Cómo viaja el mensaje, protocolo por protocolo
### MQTT — device `mqtt-baseline-01`
| Capa | Qué hace |
|---|---|
| **Aplicación** | MQTT 3.1.1 · PUBLISH al topic devices/{id}/messages/events/ |
| **Transporte** | TCP · conexión persistente (el hub puede cerrarla, paho reconecta) |
| **Seguridad** | TLS 1.2/1.3 (certificado del hub) + SAS token en el CONNECT |
| **Red** | IP · puerto 8883 |
**Peso del mensaje:** 60 B de datos + **2 B** de cabecera fija. cabecera fija MQTT de 2 B; el topic, las tramas TCP y el registro TLS van aparte · el handshake TLS y el CONNECT solo se pagan una vez, al arrancar la corrida.
**Secuencia:**
1. `→` TCP + handshake TLS 1.2/1.3 + CONNECT con SAS *(solo la primera vez)*
2. `←` CONNACK (el hub acepta la sesión)
3. `→` PUBLISH QoS 1 · 60 B de telemetría
4. `←` PUBACK del hub
**Qué mide la latencia reportada:** PUBACK = tiempo desde que el cliente publica hasta que el hub confirma que el mensaje quedó en cola (QoS 1). No incluye la entrega a la app: MQTT desacopla emisor y receptor.
**Cuándo usarlo:** telemetría ligera de muchos dispositivos y MCU (ESP32): soporte maduro y debug fácil.
### AMQP 1.0 — device `amqp-lab4-01`
| Capa | Qué hace |
|---|---|
| **Aplicación** | AMQP 1.0 · transfer al endpoint devices/{id}/messages/events |
| **Sesión / link** | attach del link de envío + créditos (control de flujo) |
| **Transporte** | TCP · sesión con estado |
| **Seguridad** | TLS + auth CBS (put-token del SAS al nodo $cbs) |
| **Red** | IP · puerto 5671 |
**Peso del mensaje:** 60 B de datos + **8 B** de cabecera fija. cabecera fija AMQP de 8 B; lo caro de AMQP no es el dato, es el handshake · el 1er mensaje de cada corrida paga TLS + CBS + attach (~430-570 ms medidos); después solo el transfer.
**Secuencia:**
1. `→` TCP + TLS 1.2/1.3 *(primera vez)*
2. `→` CBS put-token: se presenta el SAS token *(nodo $cbs)*
3. `→` attach del link de envío + crédito
4. `→` TRANSFER · 60 B de telemetría
5. `←` disposition accepted
**Qué mide la latencia reportada:** disposition = el hub acepta el mensaje y se hace responsable de entregarlo (garantía explícita por mensaje). Con el link ya abierto el costo por mensaje es solo el transfer; el 1er mensaje paga TLS + CBS + attach.
**Cuándo usarlo:** mensajería entre servicios Azure (Service Bus, Event Hubs) y plataformas propias: sesiones, créditos y garantías de entrega que MQTT no da.
### CoAP (UDP) — device `coap-gateway-01`
| Capa | Qué hace |
|---|---|
| **Aplicación** | CoAP (RFC 7252) · POST /telemetry con JSON |
| **Transporte** | UDP · sin conexión (mensaje CON con retransmisión) |
| **Seguridad** | sin TLS en el salto CoAP (DTLS es opcional y aquí no se usa) |
| **Red** | IP · puerto 5683/udp |
| **Puente** | gateway propio → cliente SDK (MQTT 8883) → IoT Central |
**Peso del mensaje:** 60 B de datos + **4 B** de cabecera fija. cabecera fija CoAP de 4 B + UDP: el mensaje más liviano de los tres, sin handshake · no hay handshake: cada POST es un datagrama independiente que viaja solo.
**Secuencia:**
1. `→` POST CON · cabecera 4 B + 60 B (datagrama UDP) *(sin handshake)*
2. `→` el gateway valida el JSON y lo reenvía con su cliente SDK
3. `←` 2.04 Changed (confirmación CoAP)
**Qué mide la latencia reportada:** RTT = ida y vuelta del datagrama al gateway (que corre en la misma VM). El forwarding mide lo que tarda el gateway en reenviarlo a Central: por eso el salto CoAP/UDP local es submilisegundo y casi todo el tiempo es el tramo a Azure.
**Cuándo usarlo:** nodos muy constrained en red local (batería, radio LPWAN) con un gateway que haga de puente.
## 4. Tabla comparativa (teórico vs observado en la VM)
| Criterio | MQTT | AMQP 1.0 | CoAP (UDP) |
|---|---|---|---|
| Modelo | pub/sub (topics) | peer-to-peer (links + créditos) | request/response (CON) |
| Puerto / transporte | 8883 TCP+TLS | 5671 TCP+TLS | 5683 UDP |
| Latencia observada | 110.8 ms | 112.7 ms (steady 111.8 ms) | 118.9 ms (RTT) + 117.4 ms (forwarding) |
| Fiabilidad | PUBACK QoS1 | disposition `SendComplete` | 2.04 Changed + retransmisión CON |
| Overhead | cabecera mínima + TLS | handshake pesado (TLS+CBS+attach) | cabecera mínima, UDP sin TLS |
| Firewall/NAT | 8883 a veces bloqueado (443/WS) | 5671 / 443 AMQP-WS | UDP 5683 suele pasar, sin garantía |
| MCU / ESP32 | soporte maduro | poco usado | ideal constrained |
| IoT Central | nativo | nativo | **requiere gateway propio** |
| Debug | muy fácil | medio (frames binarios) | medio-fácil |
## 5. Evidencia cruda
- `captura-20261005-001831/mqtt.jsonl`
- `captura-20261005-001831/mqtt-stdout.log`
- `captura-20261005-001831/amqp.jsonl`
- `captura-20261005-001831/amqp-stdout.log`
- `captura-20261005-001831/coap.jsonl`
- `captura-20261005-001831/coap-stdout.log`
- `captura-20261005-001831/coap-gateway.jsonl`
- `captura-20261005-001831/coap-gateway-stdout.log`
---
Generado automáticamente por `dashboard/dashboard.py` el 2026-10-05 00:18:31 -05.