IoT Application Layer Protocols: MQTT, CoAP, HTTP, XMPP, SoAP

01

—

MQTT (Message Queuing Telemetry Transport) was originally developed by IBM as an instant messaging protocol. The MQTT protocol is designed for communication between remote sensors and control devices that have limited computing power and operate in low-bandwidth, unreliable networks.

The advantage of MQTT is that it supports all platforms and can connect almost all networked terminals to the Internet.

MQTT has the following main features:

1. Uses a publish/subscribe messaging pattern, providing one-to-many message publishing and decoupling between applications;

2. Message transmission does not require knowledge of the payload content;

3. Uses TCP/IP for network connection;

4. Offers three levels of message delivery quality:

1. QoS 0: “At most once”; message delivery relies entirely on the underlying TCP/IP network. Distributed messages may be lost or duplicated. For example, this level can be used for environmental sensor data, where a single data loss is acceptable as there will be a second transmission soon.

2. QoS 1: “At least once”, ensuring that messages can be delivered, but they may be duplicated.

3. QoS 2: “Exactly once”, ensuring that messages are delivered only once.

5. Small transmission size with minimal overhead (fixed-length header of 2 bytes), minimizing protocol exchanges to reduce network traffic;

6. Utilizes Last Will and Testament features to notify relevant parties of client abnormal disconnections;

The following diagram illustrates the three levels of message delivery quality in MQTT, allowing MQTT clients to communicate in one-to-one, one-to-many, and many-to-one modes.

CoAP Protocol

CoAP (Constrained Application Protocol) is designed for resource-constrained devices in IoT, which have limited memory and computing power. Traditional HTTP protocols are too bulky for IoT applications. Therefore, the IETF’s CoRE working group proposed a REST-based protocol that uses UDP at the transport layer and 6LowPAN (IPv6 for low-power wireless personal area networks) at the network layer.

CoAP adopts the same request-response working mode as the HTTP protocol.CoAP has four types of different message types.

1. CON – Confirmable request, requiring acknowledgment; if a CON request is sent, the recipient must respond.

2. NON – Non-confirmable request, does not require acknowledgment; if a NON request is sent, the recipient does not need to respond.

3. ACK – Acknowledgment message, responding to a received CON message.

4. RST – Reset message, sent when the recipient receives a message that contains an error or is no longer interested in the sender’s content.

CoAP message format uses a simple binary format, with a minimum of 4 bytes. A message = fixed-length header + optional number of options + payload. The length of the payload is calculated based on the datagram length. CoAP is primarily a one-to-one protocol.

Differences Between CoAP and MQTT

MQTT and CoAP are both effective IoT protocols, but they have significant differences. For example, MQTT is based on TCP, while CoAP is based on UDP. The main differences in application direction are as follows:

1. MQTT does not support type or other label information to help clients understand; all MQTT clients must know the message format. In contrast, CoAP has built-in discovery support and content negotiation, allowing devices to discover data exchange methods.

2. MQTT is a long connection, while CoAP is connectionless. MQTT clients maintain a TCP long connection with the broker, which does not cause problems in NAT environments. If CoAP is used in a NAT environment, some NAT traversal techniques are needed.

3. MQTT is a many-to-many protocol where multiple clients communicate through a central broker. It decouples consumers and producers by allowing clients to publish messages, and the broker decides message routing and replication. MQTT acts as a real-time communication bus for message passing. CoAP is essentially a one-to-one protocol for passing state information between the server and client.

HTTP Protocol

The full name of HTTP is HyperText Transfer Protocol, which is designed to provide and receive HTML interfaces, transmitting web interface information over the Internet. HTTP consists of two processes: Request and Response, each with its own language format.

Request message format: <method> <request-URL> <version><headers>
<entity-body>
Response message format: <version> <status> <reason-phrase><headers>
<entity-body>

• Method

This is important, for example, the commonly used GET and POST methods. GET retrieves content, while POST sends data to the server. There are also others, such as DELETE, PUT, CONNECT, HEAD, OPTIONS, TRACE, totaling 8 methods (HTTP Method history: HTTP 0.9 had only the GET method; HTTP 1.0 had GET, POST, HEAD).

• Request URL

The URL here does not include the IP address or domain name; it corresponds to the directory address of the local file on the host, so we usually see “/”.

• Version

The format is HTTP/<major>.<minor>, for example, HTTP/1.1. This version represents the version of the HTTP protocol we are using, which is generally HTTP/1.1.

• Status Code

The status code consists of three digits, representing the situation that occurred during the request process; for example, 200 means success, while 404 means the file was not found.

• Reason Phrase

This is the readable version of the status code. The status code is a number, and if you don’t know what it means, you can check the reason phrase.

• Header

Here, the header is not called a head, but a header. There can be zero or multiple headers, each containing a name followed by a colon, then an optional space, followed by a value, and then a newline.

• Entity Body

The entity body contains a block of data made up of arbitrary data, and not all messages include an entity body; sometimes, it just ends with an empty line and a newline.

Let’s quickly understand through an example:

Request message: GET /index.html HTTP/1.1    Accept: text/*Host: www.xxxyyy.com
Response message: HTTP/1.1 200 OKContent-type: text/plainContent-length: 32

Differences Between HTTP and CoAP

CoAP is the application layer protocol in the 6LowPAN protocol stack, based on REST (Representational State Transfer) architectural style, supporting interaction with REST. Users can access IoT devices using CoAP as they would with HTTP. Additionally, CoAP message format uses a simple binary format with a minimum of 4 bytes. HTTP’s message format requires too much data transfer for embedded devices, making it less flexible.

XMPP Protocol

XMPP (Extensible Messaging and Presence Protocol) is a protocol based on XML (Extensible Markup Language) that inherits flexibility in XML environments. It can be used for service-based real-time communication, representation, and demand-response services in XML data streams. XMPP is based on the Jabber protocol, which is a commonly used open protocol in instant messaging.

In XMPP, three roles are defined: client, server, and gateway. Communication can occur bidirectionally between any two of these three. The server also handles client information storage, connection management, and message routing.The gateway facilitates intercommunication with heterogeneous instant messaging systems, which may include SMS, MSN, ICQ, etc.The basic network form is a single client connecting to a single server via TCP/IP, then transmitting XML.

The XML (a subset of Standard Generalized Markup Language) stream is as follows:

Client: <?xml version='1.0'?><stream:stream to='example_com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
Server: <?xml version='1.0'?><stream:stream from='example_com' id='someid' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>

SoAP Protocol

SoAP (Simple Object Access Protocol) is a protocol specification for exchanging data, designed to be lightweight, simple, and based on XML. It is intended for exchanging structured and serialized information on the web.

SoAP can be combined with many existing Internet protocols and formats, including HTTP, Simple Mail Transfer Protocol (SMTP), and Multipurpose Internet Mail Extensions (MIME).

SoAP also supports a wide range of applications, from messaging systems to Remote Procedure Calls (RPC). SOAP uses a combination of XML data structures and HTTP to define a standard method for using distributed objects across various different operating environments on the Internet.

Overall, SoAP is more suitable for enterprise-level applications, while IoT scenarios, similar to XMPP, may transmit excessive redundant data.

Conclusion

From the current trends in IoT application development, the MQTT protocol has certain advantages. Major cloud service providers both domestically and internationally, such as Alibaba Cloud, AWS, Baidu Cloud, Azure, and Tencent Cloud, all support the MQTT protocol. Another reason is that the MQTT protocol matured earlier than CoAP, giving it a first-mover advantage. However, with the intelligent and diverse development of IoT, future IoT application platforms will certainly be compatible with more IoT application layer protocols.

There are similar discussions on Quora (the American version of Zhihu):

Which is the best protocol to use for IoT implementation – MQTT, CoAP, XMPP, SOAP, UPnP?