El Protocolo de Aplicación Restringida ( CoAP ) es un protocolo de aplicación de Internet especializado basado en UDP para dispositivos restringidos, tal como se define en RFC 7252. Permite que esos dispositivos restringidos llamados "nodos" se comuniquen con Internet en general utilizando protocolos similares. CoAP está diseñado para usarse entre dispositivos en la misma red restringida (por ejemplo, redes de bajo consumo y con pérdida), entre dispositivos y nodos generales en Internet, y entre dispositivos en diferentes redes restringidas unidas por una red de Internet. CoAP también se usa a través de otros mecanismos, como SMS en redes de comunicación móvil.
CoAP es un protocolo de capa de aplicación que está pensado para su uso en dispositivos de Internet con recursos limitados, como nodos de redes de sensores inalámbricos . CoAP está diseñado para traducirse fácilmente a HTTP para una integración simplificada con la web, al mismo tiempo que cumple con requisitos especializados como compatibilidad con multidifusión , muy poca sobrecarga y simplicidad. [1] [2] La multidifusión, la baja sobrecarga y la simplicidad son importantes para la Internet de las cosas (IoT) y la comunicación de máquina a máquina (M2M), que tienden a estar integradas y tienen mucha menos memoria y suministro de energía que los dispositivos de Internet tradicionales. Por lo tanto, la eficiencia es muy importante. CoAP puede ejecutarse en la mayoría de los dispositivos que admiten UDP o un análogo de UDP.
El Grupo de trabajo de entornos RESTful restringidos (CoRE) del Grupo de trabajo de ingeniería de Internet ( IETF ) ha realizado el principal trabajo de estandarización de este protocolo. Para que el protocolo sea adecuado para aplicaciones IoT y M2M, se han agregado varias funciones nuevas.
El núcleo del protocolo se especifica en el RFC 7252. Se han propuesto varias extensiones, en particular:
CoAP utiliza dos tipos de mensajes, solicitudes y respuestas, utilizando un formato de encabezado binario simple. CoAP está vinculado de forma predeterminada a UDP y, opcionalmente, a DTLS , lo que proporciona un alto nivel de seguridad en las comunicaciones. Cuando se vincula a UDP, el mensaje completo debe caber en un único datagrama. Cuando se utiliza con 6LoWPAN , tal como se define en RFC 4944, los mensajes deben caber en un único marco IEEE 802.15.4 para minimizar la fragmentación.
El mensaje CoAP más pequeño tiene una longitud de 4 bytes, si se omiten los campos de token, opciones y carga útil, es decir, si solo consta del encabezado CoAP. El encabezado va seguido del valor del token (de 0 a 8 bytes), que puede ir seguido de una lista de opciones en un formato optimizado de tipo-longitud-valor. Todos los bytes después del encabezado, el token y las opciones (si las hay) se consideran la carga útil del mensaje, que tiene como prefijo el "marcador de carga útil" de un byte (0xFF). La longitud de la carga útil está implícita en la longitud del datagrama.
Los primeros 4 bytes son obligatorios en todos los datagramas CoAP, constituyen el encabezado de tamaño fijo.
Estos campos se pueden extraer de estos 4 bytes en C a través de estas macros:
#define COAP_HEADER_VERSION(datos) ( (0xC0 y (datos)[0]) >> 6 ) #define COAP_HEADER_TYPE(datos) ( (0x30 y (datos)[0]) >> 4 ) #define COAP_HEADER_TKL(datos) ( (0x0F y (datos)[0]) >> 0 ) #define COAP_HEADER_CLASS(datos) ( ((datos)[1] >> 5) y 0x07 ) #define COAP_HEADER_CODE(datos) ( ((datos)[1] >> 0) y 0x1F ) #define COAP_HEADER_MID(datos) ( ((datos)[2] << 8) | (datos)[3] )Los tres bits más significativos forman un número conocido como "clase", que es análogo a la clase de códigos de estado HTTP . Los cinco bits menos significativos forman un código que comunica más detalles sobre la solicitud o respuesta. El código completo se comunica normalmente en el formato class.code.
Puede encontrar los últimos códigos de solicitud/respuesta de CoAP en [1], aunque la siguiente lista ofrece algunos ejemplos:
Cada solicitud lleva un token (pero puede tener una longitud cero) cuyo valor fue generado por el cliente. El servidor debe hacer eco de cada valor de token sin ninguna modificación al cliente en la respuesta correspondiente. Está pensado para usarse como un identificador local del cliente para hacer coincidir solicitudes y respuestas, especialmente para solicitudes concurrentes.
La comparación de solicitudes y respuestas no se realiza con el ID del mensaje porque una respuesta puede enviarse en un mensaje diferente al del acuse de recibo (que utiliza el ID del mensaje para la comparación). Por ejemplo, esto se podría hacer para evitar retransmisiones si la obtención del resultado lleva algún tiempo. Este tipo de respuesta separada se denomina "respuesta separada". Por el contrario, la transmisión de la respuesta directamente en el acuse de recibo se denomina "respuesta combinada", que se espera que sea la preferida por razones de eficiencia.
Opción delta:
Longitud de la opción:
Valor de la opción:
En muchos dominios de aplicación CoAP es esencial tener la capacidad de direccionar varios recursos CoAP como un grupo, en lugar de direccionar cada recurso individualmente (por ejemplo, para encender todas las luces habilitadas para CoAP en una habitación con una sola solicitud CoAP activada al alternar el interruptor de luz). Para abordar esta necesidad, el IETF ha desarrollado una extensión opcional para CoAP en forma de un RFC experimental: Comunicación de grupo para CoAP - RFC 7390 [3] Esta extensión se basa en la multidifusión IP para entregar la solicitud CoAP a todos los miembros del grupo. El uso de la multidifusión tiene ciertos beneficios, como reducir la cantidad de paquetes necesarios para entregar la solicitud a los miembros. Sin embargo, la multidifusión también tiene sus limitaciones, como una confiabilidad deficiente y no ser amigable con la memoria caché. Un método alternativo para la comunicación grupal CoAP que utiliza unidifusiones en lugar de multidifusiones se basa en tener un intermediario donde se crean los grupos. Los clientes envían sus solicitudes grupales al intermediario, que a su vez envía solicitudes de unidifusión individuales a los miembros del grupo, recopila sus respuestas y envía una respuesta agregada al cliente. [4]
CoAP define cuatro modos de seguridad: [5]
Se han llevado a cabo investigaciones para optimizar DTLS mediante la implementación de asociados de seguridad como recursos CoAP en lugar de utilizar DTLS como un contenedor de seguridad para el tráfico CoAP. Esta investigación ha indicado que se han logrado mejoras de hasta 6,5 veces en implementaciones no optimizadas. [6]
Además de DTLS, RFC8613 [7] define el protocolo de seguridad de objetos para entornos RESTful restringidos (OSCORE) que proporciona seguridad para CoAP en la capa de aplicación.
Aunque el estándar de protocolo incluye disposiciones para mitigar la amenaza de ataques de amplificación DDoS , [8] estas disposiciones no se implementan en la práctica, [9] lo que resulta en la presencia de más de 580.000 objetivos ubicados principalmente en China y ataques de hasta 320 Gbit/s. [10]
{{cite book}}: |journal=ignorado ( ayuda )