Qu'est-ce que le protocole CoAP ?
Le
CoAP (Constrained Application Protocol) est un protocole de transfert web spécialisé conçu pour être utilisé dans des réseaux restreints, à faible consommation d'énergie et à ressources limitées, tels que ceux que l'on trouve dans les appareils de l'internet des objets (IoT). Il s'agit d'un protocole léger qui permet aux appareils de communiquer entre eux à l'aide d'une architecture client-serveur.
CoAP est conçu pour être un protocole simple et efficace qui peut fonctionner sur UDP (User Datagram Protocol) au lieu de TCP (Transmission Control Protocol). Cela permet de réduire les frais généraux et la complexité du protocole, ce qui le rend plus adapté aux réseaux limités. CoAP prend également en charge la communication multicast, ce qui permet à plusieurs appareils de recevoir le même message simultanément.
L'une des principales caractéristiques de CoAP est sa prise en charge de l'architecture REST (Representational State Transfer), qui permet aux appareils d'accéder à des ressources et de les manipuler à l'aide de méthodes simples de type HTTP, telles que GET, POST, PUT et DELETE. Les développeurs peuvent ainsi facilement créer des applications CoAP en utilisant des process de programmation et des API familiers.
Une autre caractéristique importante de CoAP est sa prise en charge d'une variété de formats de données, notamment CBOR (Concise Binary Object Representation) et JSON (JavaScript Object Notation). Cela permet aux appareils d'échanger des données de manière compacte et efficace, réduisant ainsi la bande passante et la puissance de traitement nécessaires à la communication.
CoAP s'utilise largement dans une variété d'applications IoT, telles que les maisons intelligentes, l'automatisation industrielle et les villes intelligentes. Il offre aux appareils un moyen simple et efficace de communiquer entre eux sur des réseaux limités, ce qui en fait un protocole idéal pour les applications IoT qui nécessitent une faible consommation d'énergie, une faible bande passante et un faible temps de latence.
CoAP et MQTT - quel est le meilleur protocole pour les appareils IoT alimentés par batterie ?
Grâce à sa faible surcharge et à son approche sans connexion, le protocole CoAP répond à toutes les exigences des appareils IoT alimentés par batterie. Découvrez quelles sont les principales différences et pourquoi CoAP devrait être le protocole de choix lors de la conception d'un appareil NB-IoT.
Vue d'ensemble du CoAP et MQTT
C'est quoi CoAP ?
Le protocole CoAP est similaire au protocole HTTP, mais il a été repensé pour répondre aux exigences des appareils alimentés par batterie et dotés de ressources limitées en termes de CPU et de RAM. Le protocole utilise UDP/IP comme couche de transport. Il en résulte un protocole qui utilise des paquets beaucoup plus petits, qui est plus simple que HTTP et qui a une empreinte plus faible (le plus petit message CoAP fait 4 octets contre 26 octets pour le plus petit message HTTP). De plus, CoAP a été conçu pour se traduire facilement en HTTP afin de simplifier l'intégration avec le web - les protocoles interopèrent par le biais de simples proxys. Tout comme HTTP, CoAP utilise le principe de client/serveur. Le client envoie une requête au serveur et le serveur renvoie une réponse. Les clients peuvent obtenir des ressources GET, PUT, POST et DELETE.
Comment fonctionne le MQTT ?
MQTT est un protocole de messagerie de type publication/abonnement conçu pour les communications M2M légères. Il repose sur un modèle client/serveur, dans lequel chaque appareil est un client et se connecte à un serveur, appelé broker. Le protocole utilise TCP/IP comme couche de transport. MQTT s'oriente plus sur les messages. Chaque message est publié à une adresse, appelée topic (sujet). Les clients peuvent s'abonner à plusieurs topics. Chaque client disposant d'un abonnement topic reçoit tous les messages publiés sur ce topic (sujet).
COAP vs MQTT Headers overhead des messages
La structure et la longueur de l'en-tête de base des messages MQTT et CoAP sont similaires. Pour le protocole CoAP, la taille minimale de l'option est de 4 octets, y compris l'identifiant du message. Le protocole MQTT requiert également un en-tête minimum de 4 octets : 2 octets - en-tête fixe (fixed header), 2 octets - identificateur de paquet (packet Identifier).
MQTT se base sur TCP et nécessite un remplacement de paquets sans perte. Par conséquent, le protocole UDP et d'autres couches de transport de réseau sans connexion telles que NB-IoT ne conviennent pas à MQTT, en raison de la possibilité de perte de données et de réorganisation des paquets. CoAP utilise plutôt UDP et ne nécessite pas de livraison sans perte et fournit une fragmentation à un niveau plus important.
MQTT implique la totalité de l'en-tête des paquets TCP/IP :
- En-têtes IPv4 - 20 octets (En-têtes IPv6 - 40 octets)
- Deux premiers messages handshake - 24 octets
- ACK final (acknowledgment) - 20 octets
En revanche, les paquets CoAP :
- En-têtes IPv4 - 20 octets (En-têtes IPv6 - 40 octets)
- En-têtes UDP - 8 octets
- Options CoAP - 11 octets (la taille de l'en-tête CoAP peut varier en fonction des options CoAP utilisées et de la longueur de l'uri. La taille dans l'exemple est celle de l'en-tête CoAP des capteurs Efento).
Si l'on considère que, dans la plupart des cas, chaque transmission de données (par exemple, le paquet de contrôle MQTT NOTIFY) nécessite un TCP ACK (20 octets), les économies réalisées grâce au protocole CoAP seront encore plus importantes.
Overhead du protocole
MQTT nécessite l'établissement d'une connexion avec le broker MQTT. À cette fin, le client utilise deux messages : PUBLISH, PUBACK. Une fois la connexion MQTT établie, le client peut publier des données en envoyant des messages PUBLISH au serveur. Le protocole MQTT utilise trois niveaux de qualité de service :
QoS 0 - les messages arrivent au maximum une fois et peuvent donc être perdus en cas de problèmes de connexion
Le QoS 1 - les messages ont une assurance d'arriver mais des doublons peuvent se produire
QoS 2 - les messages ont une assurance d'arriver exactement une fois
La QoS 1 (au moins une livraison) est la plus utilisée pour rendre la transmission fiable, le paquet de contrôle PUBACK MQTT confirmant chaque fois la publication des données. Si l'envoi de données est peu fréquent et nécessite que TCP et MQTT rétablissent les connexions à chaque fois, la surcharge relative devient énorme pour une petite charge utile de données. Cette solution n'est pas optimale lorsque les appareils sont maintenus en mode d'économie d'énergie la plupart du temps, ne se réveillant que pour envoyer une petite charge utile et retournant ensuite en mode d'économie d'énergie.
CoAP ne nécessite pas de configuration de connexion et de session au niveau TCP/IP.
Le protocole CoAP utilise deux types de messages :
• Message confirmable (NON)
• Message non confirmable (CON)
Lors de l'échange de messages entre deux points d'extrémité, ces messages peuvent être fiables. Dans le protocole CoAP, un message fiable s'obtient à l'aide d'un message confirmable (CON). Grâce à ce type de message, le client peut être sûr que le message arrivera au serveur. Un message confirmable est envoyé à plusieurs reprises jusqu'à ce que l'autre partie envoie un message d'accusé de réception (ACK). Le message ACK contient le même ID que le message confirmable (CON). Les messages non confirmables (NON) sont des messages qui ne nécessitent pas d'accusé de réception de la part du serveur.
COAP vs MQTT, comparaison de l'utilisation des données
Comparons la différence d'utilisation des données entre CoAP et MQTT sur la base de la payload générée par le capteur de température et d'humidité NB-IoT
Efento, qui prend des mesures toutes les 5 minutes et envoie les données au serveur toutes les heures. La payload contenant les mesures est la même pour les deux protocoles et a une taille de 84 octets. Les différences de taille de l'ensemble de la trame de données sont dues à la surcharge du protocole. L'envoi des mêmes données via le protocole CoAP utilise environ 70 % de données en moins par rapport au MQTT. Cela permet aux appareils de fonctionner plus longtemps sur les batteries (ils sont actifs moins longtemps, car ils ont besoin d'envoyer moins de données) et de consommer moins de bande passante, ce qui est important dans le cas des grands déploiements IoT prévus pour les années à venir.
