First introduction to MQTT
The Internet of Things, as the name suggests, is the Internet where things are connected. It can link objects through the Internet, and these objects can collaborate with each other. MQTT is a TCP/IP-based protocol for data communication between these objects.
Each terminal is connected to a proxy/server that implements the MQTT protocol.
Send data through a topic on a published MQTT proxy server.
Get the topic data you subscribe to from the MQTT proxy server through subscription.
The proxy server itself does not generate data; all data is generated by the terminal connected to the proxy server.
The terminal sends data to the server. The terminal that subscribes to the topic on the server accepts data sent from another terminal to the server and forwards it to itself through the server.
Why choose MQTT protocol?
The MQTT protocol is a lightweight and flexible network protocol. And it is very suitable for IOT scenarios.
First of all, the definition of the IOT protocol is very small and not as heavyweight as HTTP and HTTPS.
Generally, the network transmission environment and computing power of devices that support IOT are relatively weak, so they are suitable for MQTT, a lightweight protocol that does not have high requirements for network and data.
So, why is MQTT so lightweight and flexible? A key feature of the MQTT protocol is the publish/subscribe model. It separates the publisher and receiver of data.
A device terminal can be either a publisher of data or a subscriber of data.
If a device wants to publish data, it only needs to publish the data content to the corresponding topic in the proxy server.
If a device needs to receive data, it only needs to subscribe to the topics it needs to pay attention to in advance in the proxy server.
Why not choose another network protocol?
Most developers are already familiar with the HTTP WEB protocol. So why not let the IOT setup link to the WEB service?
The device can send data in the form of HTTP requests and obtain data from the server in the form of HTTP responses to accept updates.
Because for IOT devices, this data transmission model of active request->passive waiting for response has serious limitations:
HTTP is a synchronous protocol. The client needs to wait for the server’s response. Web browsers have such a requirement, but it comes at the expense of scalability. In the IoT world, the large number of devices and potentially unreliable or high-latency networks make synchronous communication a problem. Asynchronous messaging protocols are more suitable for IoT applications. The sensor simply sends the data and lets the network determine the best route and time to deliver it to the target device and server.
HTTP is one-way. The client must actively initiate the request. In IoT applications, the device or sensor is typically a client, which means it cannot accept data from the server unless the user or application actively requests it.
HTTP is a 1-1 protocol. The client makes a request and the server responds. They have a one-to-one correspondence. However, it is necessary to improve the 1-1 relationship of HTTP to the one-to-many relationship that is very common in IOT. It is difficult to implement and the cost is also high. And one-to-many is very common in IoT.
Compared with MQTT, HTTP is a relatively heavy protocol. It is not suitable for the limited network and poor computing power of IOT terminal devices.