Quels sont les avantages de MQTT par rapport au protocole HTTP traditionnel

HTTP est le protocole le plus utilisé et le plus populaire. Mais MQTT a rapidement gagné du terrain au cours des dernières années. Lorsqu'il s'agit de développement IoT, les développeurs doivent choisir entre ces deux protocoles.

MQTT se concentre sur les données tandis que HTTP se concentre sur les documents. HTTP est un protocole de requête-réponse pour le calcul client-serveur, qui n'est pas toujours optimisé pour les appareils mobiles. Dans ces conditions, les principaux avantages de MQTT sont : léger (MQTT transfère les données sous forme de tableaux d'octets) et modèle de publication/abonnement, ce qui rend MQTT très adapté aux appareils aux ressources limitées et permet d'économiser la batterie. De plus, le modèle de publication/abonnement permet aux clients d'être indépendants les uns des autres, augmentant ainsi la fiabilité du système global. En cas de défaillance d'un client, l'ensemble du système continue de fonctionner normalement.

MQTT présente encore de nombreux avantages, comme suit :

1. Faible surcharge du protocole, MQTT est unique en ce sens que son en-tête par message peut être aussi court que 2 octets. MQ et HTTP ont tous deux une surcharge par message beaucoup plus élevée. Avec HTTP, le rétablissement de la connexion HTTP pour chaque nouveau message de demande entraîne une surcharge importante. Les connexions persistantes utilisées par MQ et MQTT réduisent considérablement cette surcharge.

2. Tolérance aux réseaux instables, MQTT et MQ peuvent récupérer après des échecs tels qu'une déconnexion, et il n'y a aucune exigence de code supplémentaire. Cependant, HTTP ne peut pas le faire de manière native, obligeant les clients à réessayer l'encodage, ce qui peut aggraver les problèmes d'idempotence.

3. Faible consommation d'énergie, MQTT est spécialement conçu pour une faible consommation d'énergie. HTTP n'a pas été conçu pour prendre cela en compte, augmentant ainsi la consommation d'énergie.

4. Les clients avec des millions de connexions, sur la pile HTTP, qui gèrent des millions de connexions simultanées nécessitent beaucoup de travail pour fournir une prise en charge. Bien que cette prise en charge soit possible, la plupart des produits commerciaux sont optimisés pour gérer les connexions persistantes de cet ordre de grandeur. IBM propose IBM MessageSight, un serveur à montage en rack unique testé pour gérer jusqu'à 1 million d'appareils connectés simultanément sur MQTT. En revanche, MQTT n'est pas conçu pour un grand nombre de clients simultanés.

5. Notifications push, vous devez être en mesure de diffuser des notifications aux clients en temps opportun. Pour cela, une sorte d'interrogation périodique ou de push doit être utilisée ; le push est la meilleure solution du point de vue de la batterie, de la charge du système et de la bande passante.

Notre entreprise peut avoir besoin d'envoyer des informations sensibles sans l'intermédiaire d'un tiers. Cela réduit la valeur des solutions spécifiques au système d'exploitation (telles que Apple iOS, les notifications Google Play) en tant que mécanisme de transport principal.

HTTP n'autorise qu'une seule méthode appelée COMET, utilisant des requêtes HTTP persistantes pour effectuer des push. Cette approche est coûteuse du point de vue du client et du serveur. MQ et MQTT prennent tous deux en charge le push en tant que fonctionnalité fondamentale.

6. Différences entre les plateformes client, les clients HTTP et MQTT ont été implémentés sur un grand nombre de plateformes. La simplicité de MQTT permet d'implémenter MQTT sur des clients supplémentaires avec très peu d'effort.

7. Tolérance aux pannes du pare-feu, certains pare-feu d'entreprise limitent les connexions sortantes à certains ports définis. Ces ports sont généralement limités à HTTP (port 80), HTTPS (port 443), etc. HTTP peut évidemment fonctionner dans ces situations. MQTT peut être encapsulé dans une connexion WebSockets qui apparaît comme une demande de mise à niveau HTTP, permettant ainsi le fonctionnement dans ces cas. MQTT n'autorise pas ce modèle.

Par rapport à HTTP, le protocole MQTT garantit un taux de transfert élevé. Il existe trois niveaux de qualité de service :

A. Au plus une fois : essayez de garantir la livraison.

B. Au moins une fois : assurez-vous que l'e-mail est envoyé au moins une fois, mais le message peut également être livré plusieurs fois.

C. Une seule fois : assurez-vous que chaque message n'est reçu qu'une seule fois par l'autre partie.

En fait, MQTT est largement utilisé. Vous pouvez trouver MQTT dans presque toutes les grandes entreprises de matériel et d'Internet, telles que Facebook, BP, Alibaba, Baidu, etc.

En raison des divers avantages techniques de MQTT lui-même, de plus en plus d'entreprises ont tendance à choisir MQTT comme protocole standard pour la communication des produits IoT. Par conséquent, les ingénieurs ont progressivement découvert que le protocole MQTT avait certaines fonctions qui devaient être améliorées s'il devait être commercialisé à grande échelle. Par exemple :

1. Il n'existe pas de SDK complet et différents terminaux hétérogènes ont besoin de packages SDK logiciels correspondants pour communiquer avec le serveur MQTT. Par exemple, pour réaliser l'interconnexion entre MCU, Linux, Android, IOS, WEB, etc., différents packages SDK doivent être requis.

2. Les fichiers et AV ne sont pas pris en charge. Dans certains scénarios d'application, les informations à transmettre peuvent ne pas se limiter aux instructions, telles que les signaux audio et vidéo, qui doivent communiquer via les fichiers et AV.

3. Il ne prend pas en charge l'intégration avec HTTP tiers. Bien queh le protocole MQTT est supérieur au protocole HTTP ordinaire, les serveurs WEB basés sur le protocole HTTP traditionnel occupent toujours le marché grand public, ces serveurs doivent donc réaliser l'interconnexion avec le protocole MQTT pour réduire les mises à niveau Le coût est également critique.

4. Il ne prend pas en charge l'équilibrage de charge. Afin d'éviter une concurrence élevée et des attaques malveillantes, un serveur d'équilibrage de charge est également essentiel.

5. Il ne prend pas en charge l'interface de gestion des utilisateurs. Il est particulièrement important pour les utilisateurs d'analyser les données de comportement des appareils, ce qui est une exigence inévitable de l'industrie 4.0 et de l'ère du big data.

6. Il ne prend pas en charge les messages hors ligne et compense le problème selon lequel le serveur MQTT perd les informations de contrôle de l'appareil une fois l'appareil hors ligne.

7. La communication point à point n'est pas prise en charge et le protocole MQTT standard est adopté. En théorie, la communication point à point peut être réalisée via un abonnement mutuel, mais la logique est relativement compliquée et il existe des inquiétudes concernant la sécurité de l'appareil. Lorsque l'appareil B et l'appareil C sont sur le même sujet, l'appareil A ne peut pas savoir si c'est l'appareil B ou l'appareil C qui a envoyé le message, et il est également possible que le message soit écouté par l'appareil D.

8. Il ne prend pas en charge la communication de groupe et la gestion de groupe, et réalise la gestion des membres du groupe, et les membres du groupe peuvent communiquer entre eux. Dans le scénario où un appareil est contrôlé par plusieurs personnes, ou plusieurs appareils sont contrôlés par une seule personne, particulièrement utile.