Pourquoi WebSockets pour MQTT
Les navigateurs ne peuvent pas ouvrir de sockets TCP brutes. MQTT over WebSockets est donc la voie standard pour utiliser MQTT dans le web.
Cela permet aux dashboards d’abonner des flux temps reel sans polling.
Considerations de performance
Les frames WebSocket ajoutent un peu d’overhead, mais la connexion persistante reste bien plus efficace que du polling HTTP.
Pour des dashboards temps reel, MQTT sur WebSockets est souvent plus fluide.
Securite dans le navigateur
Utilisez WSS et des tokens courts. Les tokens web sont plus exposes, il faut limiter les droits.
Appliquez des ACL strictes pour limiter les topics accessibles.
Limites de connexions
Les navigateurs peuvent ouvrir plusieurs connexions (multi-onglets). Favorisez une connexion unique cote client.
Cote broker, limitez les connexions par user et imposez des timeouts.
Taille des payloads
Les UIs ne doivent pas recevoir des payloads trop lourds. Publiez des messages compacts et utilisez HTTP pour les grosses donnees.
Cela garde MQTT en temps reel sans penaliser l’UI.
Strategies de fallback
Si WebSockets sont bloques, prevoyez un fallback polling pour un sous-ensemble.
Expliquez clairement que le mode fallback est moins instantane.
Quand l’eviter
Si votre app ne recoit que rarement des mises a jour, HTTP peut suffire. MQTT sur WebSockets brille pour le temps reel.
Utilisez-le pour presence, statut et suivi des commandes.