Author: HFK_Frank
Original link:
https://blog.csdn.net/acongge2010/article/details/79142380
MQTT Protocol
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 with limited computing power operating in low bandwidth and unreliable networks.
The advantage of the MQTT protocol is that it supports all platforms, effectively connecting all Internet-enabled devices.
It 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 connectivity;
4. There are three levels of message delivery quality:
-
QoS 0: “At most once”, message delivery depends entirely on the underlying TCP/IP network. Delivered messages may be lost or duplicated. For example, this level can be used for environmental sensor data, where a single data loss is acceptable because a second transmission will occur shortly after.
-
QoS 1: “At least once”, ensures messages can be delivered, but messages may be duplicated.
-
QoS 2: “Exactly once”, ensures messages are delivered exactly once. For example, this level can be used in a billing system where duplication or loss of messages could lead to incorrect charges.
5. Small transmission size, with minimal overhead (fixed-length header is 2 bytes), minimizing protocol exchanges to reduce network traffic;
6. Uses the Last Will and Testament feature to notify relevant parties of client abnormal disconnections;
In the MQTT protocol, an MQTT packet consists of three parts: fixed header, variable header, and payload. The transmission format of MQTT is very compact, with the smallest packet being only 2 bits and no application message header.
The following image shows the three message delivery qualities for reliable message transmission in MQTT
The publish/subscribe model allows MQTT clients to communicate in one-to-one, one-to-many, and many-to-one ways.
The following image illustrates the publish/subscribe messaging pattern of MQTT
CoAP Protocol
CoAP stands for Constrained Application Protocol. As many devices in the Internet of Things are resource-constrained, with limited memory and computing power, the traditional HTTP protocol can be too bulky and unsuitable for IoT applications. Therefore, the IETF CoRE working group proposed the CoAP protocol, which is based on a REST architecture, using UDP as the transport layer and 6LowPAN (IPv6 over Low-Power Wireless Personal Area Networks) as the network layer.
CoAP adopts the same request-response working model as HTTP. There are four different message types in CoAP.
CON—— A request that requires confirmation; if a CON request is sent, the other party must respond.NON—— A request that does not require confirmation; if a NON request is sent, the other party does not need to respond.ACK—— A response message acknowledging receipt of a CON message.RST—— A reset message; if the receiver receives a message that contains an error, or if the receiver no longer cares about the content sent by the sender, a reset message will be sent.
The CoAP message format uses a simple binary format, with a minimum of 4 bytes.
A message consists of a fixed-length header + an optional number of options + payload. The length of the payload is calculated based on the length of the datagram.
Primarily a one-to-one protocol
For example:
For instance, if a device needs to query the current temperature information from the server.
-
a. Request message (CON): GET /temperature, the request content will be encapsulated in the CON message
-
b. Response message (ACK): 2.05 Content “22.5 C”, the response content will be placed in the ACK message
Differences Between CoAP and MQTT
MQTT and CoAP are both effective IoT protocols, but there are significant differences between them. For example, the MQTT protocol is based on TCP, while the CoAP protocol is based on UDP. Analyzing from the application perspective, the main differences are as follows:
1. The MQTT protocol does not support types or other tags to help Clients understand the message, meaning all MQTT Clients must know the message format. In contrast, the CoAP protocol has built-in discovery support and content negotiation, allowing devices to discover ways to exchange data.
2. MQTT is a long connection while CoAP is connectionless. MQTT Clients maintain a TCP long connection with the Broker, which does not cause issues in NAT environments. If CoAP is used in a NAT environment, some NAT traversal measures must be taken.
3. MQTT is a many-to-many protocol for message passing among multiple clients through a central broker. It decouples consumers and producers by allowing clients to publish messages, with the broker determining message routing and replication. MQTT serves as a real-time communication bus for message transmission. CoAP, on the other hand, is primarily a one-to-one protocol for passing state information between Server and Client.
HTTP Protocol
HTTP stands for HyperText Transfer Protocol. The purpose of this protocol is to provide and receive HTML interfaces, transmitting web interface information over the Internet.
There are two processes in the HTTP protocol, Request and Response, each with its own language format. Let’s take a look at what they are.
Request message format: (Note there is a line break here)
<method> <request-URL> <version>
<headers>
<entity-body>
Response message format: (Note there is a line break here)
<version> <status> <reason-phrase>
<headers>
<entity-body>
Method:
This is very important, for example, GET and POST methods are commonly used. GET is used to retrieve content, while POST is used to send data to the server. There are also others; for example, HTTP 1.1 includes DELETE, PUT, CONNECT, HEAD, OPTIONS, and TRACE, totaling 8 methods (HTTP Method History: HTTP 0.9 had only the GET method; HTTP 1.0 had GET, POST, and HEAD methods).
Request URL:
The URL specified does not include IP addresses or domain names; it corresponds to the directory address of the local file on the host, so we generally see “/”.
Version:
The format is HTTP/<major>.<minor>, such as HTTP/1.1. This version represents the HTTP protocol version we are using, with HTTP/1.1 being the most common currently.
Status Code:
The status code consists of three digits, indicating the situation that occurred during the request process; for example, 200 means success, and 404 means the file was not found.
Reason Phrase:
This is the human-readable version of the status code; since the status code is a number, if you do not know what it means, you can refer to the reason phrase.
Header:
Note that here we refer to headers as headers, not heads. 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 line break.
Entity Body:
The entity body contains a block of arbitrary data; not all messages contain an entity body, and sometimes it ends with just a blank line and a line break.
Here is a simple example:
Request message:
GET /index.html HTTP/1.1
Accept: text/*
Host: www.myweb.com
Response message:
HTTP/1.1 200 OK
Content-type: text/plain
Content-length: 3
Differences Between HTTP and CoAP
CoAP is the application layer protocol in the 6LowPAN protocol stack, based on the REST (Representational State Transfer) architectural style, supporting interaction with REST. Users can access IoT devices using the CoAP protocol in a manner similar to the HTTP protocol. Additionally, the CoAP message format uses a simple binary format, with a minimum of 4 bytes, while HTTP uses message formats that require too much data transmission for embedded devices, making it too heavy and inflexible.
XMPP Protocol
XMPP (Extensible Messaging and Presence Protocol) is a protocol based on Extensible Markup Language (XML),
It inherits the flexibility of development in an XML environment and can be used for service-oriented real-time communication, representation, and demand-response services involving XML data streams. XMPP is based on the Jabber protocol, which is a commonly used open protocol in instant messaging.
Basic Network Structure
XMPP defines three roles: Client, Server, and Gateway. Communication can occur bidirectionally between any two of these three.
The server also handles client information logging, connection management, and message routing. The gateway facilitates interconnectivity with heterogeneous instant messaging systems, which can include SMS, MSN, ICQ, etc. The basic network form is a single client connecting to a single server via TCP/IP, then transmitting XML on top.
Functionality
It transmits commands related to instant messaging. Previously, these commands were either sent in binary form (e.g., QQ) or as plain text commands with spaces and parameters (e.g., MSN). The logic of the instant messaging commands transmitted by XMPP is similar to previous protocols, but the format has changed to pure text in XML.
Let’s look at what the so-called XML (a subset of Standard Generalized Markup Language) stream looks like:
Client:
| 123456 | <?xml version='1.0'?><stream:streamto='example_com'xmlns='jabber:client'xmlns:stream='http://etherx.jabber.org/streams'version='1.0'> |
Server:
| 1234567 | <?xml version='1.0'?><stream:streamfrom='example_com'id='someid'xmlns='jabber:client'xmlns:stream='http://etherx.jabber.org/streams'version='1.0'> |
How It Works
The basic mode of communication for the XMPP core protocol is to first establish a stream, then negotiate various security aspects,
During the communication process, the client sends XML Stanzas one after the other. The server sends XML Stanzas back to the client based on the information sent by the client
and the program logic. However, this process is not a question-and-answer format; at any time, either party can send messages to the other. The final phase of communication is closing the stream and terminating the TCP/IP connection.
During network communication, the data redundancy rate is very high, with 70% of network traffic consumed at the XMPP protocol layer. For the Internet of Things, where many remote sensors and control devices operate with limited computing power in low bandwidth and unreliable networks, conserving power and bandwidth is a key technical indicator for all underlying services, making the XMPP protocol appear outdated.
SoAP Protocol
SoAP (Simple Object Access Protocol) is a protocol specification for exchanging data, designed to be lightweight and simple,
based on Extensible Markup Language (XML). It is designed for exchanging structured and serialized information over the web.
SOAP can be combined with many existing Internet protocols and formats, including Hypertext Transfer Protocol (HTTP),
Simple Mail Transfer Protocol (SMTP), and Multipurpose Internet Mail Extensions (MIME). It also supports a wide range of applications from messaging systems to remote procedure calls (RPC).
SOAP’s use of XML-based data structures and its combination with HTTP define a standard method for using distributed objects across various operational environments on the Internet.
Summary:
From the current trends in IoT application development, the MQTT protocol has certain advantages. This is because major cloud service providers, 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, as IoT becomes more intelligent and diverse, future IoT application platforms will undoubtedly be compatible with more IoT application layer protocols.
Recent Activities of RT-Thread
1. Wuhan Station RT-Thread Salon date changed to September 15! In addition to micropython, sqlite, etc. themed experience sharing and hands-on experiment sessions, there will also be a lottery for STM32 development boards!
To register, please long press the QR code below.
2. RT-Thread 4.0 Beijing Launch Event Registration: At this launch event, we will introduce the new features and capabilities of RT-Thread 4.0 in detail.
To register for the launch event, please long press to identify the QR code below.
You can add WeChat 13924608367 as a friend, indicating: company + name, to join the RT-Thread official WeChat group.
RT-Thread
Makes the development of IoT terminals simple and fast, maximizing the value of chips. GPLv2+ license, can be used for free in commercial products.
Long press the QR code to follow us.
👇 Click to register for the launch event