MQTTはトラフィック量はHTTPの1/10になると聞きましたが、実際に計測してみたところそれほどの差がないように見えました。

HTTP GETで mqtt という文字列をサーバー側からクライアント側に送ることを想定してみます。

クライアント側は以下の文字列を送ります。

GET / HTTP/1.1
User-Agent: curl/7.30.0
Host: hoge.info
Accept: */*

67バイトです。

それに対してサーバー側は以下の文字列を送ります。

HTTP/1.1 200 OK
Date: Thu, 17 Jul 2014 02:49:51 GMT
Server: Apache/2.2.25
Last-Modified: Thu, 22 Nov 2012 08:48:32 GMT
ETag: "fdvvf91-4a5-4aa11881f7899"
Accept-Ranges: bytes
Content-Length: 4
Content-Type: text/html

mqtt

222バイトです。合計すると289バイトです。

一方MQTTではこうなります。

クライアント側がSUBSCRIBEを送ります。

• MQTT固定ヘッダ部: 2バイト
• SUBSCRIBEメッセージpayload部:
  • length: 2バイト
  • topic: "#" 1バイト
  • QoS: 1バイト
  
  

6バイトです。

ブローカー側がPUBLISHを送ります。

• MQTT固定ヘッダ部: 2バイト
• PUBLISHメッセージヘッダ部:
  • length: 2バイト
  • topic: "#" 1バイト
• PUBLISHメッセージpayload部:
  • payload: "mqtt" の4バイト
  
  

9バイトです。合計すると15バイトです。


実際にはtopicの長さはもう少し長いと思いますし、ここではあえて
CONNECT/DISCONNECT処理を省いています。そのため、さすがに10分の1とはな
りませんが、かなり削減されるのは分かると思います。


さて、この差はどこから来ているかというと、ヘッダ部分の有無です。
payload自体には変わりはありません。


従って、payloadが4バイトなどではなく、もっともっと大きい場合、ヘッダ部
は相対的に小さくなりますので、MQTTとHTTPとの差は少なくなります。

検証されている内容にもよりますが、payloadが大きいのではないでしょうか。
その場合は圧縮などをしない限りプロトコルの差は出ません。

もともとMQTTはセンサーデータなど、小さいデータを数多くのデバイスから送
ることを想定しています。従って、payloadが大きいデータを送る、というこ
とは想定していないと思います。(MQTTで送ることは可能ですが、利点が少なくなる)



ちなみに、MQTTはTCPコネクションを維持しますので、TCP接続の3-way
handshakeにかかる時間がなくなります。これにより、データ転送までの時間が
短くなります。これも「軽量」と言われる所以です。