MosquittoのWebソケットを使用するか、クライアントを直接接続する必要がありますか？

このブログによると、Mosquitto（MQTTブローカー）はWebソケットを介したクライアントへの接続をサポートしています。ブログ記事は、Webソケットプロトコルが現在のブラウザーの大部分でサポートされているにもかかわらず、Webブラウザーが適切なTCPソケットを（まだ）サポートしていないため、Webソケットがブラウザーアプリケーションにとってより有用であることを示唆しているようです。

ネットワークにさまざまなクライアント（例：Raspberry Pisなどのマイクロコントローラーに基づくセンサーやアクチュエーター）しかない場合、直接TCP接続でWebソケットを使用する利点はありますか？ブラウザと通信しているときだけ、Webソケットプロトコルのオーバーヘッドはそれだけの価値がありますか？

ここでの質問は、「TCP経由のMQTTを使用するか、WebSocket経由のMQTT（これもTCP経由）を使用する必要があるか」のようです。言い換えれば、「MQTTをWebSocketプロトコルにカプセル化することは良い考えですか？」

これは（ほぼ）アプリケーションに完全にかかっており、Webソケットのサポートが必要かどうか-おそらくブラウザでメッセージを消費するためか、ファイアウォールの理由のためか。純粋なMQTTの場合、サーバーにポート1883またはそれ以上の8883でアクセスできない場合は、Webソケットが最適なオプションである可能性があります。

WebSocketsは追加の帯域幅を必要としますが、それがあなたにとって重要であるかどうかは、あなたしか答えられないものです。

Mosquittoの現在のバージョンでは、websocketがうまく機能しないため、websocketメッセージの送受信時に余分な遅延が発生する可能性があることにも注意してください。これは将来のバージョンでは問題にならないものです。

あなただけの内部で通信している場合は、あなたのネットワーク（イントラネット）、純粋なTCPを使用すると、罰金になります。ただし、別のサーバーに接続する必要がある場合は、問題が発生します。

最新のサーバーのほとんどは、クライアントがランダムなポートを介して接続することを許可していないためです。接続できるのは一部の専用ポートのみです。それで全部です。したがって、別のサーバーに接続する必要がある場合は、純粋なTCP接続ではなく、websocketを使用することをお勧めします。

オーバーヘッドを考慮している場合は、それほど大きくありません。WebSocketのオーバーヘッドについて詳しく知りたい場合は、この記事を参照してください。

私の個人的な意見では、深刻な懸念がある場合を除いて、常にwebsocketを使用することをお勧めします。

tl; dr- 自分自身をコーディングするよりも常に無料のライブラリを好む（極端な要件がない限り）

MosquittoのWebソケットを使用するか、クライアントを直接接続する必要がありますか？

文字列の長さはどれくらいですか？（YMMV）

私は一般的に話すことしかできませんが、私は常に生のソケットよりもラッパーライブラリを好みます（実際、ライブラリから無料で入手できるものをコーディングするよりも）。

これにより、コーディングが簡単になり、エラーが発生しにくくなります。彼らは多くのハウスキーピングとエラー処理を担当します。これは、自分で記述してデバッグする必要があるコードです。ライブラリは一般によくレビューされテストされており、他の何千人ものユーザーによって使用されています。バグを報告/修正します。

さらに、維持する（そして場合によっては移植する）コードも少なくて済みます。つまり、アプリの開発、テスト、および磨き、または次のアプリへの移行により多くの時間がかかります。

唯一のオーバーヘッドは間違いなく関数呼び出しです。ライブラリアンのすべての優れた点（エラー処理、ホース管理など）が、安定した優れたソフトウェアを入手するために自分でコーディングする必要があることを受け入れる場合。

パフォーマンスが気になる場合は、プロファイルを作成してください。しかし、あなたのソケットが毎秒何百回もアクティブでなければ、私は気にさえしません。