CoAP protocolo: REST sobre UDP que cabe en 8 KB de RAM

MQTT domina la telemetría continua. HTTP domina las APIs. CoAPCTérminoCoAPCoAP (Constrained Application Protocol) es un protocolo web tipo REST sobre UDP para dispositivos muy limitados, definido en el RFC 7252 del IETF.Ver perfil ocupa el espacio que ninguno de los dos puede cubrir bien: dispositivos con 8-64 KB de RAM, baterías de años, redes con pérdidas del 10-20%, y la necesidad de un modelo request/response como REST — no pub/sub.

Si estás diseñando firmware para un MCU de gama baja y HTTP te parece demasiado pesado y MQTTProtocoloMQTTEl protocolo pub/sub estándar del IoTVer perfil demasiado stateful, el CoAP protocolo (Constrained Application Protocol) es el RFC que necesitas leer.

Resumen ejecutivo

• CoAP (Constrained Application Protocol) es un protocolo de transferencia web especializado para nodos constrained, definido en RFC 7252 por el IETF en 2014 (acceso: 2026-05).
• Corre sobre UDP (no TCP), con cabecera de tan solo 4 bytes. El MTU objetivo es 1280 bytes (IPv6), con fragmentación propia vía Blockwise Transfer (RFC 7959).
• Modela HTTP REST: métodos GET, POST, PUT, DELETE + códigos de respuesta análogos (2.01 Created, 4.04 Not Found…).
• Observe (RFC 7641): un cliente puede suscribirse a un recurso y recibir notificaciones cuando cambia — parecido a pub/sub, pero sin broker.
• Seguridad: DTLS (Datagram TLS) sobre UDP para autenticación y cifrado.
• Implementaciones de referencia: Eclipse Californium (Java, lado servidor/proxy) y libcoap (C, embebido y servidor) (acceso: 2026-05).
• No usar cuando: necesitas pub/sub a escala (usa MQTT), el dispositivo tiene >256 KB RAM y conectividad estable (usa HTTP/2), o necesitas multicast confiable con QoSQTérminoQoS de MQTTEl QoS (Quality of Service) de MQTT define la garantía de entrega de un mensaje en tres niveles: 0 (como mucho una vez), 1 (al menos una vez) y 2 (exactamente una vez).Ver perfil garantizado.

Qué es CoAP y para qué sirve

CoAP nació de una constatación obvia: los dispositivos IoTITérminoIoT (Internet de las cosas)El IoT (Internet of Things) es la red de objetos físicos con sensores, software y conectividad que recogen e intercambian datos y actúan de forma autónoma.Ver perfil más baratos y de menor consumo — sensores de temperatura, actuadores simples, medidores de energía — no pueden correr HTTP. No porque HTTP sea conceptualmente complejo, sino porque sus cabeceras de texto, el overhead de TCP (handshake, control de flujo, retransmisiones), y la huella de memoria de las pilas TLS estándar superan los recursos disponibles.

El IETF formó el grupo de trabajo CoRE (Constrained RESTful Environments) en 2010 para resolver exactamente este problema. El resultado fue RFC 7252, publicado en junio de 2014.

CoAP es parte del ecosistema más amplio de protocolos IoT que cubre Plataforma IoT. Entiende el resto del ecosistema IoT para contextualizar dónde encaja.

Cómo funciona CoAP

Estructura del mensaje

Un mensaje CoAP tiene cuatro campos obligatorios en la cabecera (4 bytes total):

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T |  TKL  |     Code      |          Message ID           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Token (if any, 0-8 bytes)                                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Options (if any)                                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1|    Payload (if any)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• Ver (2 bits): versión (siempre 1).
• T (2 bits): tipo de mensaje — CON (Confirmable), NON (Non-confirmable), ACK, RST.
• TKL (4 bits): longitud del Token.
• Code (8 bits): método (0.xx) o código de respuesta (2.xx–5.xx).
• Message ID (16 bits): para deduplicación y ACK.

Tipos de mensaje

CoAP define cuatro tipos que gestionan la fiabilidad sobre UDP:

Métodos y códigos de respuesta

Los métodos son idénticos a HTTP en semántica:

Los códigos de respuesta siguen el esquema c.dd: 2.01 Created, 2.05 Content, 4.04 Not Found, 5.00 Internal Server Error. Familiar para quien conoce HTTP, pero comprimido en un solo byte.

Observe (RFC 7641): notificaciones sin broker

La extensión Observe transforma CoAP en un sistema reactivo sin necesidad de broker. Un cliente envía un GET con la opción Observe=0 (suscribirse). El servidor registra al cliente y le envía notificaciones con cada cambio del recurso.

Cliente                          Servidor (sensor)
  |---GET /temperatura Observe:0--->|
  |<--2.05 Content Observe:1 21.3--|   # estado inicial
  |<--2.05 Content Observe:2 21.7--|   # temperatura cambia
  |<--2.05 Content Observe:3 22.1--|
  |---GET /temperatura Observe:1--->|  # cancelar suscripción

El cliente puede cancelar enviando un GET con Observe=1 o simplemente ignorando las notificaciones hasta que el servidor las expire (por timeout o RST).

Seguridad con DTLS

CoAP sin cifrado expone los payloads en claro — inaceptable en producción. DTLS (Datagram TLS) aporta autenticación y cifrado sobre UDP, con el mismo modelo de handshake que TLS pero adaptado a datagramas.

Los cuatro modos de seguridad CoAP son:

• NoSec: sin seguridad (solo para laboratorio/LAN cerrada).
• PreSharedKey: clave precompartida, bajo overhead, válido para flota de dispositivos conocidos.
• RawPublicKey: clave pública sin certificado X.509, reduce tamaño del handshake.
• Certificate: X.509 completo, máxima seguridad, mayor overhead.

Para dispositivos muy constrained (8-32 KB RAM), PreSharedKey con DTLS 1.2 es el punto de equilibrio habitual. El artículo sobre seguridad IoT cubre el modelo de amenazas en detalle.

Casos de uso reales

El ESP32 con la librería libcoap soporta CoAP nativo. La huella de memoria de libcoap en modo cliente es inferior a 20 KB de flash y 4 KB de RAM — perfectamente asumible incluso en variantes ESP32HardwareESP32WiFi + BT/BLE SoC dual-core a precio de €Ver perfil-C3 o ESP32-H2.

Cuándo NO usar CoAP

CoAP no es la herramienta universal que algunos tutoriales presentan:

Si necesitas pub/sub a escala, usa MQTT. CoAP Observe funciona bien con decenas de clientes por recurso. Con miles de suscriptores, la lógica de notificación en el servidor se complica; MQTT con un broker Mosquitto/EMQXETérminoEMQXEMQX es un broker MQTT open source de alta escala (escrito en Erlang) para producción IoT, con clustering y soporte multiprotocolo.Ver perfil escala mejor.

Si el dispositivo tiene RAM suficiente y red estable, HTTP/2 es más interoperable. Un ESP32 con 520 KB de SRAM puede correr una pila HTTP ligera. La diferencia de overhead entre CoAP y HTTP se vuelve marginal si no tienes restricciones de batería o ancho de banda.

Si necesitas garantías de entrega end-to-end robustas sobre redes muy ruidosas, MQTT QoS 2 con un broker que persiste mensajes es más maduro que CON CoAP + retransmisiones manuales.

Sin soporte DTLS en el stack, no uses CoAP en producción. NoSec CoAP sobre UDP es trivialmente interceptable. Si el firmware no cabe DTLS, revisa si puedes mover la seguridad a nivel de red (VPN, LoRaWANProtocoloLoRaWANLPWAN abierta de largo alcance y bajo consumoVer perfil con AppSKey).

CoAP vs MQTT vs HTTP

CoAP es la elección natural cuando: radio es 6LoWPAN6Término6LoWPAN6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks) es un estándar que adapta IPv6 a redes de bajo consumo sobre IEEE 802.15.4. Es la base de Thread.Ver perfil (Thread/ZigbeeProtocoloZigbeeMesh 2.4 GHz veterana — base de muchos hubs smart homeVer perfil IP), el dispositivo no puede mantener TCP, y el patrón de acceso es request/response o Observe con pocos clientes.

Cómo empezar: CoAP en ESP32 con libcoap

1. Incluye libcoap en tu proyecto ESP-IDF

# En el directorio de tu proyecto ESP-IDF
idf.py add-dependency "espressif/coap==4.3.5"

O añade directamente en idf_component.yml:

dependencies:
  espressif/coap: "^4.3.5"

2. Servidor CoAP mínimo (ESP32, C)

#include "coap3/coap.h"

static void hnd_get_temperatura(coap_resource_t *resource,
                                 coap_session_t *session,
                                 const coap_pdu_t *request,
                                 const coap_string_t *query,
                                 coap_pdu_t *response) {
    float temp = read_sensor_temperature();  // tu función
    char buf[16];
    snprintf(buf, sizeof(buf), "%.1f", temp);

    coap_pdu_set_code(response, COAP_RESPONSE_CODE_CONTENT);
    coap_add_data(response, strlen(buf), (uint8_t *)buf);
}

void app_main(void) {
    coap_context_t *ctx = coap_new_context(NULL);
    coap_address_t addr;
    coap_address_init(&addr);
    addr.addr.sin.sin_family = AF_INET;
    addr.addr.sin.sin_port = htons(5683);  // puerto CoAP estándar

    coap_endpoint_t *ep = coap_new_endpoint(ctx, &addr, COAP_PROTO_UDP);

    coap_resource_t *r = coap_resource_init(
        coap_make_str_const("temperatura"), 0);
    coap_register_handler(r, COAP_REQUEST_GET, hnd_get_temperatura);
    coap_add_resource(ctx, r);

    while (1) {
        coap_io_process(ctx, 1000);  // procesa eventos 1 s
    }
}

3. Cliente CoAP desde la LAN (usando coap-client)

# macOS / Linux (instala libcoap-bin o usa Docker)
coap-client -m get coap://192.168.1.42/temperatura
# Respuesta: 22.3

4. Observe desde línea de comandos

coap-client -m get -s 10 coap://192.168.1.42/temperatura
# -s 10: observar durante 10 segundos, recibir notificaciones automáticas

CoAP en el stack IoT: dónde encaja con otros protocolos

CoAP no existe en aislamiento. En un despliegue real, coexiste con otros protocolos en distintas capas. Un caso típico en redes de sensores 6LoWPAN sería:

Capa de transporte de red:  Thread o BLE con 6LoWPAN
Capa de aplicación:         CoAP (GET/PUT/Observe)
Seguridad:                  DTLS con PreSharedKey
Integración backend:        Proxy CoAP→HTTP (Eclipse Californium)
Broker de datos:            MQTT sobre TCP para almacenamiento en nube

El sensor habla CoAP directamente al Border Router. El Border Router tiene un proxy CoAP-HTTP que traduce las peticiones al backend REST. El backend almacena en base de datos y publica métricas por MQTT a los dashboards de monitorización.

Este patrón es habitual en instalaciones de smart building: los sensores son tiny (8-32 KB RAM), hablan CoAP sobre 6LoWPAN, y el backend no necesita cambiar — consume HTTP como siempre.

La elección entre MQTT y CoAP en la capa de aplicación no es binaria. En el mismo sistema pueden coexistir: CoAP para los sensores más constrained, MQTT para los gateways y dispositivos con más recursos.

Recursos primarios

• RFC 7252 — The Constrained Application Protocol (CoAP) — spec oficial IETF (acceso: 2026-05)
• Eclipse Californium — CoAP Framework Java — implementación servidor/proxy (acceso: 2026-05)
• GitHub — obgm/libcoap — implementación C para embebidos (acceso: 2026-05)