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 を WebSocket 接続にラップして、HTTP アップグレード リクエストとして表示し、このような場合の操作を可能にすることができます。MQTT ではこのパターンは許可されません。
HTTP と比較して、MQTT プロトコルは高い転送速度を保証します。サービス品質には 3 つのレベルがあります。
A. 多くても 1 回: 確実に配信できるようにしてください。
B. 少なくとも 1 回: 電子メールが少なくとも 1 回送信されるようにします。ただし、メッセージは複数回配信することもできます。
C. 一度だけ: 各メッセージが相手側で一度だけ受信されるようにします。
実際、MQTT は広く使用されており、Facebook、BP、alibaba、baidu など、ほぼすべての大手ハードウェア企業やインターネット企業で MQTT を見つけることができます。
MQTT 自体のさまざまな技術的利点により、ますます多くの企業が MQTT を IoT 製品通信の標準プロトコルとして選択する傾向にあり、技術者は、MQTT プロトコルが実現するには改善が必要な機能があることに徐々に気づきました。大規模に商品化されました。例えば：
1. 完全な SDK はなく、異なる異種端末が MQTT サーバーと通信するには、対応するソフトウェア SDK パッケージが必要です。たとえば、MCU、Linux、Android、IOS、WEB などの間の相互接続を実現するには、異なる SDK パッケージが必要です。 。
2. ファイルと AV はサポートされていない アプリケーション シナリオによっては、送信される情報が、ファイルや AV を介して通信する必要があるオーディオ信号やビデオ信号などの命令に限定されない場合があります。
3. サードパーティの HTTP との連携には対応していません MQTT プロトコルは通常の HTTP プロトコルよりも優れていますが、依然として従来の HTTP プロトコルに基づく WEB サーバーが市場の主流を占めているため、これらのサーバーは MQTT との相互接続を実現する必要があります。アップグレードを削減するためのプロトコル コストも重要です。
4. 負荷分散には対応していないため、同時実行性の高さや悪意のある攻撃を防ぐため、負荷分散サーバーも必須です。
5. ユーザー管理インターフェイスはサポートされていないため、ユーザーにとってデバイスの動作データを分析することは特に重要であり、これはインダストリー 4.0 とビッグデータ時代の必然的な要件です。
6. オフライン メッセージをサポートせず、デバイスがオフラインになった後に MQTT サーバーがデバイスの制御情報を失うという問題を補います。
7. ポイントツーポイント通信はサポートしておらず、標準のMQTTプロトコルを採用 原理的には相互サブスクリプションによりポイントツーポイント通信を実現できるが、ロジックが比較的複雑でセキュリティに懸念があるデバイスの。デバイス B とデバイス C が同じトピックにある場合、デバイス A はメッセージを送信したのがデバイス B であるかデバイス C であるかを知ることができず、メッセージがデバイス D に盗聴される可能性もあります。
8. グループ通信とグループ管理はサポートしていませんが、グループ メンバーの管理を実現し、グループ メンバーは相互に通信できます。1 台のデバイスが複数人によって制御されたり、複数のデバイスが 1 人によって制御されたりするシナリオでは、特に便利です。