We explore the most common application communication protocols and compare their functionality and suitability for constrained devices.

According to the IoT Developer-Survey, the most popular IoT-protocols are:

• HTTP/1.1
• MQTT
• Websockets
• HTTP/2
• CoAP

We will have a look on these protocols and compare their strengths and weaknesses.

HTTP

The Hypertext Transfer Protocol (HTTP) is one of the most widespread protocols. It is used as the main protocol for the World Wide Web (WWW) in web browsers, but nowadays also as a machine-to-machine protocol for communication between web services. The version in common use is 1.1 which was first defined in RFC 2068 [7].

It employs a request-response model - a request consist of a so-called header and a body. In the header there are administrative informations while the body consists of the main payload. It is a text-based protocol, which means that the entries in the header are sent as ASCII-based strings and the data representation format used for the body is mostly text-based (e.g. JSON or XML) - but in the body, a binary representation can be used.

HTTP assumes an underlying reliable transport layer protocol and TCP is commonly used. This fact and the text-based header make HTTP not an optimal protocol for constrained devices. For security functions, TLS is mainly used - HTTP over TLS is also commonly called HTTPS.

HTTP/2

The successor of HTTP/1.1 was standardized in 2015 (RFC 7540) and offers improvements to its predecessor. It introduced binary headers and a new header compression format. Further, it introduced "multiplexing" - multiple requests can be executed in parallel over the same TCP-connection. This further reduces the overhead of making multiple requests and prevents establishing multiple TCP-connections

CoAP

The Constrained Application Protocol (CoAP) was specifically designed for constrained devices. Its design principles are based on the design of HTTP (URIs, media types, status codes, headers, caching, etc.), but it uses a binary format and is based on UDP on the transport layer. The whole stack is completed with the binary data representation format CBOR and the security protocol DTLS (based on TLS but for UDP). It was also designed to be easily "mapped" back to HTTP, meaning that is possible to communicate with HTTP servers or client via proxies that map the requests between CoAP and HTTP.

While HTTP is mainly a point-to-point protocol, CoAP offers additional features. For example:

• multicast - as it runs over UDP, it enables CoAP multicast requests.
• asynchronous message exchange
• observe - a server can send multiple responses to the client

MQTT

Message Queuing Telemetry Transport (MQTT) is a very popular IoT-protocol. It implements a publish-subscribe pattern - clients communicate over a message broker, which forwards the messages. A disadvantage in comparison to CoAP is that it is based on TCP - a variation of the protocol, called MQTT-SN, also works on non TCP/IP-Stacks (e.g. UDP, or even low-level protocols like Bluetooth). It does not include a content-type field like web-based protocols (HTTP or CoAP) therefore the interpretation of the data must already be defined in the applications. One major feature is Quality of Service - a connection to the broker can specify one of three service-levels for delivery-guarantees:

• At most once: a message is sent to the broker once, no further delivery acknowledgment.
• As least once: a message is re-tried until an acknowledgment is received.
• Exactly once: a two-way handshake is executed to ensure exact-once delivery.

Websockets

WebSocket is a protocol which provides full-duplex communcation over TCP. It was designed to enable more interactive applications in web browsers, where the browser and the web-server can send data bi-directionally. With HTTP the client would use techniques like polling (making regular requests) or long-polling (the server blocks the request until a response is available). Websockets give the server the ability to push messages to the client without having the client to make a request first.

Websockets establish a connection via an initial HTTP handshake and then keep a persistend TCP connection to the server. Given the fact that it includes HTTP, TCP and persistent connections, it is not a good fit for very resource-constrained devices, but the interactive nature of the protocol can be a good fit for devices with enough computing resources.

Conclusion

CoAP and MQTT are protocols specifically designed for constrained devices. CoAP has the advantage that it is based on UDP and shares semantics with HTTP. MQTT offers publish-subscribe-semantics and quality-of-service, which is comfortable and enables more use-cases.

HTTP is so ubiquitous that it would be pleasant if its rich ecosystem of clients, servers, libraries, and proxies could be reused for the IoT. HTTP/1.1 is too resource-heavy for weak devices, but HTTP/2 could see more adoption in the future.