MQTTの正式名称は、メッセージキューイング・テレメトリー・トランスポート（message queuing telemetry transport）です。
MQTTはパブリッシュ/サブスクライブパターンで動作し、ペイロードを含むトピックをMQTTブローカーにパブリッシュし、他のMQTTクライアントは同じトピックをサブスクライブすることができます。そのため、いずれかのクライアントが停止しても、他のクライアントに依存することはありません。
LWT（Last will testament）オプションでも、MQTTクライアントがネットワークから切断されたときに、登録しているすべてのMQTTクライアントにメッセージを発行します。
MQTTのサービス品質（QoS）には3つのレベルがあります。
QoS 0 – at most once – 確認応答なしで可能な限りの配信を保証します。
QoS 1 – at least once – メッセージを少なくとも 1 回配信する必要がありますが、複数回配信することも可能です。ネットワークの遅延や使用量を減らすために、ほとんどのアプリケーションで使用することができる最適な方法です。
QoS 2 – 一度だけ – メッセージがサブスクライバに到達し、継続的に発行するまで確認応答を受け取ることを保証します。
リテインメッセージはMQTTのもう一つの機能で、MQTTブローカーはMQTTクライアントからretainフラグが付いたメッセージを保持し、retainフラグがクリアされるまで保持し続ける。
MQTTとHTTPの比較では、MQTTがメッセージを発行/購読するためにはQoSが重要であることから、IoTアプリケーションの重要性がわかります。
[Understanding retained messages](https://www.ioctrl.com/post/mqtt-retained-messages)については、別ブログで詳しく紹介しています。
HTTPは、Hypertext Transfer Protocolの略です。
HTTPは、ウェブブラウザと通信するためにHTMLとともに使用されるユニバーサルウェブプロトコルです。より多くのRAMと電源を必要とします。
HTTPは、リクエスト/レスポンスパターンで動作するさまざまなアプリケーションに広く使用されています。P2P（peer to peer）技術、つまりクライアント／サーバーモデルで動作します。
HTTPリクエスト/レスポンスパターン
HTTPのヘッダサイズは大きく、応答時間もMQTTプロトコルと比較して長くなります。
MQTTはPUBLISH、SUBSCRIBE、CONNECT、DISCONNECT、UNSUBSCRIBEの各機能を使用しますが、HTTPには膨大なライブラリ機能があります。MQTTはTLS/SSLでデータ層を保護しますが、HTTPはHTTPSのみで保護します。 MQTTは1883/8883ポートを使用し、HTTPは80ポートを使用します。
HTTPはbase64データ構造を使用し、TCPを使用するMQTTと比較してUDPでデータを転送します。
MQTTとHTTPの比較は、IoTアプリケーションの重要性を示しています。
MQTTとHTTPの比較
IoT/IIOTデバイスは、MQTT/HTTPプロトコルを使ってクラウドと通信します。どちらのプロトコルもIoTアプリケーションには最適ですが、ユースケースによって異なります。
例えば、リソースに制約のあるデバイスをクラウドに接続し、バッテリー使用量やネットワーク帯域幅を抑えたい場合は、HTTPに比べてMQTTの方が適しています。MQTTは特にM2MやIOT/IIOTアプリケーション向けに設計されています。
Snap Storeで販売されているMqttDesk MQTT Clientをダウンロードします。
