MQTT をわかりやすく解説: なぜ MQTT が IoT に選ばれるプロトコルなのでしょうか?

記事ディレクトリ

ここに画像の説明を挿入します

MQTT プロトコルの概要

概要

MQTT は、パブリッシュ/サブスクライブモデルに基づく軽量のメッセージ送信プロトコルで、特に低帯域幅で不安定なネットワーク環境向けに設計されています。IoT 向けに設計されています。アプリケーションでは、非常に少ないコードで、接続されたデバイスにリアルタイムで信頼性の高いメッセージングサービスを提供できます。 MQTT プロトコルは、モノのインターネット、モバイルインターネット、スマートハードウェア、車両のインターネット、スマートシティ、遠隔医療、電力、石油、エネルギーなどの分野で広く使用されています。

MQTT プロトコルは、Andy Stanford-Clark (IBM) と Arlen Nipper (Arcom、現在は <) によって開発されました。 a i= 4>) は 1999 年にリリースされました。 Nipper の紹介によると、MQTT には次の点が必要です。Cirrus Link

シンプルで実装が簡単
QoSをサポート（デバイスのネットワーク環境が複雑）
軽量で帯域幅を節約できる (当時帯域幅が高価だったため)
データに依存しない (ペイロードのデータ形式を気にしない)
継続的なセッション認識 (デバイスがオンラインかどうかを常に把握)

に関するArlen Nipper の自己報告によると、MQTT の元の名前は MQ TT< /span> 経由で IBM の MQ Integrator と通信できるようにすることです。 Nipper はリモートセンシング、データ収集、監視の専門家であるため、業界の慣例に従って MQ TT という名前を選択しました。 VSAT) 用に開発されたリアルタイムデータ送信プロトコル。その目的は、センサーが帯域幅制限のある会社監視システム (、これは、彼が 1990 年代初頭に参加した原油パイプラインのデータ収集です。、MQ と TT の間のスペースに注意してください。正式名称は IBM PodcastMQ Telemetry TransportConoco Phillipspipeline SCADA system

MQTT と他のプロトコルの比較

MQTT と HTTP

MQTT の最小メッセージはわずか 2 バイトであり、HTTP よりもネットワークオーバーヘッドの消費が少なくなります。
MQTT と HTTP はどちらも TCP 接続を使用でき、安定した信頼性の高いネットワーク接続を実現できます。
MQTT はパブリッシュ/サブスクライブモデルに基づいており、HTTP はリクエスト/レスポンスに基づいているため、MQTT は二重通信をサポートします。
MQTT はリアルタイムでメッセージをプッシュできますが、HTTP ではデータ更新のためにポーリングが必要です。
MQTT はステートフルですが、HTTP はステートレスです。
MQTT は、HTTP では不可能な異常な接続切断から回復できます。

MQTT と XMPP の比較

MQTT プロトコルは、シンプルで軽量な設計と柔軟なルーティングを備えており、モバイルインターネットや IoT メッセージングの分野で PC 時代の XMPP プロトコルを完全に置き換えます。

MQTT メッセージはサイズが小さく、エンコードとデコードが簡単ですが、XMPP は重い XML に基づいているため、メッセージサイズが大きく、対話が煩雑です。
MQTT はパブリッシュ/サブスクライブモデルに基づいており、XMPP の JID ベースのポイントツーポイントメッセージルーティングよりも柔軟です。
MQTT は、JSON やバイナリなどのさまざまなタイプのメッセージをサポートします。 XMPP は XML を使用してメッセージを伝送します。バイナリは Base64 でエンコードされ、処理される必要があります。
MQTT は QoS を通じてメッセージの信頼性の高い送信を保証しますが、XMPP メインプロトコルは同様のメカニズムを定義していません。

なぜ MQTT が IoT に最適なプロトコルなのでしょうか?

IoT Analytics が発表した最新の「State of the Internet of Things Spring 2022」調査レポートによると、IoT 市場は 2022 年までに 18% 成長し、14.4 に達すると予想されています。 10 億 a>アクティブな接続。

モノのインターネットに対するこのような大規模な需要に伴い、大量のデバイスアクセスとデバイス管理がネットワーク帯域幅、通信プロトコル、プラットフォームサービスアーキテクチャに大きな課題をもたらしています。 モノのインターネットプロトコルでは、IoT デバイス通信におけるいくつかの重要な問題を的を絞った方法で解決する必要があります。ネットワーク環境は複雑で信頼性が低く、メモリとフラッシュの容量が小さく、プロセッサの能力も限られています。

MQTT プロトコルは、上記の問題に対処するために作成され、数年にわたる開発を経て、軽量、効率的、信頼性の高いメッセージング、大規模な接続サポート、安全な双方向通信という利点により、モノのインターネット業界で推奨されるプロトコルになりました。

ここに画像の説明を挿入します

軽量かつ効率的で帯域幅を節約

MQTT は、プロトコル自体が占有する追加消費量を最小限に抑え、メッセージヘッダーが占有する必要があるのは最低 2 バイトだけであり、帯域幅が限られたネットワーク環境でも安定して実行できます。同時に、MQTT クライアントは非常に少量のハードウェアリソースのみを必要とし、リソースが限られたさまざまなエッジデバイス上で実行できます。

信頼できるメッセージング

MQTT プロトコルは、さまざまなネットワーク環境でのメッセージ配信の信頼性を確保するために、3 つのメッセージのサービス品質レベル (Quality of Service) を提供します。

QoS 0: メッセージは最大 1 回配信されます。
その時点でクライアントが利用できない場合、メッセージは失われます。発行者はメッセージを送信すると、それが相手に送信されるかどうかを気にしなくなり、再送信メカニズムも設定しなくなります。
QoS 1: メッセージは少なくとも 1 回配信されます。
単純な再送信メカニズムが含まれています。発行者はメッセージを送信した後、受信者の ACK を待ちます。ACK が受信されない場合は、メッセージを再送信します。このモードでは、メッセージが少なくとも 1 回到着することが保証されますが、メッセージが繰り返されることは保証できません。
QoS 2: メッセージは 1 回だけ配信されます。
メッセージが確実に相手に確実に 1 回だけ到達するように、再送信および重複メッセージ検出メカニズムを設計しました。

QoS に加えて、MQTT はセッションのクリア (クリーンセッション) メカニズムも提供します。再接続後にオフライン期間中に失われたメッセージを受信したいクライアントの場合、接続時にクリアセッションを閉じるように設定できます。このとき、サーバーはクライアントのサブスクリプション関係とオフラインメッセージを保存し、セッションを再試行します。オンラインになった後、クライアントに送信されます。

大規模な接続のサポート

MQTT プロトコルは、その誕生以来、IoT デバイスの増加を考慮してきました。その優れた設計のおかげで、MQTT ベースの IoT アプリケーションとサービスを簡単に実装できます。 高い同時実行性、高スループット、および高スケーラビリティ機能。

多数の IoT デバイスを接続するには、MQTT サーバーのサポートが不可欠です。現在、EMQX は、最大数の同時接続をサポートする MQTT サーバーです。最近リリースされた EMQX 5.0 は、23 ノードのクラスターを通じて **1 億 MQTT 接続 +** 毎秒 100 万メッセージスループットを達成しました。これにより、EMQX 5.0 は世界で最もスケーラブルな MQTT サーバーとなりました。これまでのところ。

安全な双方向通信

MQTT は、パブリッシュ/サブスクライブモデルに基づいて、デバイスとクラウド間の双方向メッセージ通信を可能にします。パブリッシュ/サブスクライブモデルの利点は、パブリッシャーとサブスクライバーが直接接続を確立する必要がなく、同時にオンラインである必要もないことです。代わりに、メッセージサーバーがすべてのメッセージのルーティングと配布を担当します。メッセージ。

セキュリティはすべての IoT アプリケーションの基礎であり、MQTT は TLS/SSL を介した安全な双方向通信をサポートします。また、MQTT プロトコルで提供されるクライアント ID、ユーザー名、パスワードを使用して、アプリケーション層の認証と認可を実装できます。

存在認識

ネットワークの不安定性に対処するために、MQTT は **ハートビートキープアライブ (Keep Alive)** メカニズムを提供します。クライアントとサーバー間で長期間メッセージのやり取りがない場合、Keep Alive により接続が切断されなくなります。切断された場合、クライアントは即座にそれを感知し、すぐに再接続できます。

同時に、MQTT はLast Will メッセージを設計し、クライアントが異常にオフラインになったことをサーバーが発見したときに支援できるようにしました。クライアントは、指定されたMQTT トピックにラストウィッシュメッセージをパブリッシュします。

さらに、EMQX などの一部の MQTT サーバーは、オンラインおよびオフラインのイベント通知機能も提供します。バックエンドサービスが特定のトピックをサブスクライブすると、すべてのクライアントからオンラインイベントとオフラインイベントを受信できます。これにより、バックエンドサービスが均一に処理することができます。クライアントのオンラインおよびオフラインイベント。

MQTT 5.0 および 3.1.1

MQTT 3.1.1 がリリースされて OASIS 標準となってから 4 年後、MQTT 5.0 が正式にリリースされました。これは大幅な改善とアップグレードであり、その目的は、現在の業界のニーズを満たすだけでなく、業界の将来の発展と変化に適切に備えることです。

バージョン 3.1.1 をベースにした MQTT 5.0 では、セッション/メッセージの遅延、理由コード、トピックエイリアス、ユーザー属性、共有サブスクリプション、および最新のモノのインターネットアプリケーションのニーズにより一致するその他の機能が追加され、パフォーマンス、安定性、およびパフォーマンスが向上します。大規模システムの信頼性、拡張性。現在、MQTT 5.0 はほとんどの IoT 企業で選ばれるプロトコルとなっており、MQTT を初めて使用する開発者にはこのバージョンを直接使用することをお勧めします。

MQTTサーバー

MQTT サーバーは、クライアントによって開始された接続を受信し、クライアントによって送信されたメッセージを他の資格のあるクライアントに転送する責任を負います。成熟した MQTT サーバーは、大規模なクライアント接続と百万レベルのメッセージスループットをサポートできるため、IoT サービスプロバイダーはビジネス機能に集中し、信頼性の高い MQTT アプリケーションを迅速に作成できます。

EMQX は、広く使用されている大規模な分散 IoT MQTT サーバーです。 2013 年にオープンソース版が GitHub でリリースされて以来、世界中で 1,000 万回以上ダウンロードされ、1 億台以上の主要な IoT デバイスに接続されています。

興味のある方は、次の Docker コマンドを使用して EMQX 5.0 オープンソースバージョンをインストールし、体験してください。

docker run -d --name emqx -p 1883:1883 -p 8083:8083 -p 8084:8084 -p 8883:8883 -p 18083:18083 emqx/emqx:latest

フルマネージドの MQTT サービスを EMQX クラウド上に直接作成することもできます。

MQTTクライアント

MQTT アプリケーションは通常、MQTT 通信を実装するために MQTT クライアントライブラリに基づいている必要があります。現在、基本的にすべてのプログラミング言語には、成熟したオープンソースの MQTT クライアントライブラリがあります。EMQ によってコンパイルされた MQTT クライアントライブラリの完全なリストを参照して、適切なものを選択できます。独自のビジネスニーズを満たす MQTT クライアントを構築するためのクライアントライブラリ。

MQTT アプリケーション開発は、MQTT テストツールのサポートとも切り離すことができず、使いやすく強力な MQTT テストツールは、開発者が開発サイクルを短縮し、安定した IoT アプリケーションを作成するのに役立ちます。

MQTTX は、オープンソースのクロスプラットフォームデスクトップクライアントです。使いやすく、包括的な MQTT 5.0 の機能と機能のテストを提供します。macOS、Linux、Windows で実行できます。。同時に、さまざまなシナリオでの MQTT テストのニーズを満たすコマンドラインバージョンとブラウザバージョンも提供します。興味のある方は、MQTTX 公式 Web サイトにアクセスして、ダウンロードして試してみてください。
ここに画像の説明を挿入します
今日はここまでです。ぜひ皆さんもダウンロードして体験してください。

参考リンク：https://www.emqx.com/zh/blog/what-is-the-mqtt-protocol#mqtt-%E5%8D%8F%E8%AE%AE%E7%AE%80%E4% BB%8B