IoTにおいて注目を集めているプロトコルがMQTTです。相互に送受信が可能で、ごく短いメッセージを送るのに適したプロトコルになっています。

相互に送受信というとWebSocketが思い当たるのですが、様々な点が異なります。そこで今回はMQTTとWebScoketの相互点について紹介します。

似ているところ

どちらも相互通信が可能

WebSocket、MQTTともに相互通信が可能という点が特徴です。これまでのWebの世界ではクライアントがリクエストを投げてくるまではデータを遅れませんでした。その回避策としてCometやロングポーリングのような技術ができたのですが、最適解とは言いがたかったかと思います。そこでWebSocketが生まれた経緯があります。

相互通信ができるということはデータを相互にやりとりできると言うことです。この形はPub/Sub型と言われます。サーバからメッセージを投げたり、逆にクライアントから受け取ったりという点もあってチャットなどがよく例としてあがっています。

トピックベースの送受信

どちらも送信側(Publisher)、購読側(Subscriber)ともにトピックを指定します。そしてそのトピックにあったメッセージだけを送受信できるようになっています。

TLS/SSLがある

WebSocketのプロトコルはws://ですが、SSL/TLSにするとwss://になります。同様にMQTTもmqtt://が基本で、セキュアにする場合はmqtts://になります。ただしごく小さなIoTデバイスの場合、暗号化処理できるスペックがない場合もありますので注意が必要です。

違うところ

発想

元々WebSocketはHTML5の仕様の一つでした(現在は違います)。そのためWebブラウザとサーバ間で通信するのが基本となります。チャットなどはクライアント間の接続をサーバが中心に立って行っているイメージです。

対してMQTTはブローカーと呼ばれるサービスを間に立てます。そしてパブリッシャー(発行側)とサブスクライバー(購読型)が任意にブローカーに接続して通信を行います。パブリッシャー兼サブスクライバーにもなれます。ブローカー自身はデータを変更したり、検証することなくサブスクライバーにデータを流すのみです。

品質保証

WebSocketはTCPのレベルでのデータ配信が保証されます。実際に届いたかどうかは分かりませんので、アプリケーション側で受け取った時にメッセージを返すような工夫が必要です。MQTTの場合はQoS0〜QoS2までのレベルがあり、最高1回、最低1回、必ず1回の品質が指定できます。ただしクライアントが常時切断されていたり、ブローカーが落ちている場合などはこの限りではありません。

ヘッダ量の違い

MQTTの特徴としてヘッダーサイズが最小2byteと小さい点が良く挙げられます。ただしいくらヘッダーサイズが小さくしても実際のメッセージ部が長いと意味がありません。メッセージは最大256MBまでで、そうなるとHTTPのヘッダーと比べても差はごくわずかになってしまうでしょう。

そのため、MQTTを使う場合にはメッセージがごく短い場合に限定すべきです。


WebScoketとMQTTは似たような技術ではありますが、向き不向きがあると思われます。サーバと連携してメッセージを送りたい時にはWebSocketが向いていると思われ、スマートフォンアプリやIoTなどWeb以外の技術も関わる場合にはMQTTを使っていくべきかも知れません。

なおニフティクラウドのMQTTサービスはWebSocketにも対応しており、TLS/SSLもサポートしています。ぜひご利用ください!