A publish/subscribe messaging model that facilitates one-to-many distribution.  The sending applications or devices do not need to know anything about the receiver, not even its address.

 

Ideal for constrained networks (low bandwidth, high latency, data limits, fragile connections).  MQTT message headers are kept as small as possible; the fixed header is just 2 bytes.  Its on demand, push-style message distribution keeps network utilization low.

 

Multiple service levels allows flexibility in handling different types of messages. Developers can designate that messages will be delivered “at most once”, “at least once”, or “exactly once”.

 

Designed specifically for remote devices with little memory or processing power.  Minimal headers, a small client footprint and limited reliance on libraries make MQTT ideal for constrained devices.

 

Easy to use and implement with a simple set of command messages. Many applications of MQTT can be accomplished using just CONNECT, PUBLISH, SUBSCRIBE and DISCONNECT.

 

Built-in support for loss of contact between client and server.  The server is informed when a client connection breaks abnormally, allowing the message to be re-sent or preserved for later delivery. 

 

MQTT uses a single TCP/IP port connection from client to server. This allows easier firewall and security implementation.

--Both HTTP and MQTT are based on TCP/IP
 

--HTTP uses Request/Response (1 to 1)
 

--MQTT uses Publish/Subscribe pattern
   (1-to-1 or 1-to-many)

 

--HTTP is document centric, MQTT is data centric
 

--HTTP is more complex than MQTT which is simple
 

--MQTT message size is smaller, with only a 2 byte header
 

--MQTT offers 3 Quality of Service settings, with HTTP all messages get same level of service.

MQTT Features

MQTT Compared to HTTP

MQTT Reduces Bandwidth Consumption 
Using a publish/subscribe middleware topology, data latency is reduced while gaining greater reliability and quality of data.