Performances de MQTT sur TLS par rapport à MQTT

Bien que MQTT soit assez polyvalent, il n'est pas non plus sécurisé sur lui-même. C'est par conception.

Selon Stanford-Clark, la sécurité a été consciemment exclue du protocole au départ parce que lui et Nipper savaient que les mécanismes de sécurité pouvaient être intégrés au MQTT pour renforcer la sécurité. De plus, à l'époque, Stanford-Clark a déclaré que les informations envoyées via MQTT, telles que les données de vitesse du vent d'une station météo, n'avaient pas particulièrement besoin d'être sécurisées. - Source

TLS est l'un de ces mécanismes de sécurité qui peuvent être intégrés à MQTT. La plupart des courtiers le soutiennent de nos jours. Bien sûr, toute mesure d'emballage produit des frais généraux. Ce surcoût peut être négligeable (cf. blog HiveMQ ).

Actuellement, je recherche des informations (je l'espère, une source faisant autorité) sur la perte de performances de MQTT sur TLS par rapport à MQTT ordinaire pour évaluer la viabilité de MQTT pour mon projet. Surtout lorsque la technologie évolue dans un grand nombre d'abonnés.

Existe-t-il un moyen, outre le prototypage, d'obtenir des données valides sur les performances de MQTT sur TLS?

Je ne m'attendrais pas à ce que la différence soit trop importante, une fois la connexion établie .

Une ventilation des frais généraux produits par TLS en général peut être trouvée ici . Les bits importants sont:

• La surcharge totale pour établir une nouvelle session TLS s'élève à environ 6,5 k octets en moyenne
• Le temps système total pour reprendre une session TLS existante s'élève à environ 330 octets en moyenne
• La surcharge totale des données cryptées est d'environ 40 octets (20 + 15 + 5)
• Il est facile de modifier les calculs ci-dessus pour refléter plus précisément les spécificités d'un environnement, donc cela devrait être considéré comme une base pour les frais généraux TLS et non comme la réponse faisant autorité à la question posée.

Cela vaut la peine d'être lu pour voir comment ces chiffres ont été calculés - vous devriez mieux comprendre comment TLS fonctionne avec tout cela. Comme indiqué dans d'autres réponses, la transmission radio est probablement l'une des plus grandes utilisations de l'énergie, ce qui est souvent une contrainte dans l'IoT, donc une fois la session établie, les frais généraux ne sont pas trop importants, surtout si vos messages sont pas trivialement court.

Comme indiqué par HiveMQ dans l'article Comment TLS affecte-t-il les performances MQTT? :

La bonne nouvelle est qu'un client MQTT n'a besoin d'établir une connexion qu'une seule fois par session - contrairement aux protocoles comme HTTP, qui doit rétablir une connexion à chaque demande (si aucun maintien en vie n'est utilisé ou d'autres techniques comme Long Les sondages sont en place). Une fois connecté au courtier, le client peut envoyer et recevoir des messages sans surcharge de prise de contact supplémentaire. L'utilisation de TLS doit allouer des tampons supplémentaires, de sorte que la consommation de RAM est également légèrement plus élevée par connexion MQTT.

Ils fournissent également un graphique de l'utilisation du processeur sur le courtier lorsque 50 000 clients se connectent:

^{Source de l'image: HiveMQ (voir l'article lié ci-dessus)}

Notez que ce n'est certainement pas un modèle d'utilisation typique, mais les données sont néanmoins intéressantes. Comme vous pouvez le voir, il y a une surcharge importante pendant que les poignées de main sont en cours, mais après cela, la surcharge du processeur est presque identique. Je m'attendrais à une chose similaire sur le client.

Pourtant, les conseils généraux ici sont corrects: une référence artificielle ne vous donnera pas les informations dont vous avez vraiment besoin; pour savoir comment TLS affectera votre cas d'utilisation, vous devez le tester dans ... votre cas d'utilisation !

Pas vraiment, vous allez devoir tester et comparer votre situation spécifique. Les éléments suivants sont susceptibles d'avoir un impact direct sur les performances.

• Quel matériel client / courtier utilisez-vous, at-il une accélération matérielle pour la cryptographie?
• Quelle est la taille de la charge utile que vous envoyez?
• Quel est le profil de connexion / reconnexion pour votre application?

Il est difficile de faire des estimations de performances utiles. Il est probable que votre application nécessite un chiffrement pour au moins une partie de son trafic, il est donc peu probable qu'il y ait un coût de mise en œuvre pour rendre la sécurité disponible pour ce sous-ensemble du trafic.

Pour une mise en œuvre contrainte par l'énergie, la transmission est susceptible d'être sans fil. Même avec un canal radio approprié, le coût énergétique de la configuration du canal et de la négociation de la connexion est susceptible de l'emporter sur le coût de traitement pour le cryptage d'un message simple - en particulier si certains messages nécessitent un cryptage.

Si vos messages ne sont pas anodins, il peut être justifié d'effectuer davantage de traitement au niveau du point de terminaison pour réduire le trafic réseau.

Enfin, dans un scénario où le canal est lourdement chargé, les performances peuvent ne pas être aussi bonnes que ce que vous attendez de l'analyse d'une implémentation plus triviale de votre système complet.

Même si vous pouvez trouver une référence pour les données que vous recherchez, il est peu probable qu'il réponde suffisamment à la question pour être suffisant pour fonder les décisions de conception.