従来の HTTP プロトコルと比較した MQTT の利点は何ですか

HTTP は最も広く使用されており、人気のあるプロトコルです。 しかし、MQTT はここ数年で急速に普及してきました。 IoT 開発について議論する場合、開発者はこれら 2 つのうちのどちらかを選択する必要があります。

MQTT はデータに重点を置き、HTTP はドキュメントに重点を置きます。 HTTP はクライアント/サーバー コンピューティング用の要求/応答プロトコルですが、必ずしもモバイル デバイス用に最適化されているわけではありません。 これらの観点から、MQTT の主な利点は次のとおりです。軽量 (MQTT はバイト配列の形式でデータを転送します) とパブリッシュ/サブスクライブ モデルです。これにより、MQTT はリソースが限られたデバイスに非常に適しており、バッテリーの節約に役立ちます。 さらに、パブリッシュ/サブスクライブ モデルにより、クライアントを相互に独立させることができるため、システム全体の信頼性が向上します。 クライアントに障害が発生した場合でも、システム全体は正常に機能し続けます。

MQTT には、次のような多くの利点があります。

1. プロトコル オーバーヘッドが低い MQTT は、メッセージあたりのヘッダーを 2 バイトまで短くできるという点で独特です。 MQ と HTTP は両方とも、メッセージごとのオーバーヘッドがはるかに高くなります。 HTTP では、新しい要求メッセージごとに HTTP 接続を再確立すると、かなりのオーバーヘッドが発生します。 MQ と MQTT で使用される永続的な接続により、このオーバーヘッドが大幅に削減されます。

2. 不安定なネットワークに対する耐性があり、MQTT および MQ は切断などの障害から回復でき、追加のコード要件はありません。 ただし、HTTP ではこれをネイティブに行うことができないため、クライアントはエンコードを再試行する必要があり、冪等の問題がさらに増大する可能性があります。

3. 低消費電力、MQTT は低消費電力向けに特別に設計されています。 HTTP はこれを考慮して設計されていないため、消費電力が増加します。

4. HTTP スタック上で数百万の接続を持つクライアントが数百万の同時接続を維持するには、サポートを提供するために多大な作業が必要です。 このサポートは可能ですが、ほとんどの商用製品は、この規模の持続的な接続を処理できるように最適化されています。 IBM は、MQTT 経由で最大 100 万台の同時接続デバイスを処理できるようにテストされたシングル ラック マウント サーバーである IBM MessageSight を提供しています。 対照的に、MQTT は多数の同時クライアント向けに設計されていません。

5. プッシュ通知では、顧客にタイムリーに通知を配信できる必要があります。 このためには、ある種の定期的なポーリングまたはプッシュを使用する必要があります。 バッテリー、システム負荷、帯域幅の観点からは、プッシュが最適なソリューションです。

私たちのビジネスでは、サードパーティの仲介なしに機密情報を送信する必要がある場合があります。 これにより、主要なトランスポート メカニズムとしての OS 固有のソリューション (Apple iOS、Google Play 通知など) の価値が低下します。

HTTP では、永続的な HTTP リクエストを使用してプッシュを実行する、COMET と呼ばれる 1 つのメソッドのみが許可されます。 このアプローチは、クライアントとサーバーの両方の観点から見て高価です。 MQ と MQTT は両方とも、基本的な機能としてプッシュをサポートしています。

6. クライアント プラットフォームの違い。HTTP クライアントと MQTT クライアントは両方とも、多数のプラットフォームに実装されています。 MQTT のシンプルさは、ほとんど労力をかけずに追加のクライアントに MQTT を実装するのに役立ちます。

7. ファイアウォールのフォールト トレランス。一部の企業ファイアウォールでは、定義されたポートへの送信接続が制限されています。 通常、これらのポートは HTTP (ポート 80)、HTTPS (ポート 443) などに制限されています。HTTP は明らかにこのような状況でも機能します。 MQTT は、HTTP アップグレード リクエストとして表示される WebSocket 接続にラップでき、このような場合の操作が可能になります。 MQTT ではこのパターンは許可されません。

HTTP と比較して、MQTT プロトコルは高い転送速度を保証します。 サービス品質には 3 つのレベルがあります。

A. 多くても 1 回: 確実に配信するように努めます。

B. 少なくとも 1 回: メールが少なくとも 1 回送信されるようにします。ただし、メッセージは複数回配信することもできます。

C. 1 回だけ: 各メッセージが相手側で 1 回だけ受信されるようにします。

実際、MQTT は広く使用されています。 MQTT は、Facebook、BP、alibaba、baidu など、ほぼすべての大手ハードウェアおよびインターネット企業で見つけることができます。

MQTT 自体にはさまざまな技術的利点があるため、ますます多くの企業が MQTT を選択する傾向があります。 IoT 製品通信の標準プロトコルとしての MQTT。 したがって、エンジニアは、MQTT プロトコルには、大規模に商用化する場合には改善する必要がある機能がいくつかあることに徐々に気づきました。 例:

1. 完全な SDK はなく、さまざまな異種端末が MQTT サーバーと通信するには、対応するソフトウェア SDK パッケージが必要です。 たとえば、MCU、Linux、Android、IOS、WEB などの間の相互接続を実現するには、異なる SDK パッケージが必要です。

2. ファイルとAVはサポートされていません。 一部のアプリケーション シナリオでは、送信される情報は、ファイルや AV を通じて通信する必要があるオーディオ信号やビデオ信号などの命令に限定されない場合があります。

3. サードパーティの HTTP との統合はサポートされていません。 しかしMQTT プロトコルは通常の HTTP プロトコルよりも優れており、従来の HTTP プロトコルに基づく WEB サーバーが依然として主流の市場を占めているため、これらのサーバーはアップグレードを削減するために MQTT プロトコルとの相互接続を実現する必要があります。コストも重要です。
< br/>4. 負荷分散はサポートされていません。 高い同時実行性や悪意のある攻撃を防ぐために、負荷分散サーバーも不可欠です。

5. ユーザー管理インターフェースはサポートしていません。 ユーザーにとってデバイスの動作データを分析することは特に重要であり、これはインダストリー 4.0 とビッグデータ時代の必然的な要件です。

6. オフライン メッセージはサポートされておらず、デバイスがオフラインになった後に MQTT サーバーがデバイスの制御情報を失うという問題を補います。

7. ポイントツーポイント通信はサポートされておらず、標準の MQTT プロトコルが採用されます。 理論的には、ポイントツーポイント通信は相互サブスクリプションによって実現できますが、ロジックが比較的複雑であり、デバイスのセキュリティに懸念があります。 デバイス B とデバイス C が同じトピックにある場合、デバイス A はメッセージを送信したのがデバイス B であるかデバイス C であるかを知ることができず、メッセージがデバイス D によって盗聴される可能性もあります。

8. グループ通信やグループ管理はサポートしていませんが、グループメンバーの管理を実現し、グループメンバーは相互に通信できます。 1 台のデバイスが複数の人によって制御されたり、複数のデバイスが 1 人によって制御されたりするシナリオでは、特に役立ちます。