Mqtt and WebSocket

Strictly speaking, MQTT has little to do with WebSocket. They are not at a level.

The relationship between Mqtt and TCP, WebSocket can be used at a glance:

Resources:

http://www.zhihu.com/question/21816631

Advantages of WebSocket

Previously, many websites used polling to implement push technology. Polling is at a specific time interval (for example, 1 seconds), the browser sends an HTTP request to the server, and the server returns the latest data to the browser. The disadvantage of polling is obvious, the browser needs to constantly make requests to the server, however, the header of the HTTP request is very long, and the actual transmission of data may be very small, resulting in a waste of bandwidth and server resources.

Comet uses Ajax to improve polling, enabling two-way communication. But comet still needs to make a request, and in comet, long links are widely used, which also consumes server bandwidth and resources.

As a result, the WebSocket agreement arose. The browser makes a request to the server to establish a WebSocket connection through JavaScript, and after the connection is established, the client and server Exchange data directly over the TCP connection. The WebSocket connection is essentially a TCP connection.

WebSocket has a great performance advantage in terms of the stability of data transmission and the size of data transmission volume. Websocket.org compared the performance benefits of polling and Websocket:

HTTP rotation needs to return 871 bytes at a time, WebSocket only 2 bytes each time

Use case a:1,000 client receives a message per second, network throughput (2*1,000) =2,000 bytes = 16,000 bits per second

Use case b:10,000 client receives a message per second, network throughput (2*10,000) =20,000 bytes = 160,000 bits per second

Use case c:100,000 client receives a message per second, network throughput (2*100,000) =200,000 bytes = 1,600,000 bits per second

Reference:

http://segmentfault.com/a/1190000000382788

WebSocket Architecture in Spring 4.0
http://www.oschina.net/translate/websocket-architecture-in-spring-4-0

Mqtt

The MQTT protocol is a protocol designed to communicate with a wide range of remote sensors and control devices that have limited computational power and work in low-bandwidth, unreliable networks, with the following key features:

• Very small communication overhead (with a minimum message size of 2 bytes), small transfers, small overhead (fixed-length headers are 2 bytes), protocol switching minimized, to reduce network traffic.
• supports a wide range of popular programming languages (including C,java,ruby,python, etc.) and easy-to-use clients;
• Use the Publish/Subscribe message pattern to provide a one-to-many message release, decoupling the application.
• A message transmission that is masked against the payload content.
• Provides network connectivity using TCP/IP.
• There are three kinds of message Publishing service quality, so that the message can reach the destination on demand, adapt to the network transmission demand of unstable work:
• "At most once", message publishing relies entirely on the underlying TCP/IP network. Message loss or repetition occurs. This level can be used when the environment sensor data, loss of a read record does not matter, because there will be a second time to send.
• "At least once" to ensure that the message arrives, but the message duplication may occur.
• "Only once" to make sure the message arrives once. This level can be used for situations where, in a billing system, duplicate or missing messages can result in incorrect results.
• Use the last would and Testament features to notify the client of the mechanism of an abnormal interrupt on the parties.

Mqtt and WebSocket