MQTT通信について(座学)
はじめに
前回のBluttoothに続いて、少し気になったのでまとめます。MQTTクライアントを使ってAWSでやってみよう編は次回書いてみようかなと思っています。
MQTT通信は軽量で効率的なプロトコルのため、スマートホームや産業IoTなど幅広い分野で利用されています。
まずはイメージを掴むためにですが、温度センサーのIoTデバイスがあり、スマホの専用アプリで温度が確認できる、というのが想像しやすい気がします。
MQTT通信の特徴
MQTT(Message Queuing Telemetry Transport)は以下の特徴を持っています。
- 軽量かつ低帯域
- 通信データ量が少ない
- ネットワーク負荷を抑えられる
- 双方向通信
- デバイス間でメッセージのやり取りが可能
- 疎結合
- 通信するデバイス同士が直接つながる必要がなく、柔軟なシステム構築が可能
- QoS(Quality of Service)の選択が可能
- メッセージの送信品質を用途に応じて調整できる
- 詳細はこの後記載します
仕組み(Publisher/Subscriberモデル)
MQTTはPublisher/Subscriberモデル
と呼ばれる仕組みを使います。
用語の確認
- MQTTクライアント
- MQTTを使用してメッセージを送受信するもの
- 先のイメージでいうと、温度センサーもスマホもMQTTクライアントになる
- Broker (ブローカー)
- ブローカーは受け取った情報を適切なMQTTクライアントに送る役割
- ブローカーを挟んで、送信側と受信側が疎結合な状態で通信を行う方式をパブリッシュ/サブスクライブ(Pub/Sub)という
- ブローカーはソフトウェアで、受信したメッセージを適切な受信者にルーティングをする
- パブリッシュ/サブスクライブ
- MQTTクライアントがメッセージを送信することをパブリッシュという
- 逆にMQTTクライアントがメッセージを受信することをサブスクライブという
- トピック
- メッセージを送る際、何に関するメッセージか記載された情報
- 通常は
/
で区切られている
横文字多くて意味わかりません(と私は思いました)ので、以下がイメージ図です。先の温度センサーを例にしています。
QoSについて
MQTTでは、メッセージ配信の信頼性をさまざまなネットワーク環境下で保証するQoSが定められています。
QoS0: とりあえず送るけど届くかはわかんないぜ!
かっこよく言うと At most once
最大1回のメッセージが送信されますが、到達することは保証されていません。
先の温度センサーの例では、温度は最新値が重要ですし(用途による)、1回送れなくても大きな問題にはなりにくいケースが多いと思います。
QoS0は上記のようなデータが損失しても大きな問題が起きないような場合に利用されます。
QoS1: 必ず送ります、けどしかしたら何回も送っちゃうかも...
かっこよく言うと At least once
最低1回のメッセージが到達することが保証されます。受信者はメッセージが届いたことを送信者に通知するため、メッセージが到達することが保証されます。
先の温度センサーで考えると、家にペットがいて、室温が28°以上になったら危ないのでアラートを出す
という設定をしてるケースを考えましょう。
この場合、アラート忘れちゃいました。だと困っちゃうわけで、重複してもいいから送ってくれよと思うはずです。まさにこの場合がQoS1ですね。
QoS2: 必ず1回だけ送ります!
かっこよく言うと Exactly once
文字通り重複なく1回だけ送るという完成系になります。
中身の仕組みがどうなっているかというと、
- メッセージを送る
- 受信者から返事(PUBREC)があるまで待機(QoS1だと一定時間経って返事がないと再送)
- 受信者から返事がきたら、「では完了します」と送信する(PUBREL)
- 受信者は送信者に「はい、OKです」と連絡(PUBCOMP)
このような多段チェックにより重複を防ぐようになっています。
おわりに
簡単でしたが以上です。。
reference
Discussion