MQTT over TLSとMQTTのパフォーマンス

MQTTは非常に用途が広いですが、それ自体も保護されていません。これは仕様によるものです。

Stanford-Clark氏によると、セキュリティを強化するためにセキュリティメカニズムをMQTTの周りに配置できることを彼とNipperが知っていたため、セキュリティは当初プロトコルから意識的に除外されていました。また、当時、スタンフォードクラーク氏は、気象観測所からの風速データなど、MQTTを介して送信される情報は特に保護する必要はないとしました。- ソース

MQTTにラップできるセキュリティメカニズムの1つはTLSです。今日、ほとんどのブローカーがこれをサポートしています。もちろん、ラッピングメジャーによってオーバーヘッドが生じます。このオーバーヘッドは無視できる可能性があります（HiveMQブログを参照）。

現在、私のプロジェクトのMQTTの実行可能性を評価するために、TLSを介したMQTTと単純なMQTTのパフォーマンスの低下に関する情報（できれば信頼できる情報源）を探しています。特に、テクノロジーが多数の加入者に拡大する場合。

MQTT over TLSのパフォーマンスに関する有効なデータを取得するためのプロトタイピング以外の方法はありますか？

いったん接続が確立されると、違いがあまりにも大きくなるとは思わないでしょう。

TLSが一般的に生成するオーバーヘッドの内訳は、こちらで確認できます。重要なビットは次のとおりです。

• 新しいTLSセッションを確立するための総オーバーヘッドは、平均で約6.5kバイトになります。
• 既存のTLSセッションを再開するための合計オーバーヘッドは、平均で約330バイトになります。
• 暗号化されたデータのオーバーヘッドの合計は約40バイト（20 + 15 + 5）
• 環境の詳細をより正確に反映するように上記の計算を変更するのは簡単なので、これはTLSオーバーヘッドの基礎と見なされるべきであり、提起された質問に対する信頼できる回答ではありません。

これらの数値がどのように計算されたかを確認することは一読の価値があります。TLSがこれらすべてでどのように機能するかをより深く理解する必要があります。他の回答で述べたように、無線送信はエネルギーの最大の使用の1つである可能性が高く、これは多くの場合IoTの制約であるため、セッションが確立されると、特にメッセージがさほど短くはない。

記事のHiveMQで述べられているように、TLSはMQTTのパフォーマンスにどのように影響しますか？：

良い知らせは、MQTTクライアントは、セッションごとに1回だけ接続を確立する必要があることです。HTTPなどのプロトコルとは異なり、すべてのリクエストで接続を再確立する必要があります（キープアライブが使用されていない場合、またはLongのような他の手法の場合）ポーリングが実施されています）。ブローカーに接続すると、クライアントは追加のハンドシェイクオーバーヘッドなしでメッセージを送受信できます。TLSを使用するには、追加のバッファーを割り振る必要があるため、RAMの消費量もMQTT接続ごとにわずかに多くなります。

また、50,000のクライアントが接続したときのブローカーのCPU使用率のグラフも提供します。

^{画像ソース：HiveMQ（上記のリンクされた記事を参照）}

これはほとんどの場合典型的な使用パターンではありませんが、それでもデータは興味深いことに注意してください。ご覧のとおり、ハンドシェイクの進行中は大きなオーバーヘッドがありますが、その後はCPUオーバーヘッドはほとんど同じです。クライアントにも同様のことが期待されます。

それでも、ここでの一般的なアドバイスは正しいです。人為的なベンチマークでは、本当に必要な情報は得られません。TLSがユースケースにどのように影響するかを知るには、それをテストする必要があります... ユースケース！

実際には、特定の状況をテストしてベンチマークする必要があります。以下は、パフォーマンスに直接影響する可能性があります。

• どのクライアント/ブローカーハードウェアを使用していますか？暗号化用のハードウェアアクセラレーションはありますか？
• 送信するペイロードのサイズはどれくらいですか？
• アプリケーションの接続/再接続プロファイルは何ですか？

有用なパフォーマンス推定を行うことは困難です。アプリケーションは少なくともそのトラフィックの一部に対して暗号化を必要とする可能性が高いため、トラフィックのこのサブセットでセキュリティを利用できるようにするための実装コストはほとんどありません。

エネルギーに制約のある実装の場合、送信はワイヤレスになる可能性があります。適切な無線チャネルがあっても、チャネルの設定と接続のネゴシエーションのエネルギーコストは、特に一部のメッセージが暗号化を必要とする場合、単純なメッセージの暗号化の処理コストを上回る可能性があります。

メッセージが重要なものである場合、ネットワークトラフィックを削減するためにエンドポイントでより多くの処理を実行することには正当な理由があるかもしれません。

最後に、チャネルの負荷が高いシナリオでは、システム全体のより簡単な実装の分析から期待するほどパフォーマンスが良くない場合があります。

探しているデータの参照を見つけることができたとしても、設計上の決定の基礎となるのに十分である十分な質問に答えることはほとんどありません。