What are the advantages of MQTT compared with the traditional HTTP protocol

HTTP is the most widely used and popular protocol. But MQTT has rapidly gained ground over the past few years. When discussing IoT development, developers must choose between these two.

MQTT focuses on data while HTTP focuses on documents. HTTP is a request-response protocol for client-server computing, which is not always optimized for mobile devices. In these terms, the main advantages of MQTT are: lightweight (MQTT transfers data in the form of byte arrays) and publish/subscribe model, which makes MQTT very suitable for devices with limited resources and helps to save battery. In addition, the publish/subscribe model enables clients to be independent of each other, thereby increasing the reliability of the overall system. In the event of a client failure, the entire system continues to function normally.

There are still many advantages of MQTT, as follows:

1. Low protocol overhead, MQTT is unique in that its header per message can be as short as 2 bytes. Both MQ and HTTP have a much higher per-message overhead. With HTTP, re-establishing the HTTP connection for each new request message incurs significant overhead. The persistent connections used by MQ and MQTT significantly reduce this overhead.

2. Tolerance to unstable networks, MQTT and MQ can recover from failures such as disconnection, and there is no further code requirement. However, HTTP cannot do this natively, requiring clients to retry the encoding, which can add to idempotence issues.

3. Low power consumption, MQTT is specially designed for low power consumption. HTTP was not designed to take this into account, thus increasing power consumption.

4. Clients with millions of connections, on the HTTP stack, maintaining millions of concurrent connections requires a lot of work to provide support. While this support is possible, most commercial products are optimized to handle persistent connections of this order of magnitude. IBM offers IBM MessageSight, a single rack mount server tested to handle up to 1 million concurrently connected devices over MQTT. In contrast, MQTT is not designed for a large number of concurrent clients.

5. Push notifications, you need to be able to deliver notifications to customers in a timely manner. For this, some kind of periodic polling or push must be employed; push is the best solution from a battery, system load and bandwidth perspective.

Our business may need to send sensitive information without the intermediary of a third party. This reduces the value of OS-specific solutions (such as Apple iOS, Google Play notifications) as the primary transport mechanism.

HTTP only allows one method called COMET, using persistent HTTP requests to perform pushes. This approach is expensive from both the client and server perspectives. Both MQ and MQTT support push as a fundamental feature of them.

6. Client platform differences, both HTTP and MQTT clients have been implemented on a large number of platforms. The simplicity of MQTT helps to implement MQTT on additional clients with very little effort.

7. Firewall fault tolerance, some corporate firewalls restrict outbound connections to some defined ports. These ports are usually restricted to HTTP (port 80), HTTPS (port 443), etc. HTTP can obviously work in these situations. MQTT can be wrapped in a WebSockets connection that appears as an HTTP upgrade request, allowing operation in these cases. MQTT does not allow this pattern.

Compared to HTTP, the MQTT protocol guarantees a high transfer rate. There are three levels of service quality:

A. At most once: Try to ensure delivery.

B. At least once: Make sure that the email is sent at least once, but the message can also be delivered more than once.

C. Just once: Ensure that each message is received only once by the other party.

In fact, MQTT is widely used. You can find MQTT in almost any large hardware and Internet company, such as Facebook, BP, alibaba, baidu, etc.

Due to the various technical advantages of MQTT itself, more and more companies tend to choose MQTT as the standard protocol for IoT product communication. Therefore, engineers have gradually discovered that the MQTT protocol has some functions that need to be improved if it is to be commercialized on a large scale. for example:

1. There is no complete SDK, and different heterogeneous terminals need corresponding software SDK packages to communicate with the MQTT server. For example, to achieve interconnection between MCU, Linux, Android, IOS, WEB, etc., different SDK packages must be required.

2. File and AV are not supported. In some application scenarios, the information to be transmitted may not be limited to instructions, such as audio signals and video signals, which need to communicate through File and AV.

3. It does not support the integration with third-party HTTP. Although the MQTT protocol is superior to the ordinary HTTP protocol, WEB servers based on the traditional HTTP protocol still occupy the mainstream market, so these servers must realize the interconnection with the MQTT protocol to reduce upgrades Cost is also critical.

4. It does not support load balancing. In order to prevent high concurrency and malicious attacks, a load balancing server is also essential.

5. It does not support the user management interface. It is particularly important for users to analyze device behavior data, which is an inevitable requirement of Industry 4.0 and the era of big data.

6. It does not support offline messages, and makes up for the problem that the MQTT server loses the control information of the device after the device is offline.

7. Point-to-point communication is not supported, and the standard MQTT protocol is adopted. In theory, point-to-point communication can be realized through mutual subscription, but the logic is relatively complicated, and there are concerns about the security of the device. When device B and device C are on the same topic, device A cannot know whether it is device B or device C that sent the message, and it is also possible that the message is eavesdropped by device D.

8. It does not support group communication and group management, and realizes the management of group members, and group members can communicate with each other. In the scenario where one device is controlled by multiple people, or multiple devices are controlled by one person, Especially useful.