0

Can someone explain to me the advantages and disadvantages when transmitting MQTT over Websocket instead of direct transmission over MQTT? . I am planning to use MQTT over websocket for my project on ESP8266. I am in a situation where I cannot use MQTT directly

Đại Ngọc Nguyễn
  • 15
  • 1
  • 7
  • It would help if you can explain why you can't use native MQTT. – hardillb Feb 28 '19 at 10:46
  • Because I'm using AWS iot core for my project. But AWS don't support for ESP82866 to connect direct mqtt – Đại Ngọc Nguyễn Feb 28 '19 at 12:10
  • Hi @ĐạiNgọcNguyễn We can use AWS IoT core on ESP32 and ESP8266. it uses direct MQTT. I have done this project where I am sending wireless Sensor data to AWS IoT core here is the [link](https://www.hackster.io/vaibhav-sharma2/aws-iot-core-with-wireless-temperature-sensor-using-mqtt-ba955b) – varul jain Mar 01 '19 at 06:09
  • Hi Varun Jain ,Why can you do that? You are using mongoose-os?? – Đại Ngọc Nguyễn Mar 01 '19 at 06:59

2 Answers2

2

The major upside to MQTT over Websockets for none browser based clients is that it allows you to make use of HTTP proxies (assuming the client also supports proxies) when you don't have a direct connection to the broker.

The other advantage is that if you have a mix of devices and web based MQTT clients that you only need to expose one port to service both sets of clients.

You do pay a price for a larger connect/setup payload with MQTT over Websockets because you have the HTTP Upgrade message that needs to be handled before the normal MQTT connection starts.

hardillb
  • 54,545
  • 11
  • 67
  • 105
  • Hardillb . Just connect and set the load? Is it still sending both messages? I'm thinking when sending messages, the content of mqtt will be in the body of websocket, right? – Đại Ngọc Nguyễn Feb 28 '19 at 11:54
  • MQTT connections should be persistent (started once and maintained for as long as possible) if you are planning on opening/closing for every message then the difference in network usage between native MQTT and MQTT over Websockets will be huge. – hardillb Feb 28 '19 at 11:59
  • Hello Hardillb . My mean is when sending MQTT messages, client will send both mqtt and websocket messages right? . Could you explain the mechanism of mqtt over websocket for me? Sorry my english is not good – Đại Ngọc Nguyễn Feb 28 '19 at 12:49
  • @ĐạiNgọcNguyễn Yes, MQTT messages are sent *inside* websocket frames. See https://www.hivemq.com/blog/mqtt-essentials-special-mqtt-over-websockets/ and http://www.steves-internet-guide.com/mqtt-websockets/. The overhead that hardlib refers to is in setting up the initial websocket connection. – Ben T Mar 01 '19 at 05:26
  • Hello Hardillb. I will research this document after 5 hours . Thanks you very much. – Đại Ngọc Nguyễn Mar 01 '19 at 07:01
0

MQTT often runs on a well known port (1883/TCP) (note: the encrypted port is often 8883/TLS) but in some locations, e.g. public Wifi and private networks run by organisations, using ports other than 80/TCP (http) or 443/TLS (https), on a connection exiting that network is barred (As is the case in my company).

This prevents the use of an MQTT Broker located in the public Internet even for secure traffic. Locating a Broker within the private network limits use cases. (IMO this is a lack of understanding of what MQTT is/does by some IT pros)

By using Websockets (ws over http) and especially Secure Websockets (wss over https) it is much less likely that IT network limitations and restrictions will be able to block connections, expanding use case possibilities.

For low bandwidth traffic the extra overhead of the effective tunnel is minimal.

Depending on the Broker, other clients can use other protocols for their messages to the same collection of clients and topics, (is there an official phrase for that??) so they don't all have to use the same transport.

A good client implementation should perhaps try direct secure TCP first and fall back to wss (over https) if that fails.

Jay M
  • 3,736
  • 1
  • 24
  • 33