AWS ACM PCA for AWS IoT and SSL Pinning

MQTT, HTTP, or WebSockets for IoT Communication


MQTT (MQ Telemetry Transport) Protocol

It is a publish/subscribe, extremely simple and lightweight messaging protocol.

Why do we use MQTT?

MQTT is designed for constrained devices that use low-bandwidth, high-latency networks. 

Let's look at one of the case studies from AWS IoT. Taiwan-based Weintek designs and manufactures human-machine interface (HMI) products. Before using AWS, HMIs were not connected to networks and they had to transfer and upload data manually to the network.

Later, they decide to implement AWS infrastructure and use IoT Technology. Since MQTT is lightweight, it enabled them to collect data from thousands of machines using relatively little bandwidth

MQTT pub/sub pattern

pub_sub_pattern
Pub/sub pattern

MQTT uses the pub/sub pattern to connect relevant parties. This protocol enables an application to announce events to multiple interested consumers asynchronously, without coupling the senders to the receivers.

In this pattern, the publisher sends messages via the input channel and subscribers will consume these messages. A message broker or event bus will be responsible for copying the messages from the input channels to the one or more output channels.

Benefits of pub/sub pattern

  • decouples subsystems that still need to communicate.
  • It increases scalability and improves the responsiveness of the sender
  • Asynchronous messaging helps applications continue to run smoothly under increased loads
  • It allows for deferred or scheduled processing. 
  • Enables simpler integration between systems.
  • It improves testability.
  • It provides separation of concerns for your applications. 

HTTP for IoT

AWS and Google cloud both support HTTP for IoT communication. We should select the protocol based on our use case. 

According to AWS, they provide MQTT or WebSockets to maintain long-lived, bidirectional connections that enable devices to send and receive messages at any time with low latency.

Google cloud website has a great article that compares these two protocols. According to their experiment, The real advantage of MQTT over HTTP occurs when we reuse the single connection for sending multiple messages. If connections are set up and torn down frequently just to send individual messages, the efficiency gains are not significant compared to HTTP.


mqtt_v_http
MQTT vs HTTP
https://cloud.google.com/blog/products/iot-devices/http-vs-mqtt-a-tale-of-two-iot-protocols


Using HTTP for point to point communication and using MQTT for pub/sub to establish the IoT communication would be the optimal solution.

WebSocket

WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection. Both HTTP and WebSocket are located at layer 7 in the OSI model and depend on TCP at layer 4. WebSocket handshake is interpreted by HTTP servers as an Upgrade request.

The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections.

Example: socket.io provides a bi-directional communication channel between a client and a server. One of the most popular implementations of this is chat applications.

MQTT over WebSocket

MQTT implementations build on top of TCP works in many scenarios with one big exception, they do not support browsers. Browsers use HTTP and to use MQTT with browsers like clients we can use MQTT over WebSockets.

According to RFC6455, If MQTT is transported over a WebSocket, the following conditions apply:
  • MQTT Control Packets MUST be sent in WebSocket binary data frames. If any other type of data frame is received the recipient MUST close the Network Connection.
  • A single WebSocket data frame can contain multiple or partial MQTT Control Packets. The receiver MUST NOT assume that MQTT Control Packets are aligned on WebSocket frame boundaries.
  • The Client MUST include “mqtt” in the list of WebSocket Sub Protocols it offers.
  • The WebSocket Subprotocol name selected and returned by the Server MUST be “mqtt”.
  • The WebSocket URI used to connect the Client and Server has no impact on the MQTT protocol.

Conclusion

MQTT over WebSocket would be the better solution if we are showing real-time data without interaction with the consumers. For individual message sending, we should use HTTP. AWS IoT supports  MQTT, WebSockets, and HTTP 1.1 protocols.


References:




Comments