MQTT
ウィキペディアから
MQTT（旧称：MQ Telemetry Transport、Message Queuing Telemetry Transport）は、メッセージ指向ミドルウェアのアプリケーション層で使用される、TCP/IPによるPub/Sub型データ配信モデルの軽量なデータ配信プロトコルである。
 |
MQTTのMQは、歴史的にはMQSeriesから来ているが、メッセージキューの機能は持たない。
非力なデバイスやネットワークが不安定な場所でも動作しやすいように、メッセージ通信電文が軽量に設計されていることが特徴である。
Pub/Sub型メッセージング·パターンには、サーバとしてメッセージブローカーが必要である。
サーバは、メッセージのトピックに基づいて、それを必要としているクライアントにメッセージを配布する。
1999年にIBMのアンディー・スタンフォード・クラークとArcom Control Systemsのアーレンニッパーによりプロトコルの最初のバージョンが執筆された。[5]
その年の内にVersion 2を定義し、1999年10月22日にアップデートしたVersion 2.3でVersion3.1.1相当のパケットを備えるものとなった。[5][6]
2000年にはVersion 3.0がリリースされた。[5]
2007年にEurotechに買収されたArcom Control Systemsは社名もEurotechに変更したため、MQTTの仕様はIBMとEurotechが管理するものになった。
2010年にVersion 3.1がリリースされた。[5]
2014年10月29日にVersion 3.1.1がリリースされ11月13日に発表された。[7][8] このバージョンからOASISが仕様を管理している。 また、2016年6月にISO/IEC標準のISO/IEC 20922:2016として採用された。[9] [10]
MQTTには次のような特徴がある。
軽量なプロトコル
プロトコル電文仕様は軽量でシンプルになっていてヘッダーサイズは最小で２バイトである。[12]
MQTTはロスレスで順序保証がされた双方向通信のプロトコル上で動作することが前提となっていて、TCP/IPとTLSとWebSocketが仕様で言及されている。[13]ただし、これらのプロトコルを使用することに限定はしていない。
柔軟性の高いメッセージ配布(Sub：購読)
配布先条件が/区切りの階層構造になっており、さらにワイルドカードによる指定ができる。[14]
配布先はそのパターンにマッチした宛先になる。
- トピックベースでのPub/Sub
- 1対1、1対N、N対Nのメッセージ配布
メッセージ配布の品質
三種類の QoS (Quality of Service) レベルの指定ができる。[15]
QoSレベルは単一の送信者と単一の受信者の間で適用される。[15]
つまりサーバが同一のメッセージを複数のクライアントに配布を行う場合はそれぞれのクライアントで異なるQoSレベルが使用される場合がある。[15]
またメッセージを配布するクライアントとサーバ間、トピックに応じて配布するサーバとクライアント間でも同じことが言えるためアプリケーションメッセージの品質を定義するものではない。
QoS 0: At most once delivery
最高１回の送信を行う。[16] 使用しているトランスポート層の性能に応じたメッセージ配布を行う。[15] メッセージが確実に届く保証はない。 メッセージ配布に失敗しても再送をしない。
QoS 1: At least once delivery
最低１回の送信を行う。[17] 必ずメッセージを配布するが、重複する可能性がある。
QoS 2: Exactly once delivery
正確に１回の送信を行う。[18] 必ずメッセージを配布して、重複も発生しない。
メッセージ再配布機能
クライアントが再接続をしたときにセッションが残っている場合はクライアントとサーバの両方が確認応答がないPUBLISHパケットとPUBRELパケットを再送信する。[19]
これはメッセージが再配布される唯一の機会である。[19]
QoS 0のPUBLISHパケットの再送信は行われない。
Willメッセージ
クライアントとの接続が正常にクローズされなかったときにサーバによって配布されるメッセージのこと。 [20]
クライアントがサーバに接続する際にCONNECTパケットにWillフラグとWillメッセージを含める。サーバはCONNECTパケットを受け入れた場合はWillメッセージをセッションに関連付けて保存する。[21]
サーバはクライアントとのネットワーク接続が正常ではない方法でクローズされたとき保存しているWillメッセージを購読している別のクライアントに配布する。[21]
MQTT Version 3.1までの仕様にはLast Will and Testamentと書かれていた。[12] そのためLWTと言う略称で説明される場合がある。[22]
Retain
クライアントがRetainフラグを有効にして配布したメッセージはサーバでトピックごとに上書き保存される。[23]
クライアントがトピックの購読を行った際に保存されたメッセージがある場合はサーバにより購読したクライアントに配布される。
これによりクライアントはトピック購読前の最後のメッセージを受け取ることができる。
セキュリティ
MQTTは仕様として具体的なセキュリティの規定はない。 基本的に実装依存と下位層が持つ既存のセキュリティ技術を利用することとなっている。 ただし以下の言及がある。
CONNECTパケットにユーザネームとパスワードを含めることができる。[24][25] これらを使ってBasic認証を行うことができる。[26] ただし、これらのフィールドをBasic認証のみに使うことに限定しておらず、パスワードフィールドをベアラ認証のトークンを渡すために使うことなども言及している。[25][26][27] MQTT Version 5.0からユーザネームを省略してパスワードのみクライアントからサーバに通知することができるようになった。[注釈 1][28]
認可のために先述のユーザネームとパスワード以外にCONNECTパケットに含まれるクライアント識別子や下位層のプロトコルから得られるホスト名やIPアドレスが利用できることも言及している。[29]
MQTT Version 5.0からAUTHパケットが追加され、２往復以上のハンドシェイクが必要な認証アルゴリズムにも対応できるようになった。[26]
暗号化はTLSまたはVPNが利用できることに言及している。[30]
OASISに管理が移管されたMQTT Version 3.1.1より、NISTのサイバーセキュリティフレームワークのMQTTを使用する際のガイドラインが用意された。[31]
CONNECT/CONNACK
クライアントがサーバーとの接続が確立されるのを待機し、ノード間でセッションを作成する。
MQTT Version 5.0でサーバのオプション機能をクライアントに通知するために多くのパラメータが追加された。[32]
SUBSCRIBE
クライアントがサーバにトピックを登録する。[33]
PUBLISH
アプリケーションメッセージを配布するためにクライアントからサーバ、またはサーバからクライアントに送信される。[34]
クライアントからPUBLISHパケットを受信したサーバはトピックを購読しているクライアントにPUBLISHパケットでメッセージの転送を行う。
DISCONNECT
MQTTクライアントが必要な処理を完了し、TCP/IPセッションが切断されるのを待機する。
MQTT Version 5.0よりサーバからもDISCONNECTパケットを送信する場合がある。[32]
MQTTをサポートするブローカー（MQサーバ）は数多くある。それぞれのサーバがサポートする機能には、基本機能の他、サーバ特有の機能がある[35]。
主なMQTTブローカーには以下のようなものがある。
OSS
- Mosquitto
- RabbitMQ（Pluginが必要）
- Apache_ActiveMQ
- MQTTnet - .NETによる実装。ライブラリであるが、短いコードで拡張可能な独自のブローカーを実装できる。
商用
Facebook Messenger
FacebookのメッセンジャーにMQTTを使用している。
IECC Scalable
DeltaRail Group （現：Resonate Group）のIECCシグナリング制御システムの最新バージョンではシステムとシグナリングシステムの他の構成要素との通信にMQTTを使用している。
2018年8月16日にAvast Softwareはスマートホームシステムの制御で使われるMQTTサーバの多くがパスワードで保護されていないと言うレポートを発表した。[37] レポートによると全世界で49,000台以上MQTTサーバが公開されており、そのうち32,000台以上がパスワードで保護されておらず通信内容を容易に確認できる。 レポートではMQTTの仕様および実装されたソフトウェアやライブラリにはセキュリティの問題はなくシステム構成時の問題であるとしている。
2018年12月4日にトレンドマイクロはM2M通信プロトコルの脆弱性に関するレポートを発表した。[38] その中でMQTTのトピックに不正なUTF-8文字列を設定することによるDoS攻撃と、残り文字数フィールドを利用したバッファオーバーフロー攻撃が紹介されている。[39]
2024年3月1日にトレンドマイクロはMQTTプロトコルの盗聴や改竄のリスクについてレポートを発表した。[40] レポートによるとTLSで保護しているものの認証を必要としないMQTTサーバが数万台ありそのうち9000台程度が実際に稼働している。 レポートは顧客がベンダーにセキュリティの確保を求めていない、もしくは認識していないことが原因であると分析している。
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
