On today's Internet, HTTP is the most relevant application layer protocol - as it is the foundation of the World-Wide Web, and therefore the basis of most of the Internet's economic
For the Internet of Things, there is an ongoing discussion about the possible need for other application-layer protocols. Typically, proposals for such protocols are all based on either UDP/IP or TCP/IP, the core network and transport layer protocols of the Internet. But let us first take a look at HTTP.
HTTP/1.1 is the protocol that allows browsers to request Web pages from a Web server, usually represented as HTML documents. This is the Web as we all know from direct experience.
However, the design of HTTP is in no way tied to HTML documents, nor to presentation purposes in general, nor to clients that interact with humans. In fact, HTTP is also the standard protocol for the "programmable Web": Web services that typically operate with non-visual data represented in XML-based, JSON-based, or other formats. This decoupling from specific UI-oriented formats makes HTTP applicable to many IoT applications as well (or Web of Things applications, if you will).
HTTP supports the REST architecture principles. This means that
- GET e.g. for reading the current temperature
- PUT e.g. for updating the device´s configuration parameters
- POST e.g. for adding a subscriber to a subscription resource
- DELETE e.g. for removing such a subscription again
Most modern cloud services expose REST APIs based on HTTP - either to other cloud services or to apps running on "smart screens" like PCs or smartphones (the green edge in our IoT Triangle).
Facebook, Twitter etc. have shown that the REST architecture and HTTP can scale to hundreds of millions of users for a service. Moreover, HTTP has proven suitable for an incredibly broad spectrum of applications. Therefore it is only natural to reuse the existing Web know-how and infrastructure also for IoT applications, as long as there is no strong reason for using some other protocol.
Whether HTTP can further scale to IoT applications with potentially billions of devices, or whether other protocols will be needed, is hotly debated today. Usually, the arguments boil down to
performance and scalability for an expected future with many billions of Internet-connected devices.
Other considerations are the buffering of data when the receiving end-points are offline (e.g. a device that is sleeping most of the time to conserve power), security, support for complex information models, etc. Different industries may favor different protocols (e.g., OPC UA in industrial automation), and even vendor-specific protocols may have a market impact (Apple's HAP, i.e. HomeKit Accessory Protocol is a candidate, for home automation applications in the Apple ecosystem).
So inevitably, other protocols have been positioned to compete with HTTP (I am not talking about edge network protocols here, just about protocols for the link between edge networks and cloud services - the red link in the IoT Triangle). These are e.g. MQTT, AMQP, XMPP, OPC UA, MTConnect or DDS.
In most applications where HTTP is ruled out for IoT today, this is because of performance considerations. Some aspects of HTTP can indeed be drawbacks in terms of performance. Frequent opening and closing of TCP connections is expensive, especially if transport layer security is used. Keeping open multiple TCP connections is expensive. Waiting for a response after each request before sending the next request often unnecessarily penalizes performance. The textual encoding of HTTP headers incurs unnecessary overhead for parsing. While the current version 1.1 of HTTP allows keeping open a connection and reusing it for multiple request/response round-trips, the other issues remain.
As the REST architecture principles are attractive for any kind of distributed system, not just global large-scale systems like the Internet, it is no surprise that a light-weight alternative to HTTP for embedded systems and sensor networks has been proposed. It is called CoAP. It can be regarded as a more efficient encoding of a subset of HTTP, with a few added features, such as the OBSERVE verb that allows to subscribe to notifications from a resource. As it has been designed explicitly with conversions to and from HTTP in mind, it is possible to develop generic gateways.
While CoAP was developed with embedded systems as targets, the mentioned overhead of HTTP has also been motivating another group to look at alternatives: large cloud companies such as Google,
Twitter and Facebook. It is in their best economic interest to minimize the load on their servers. The result of this effort is a specification for HTTP/2, based on a Google proposal called SPDY.
As of today, HTTP/2 is considered "done" and has been formally approved, so that it can become an official IETF RFC! From now on, there should only be editorial changes of the specification.
For these reasons, I think that HTTP/2 may quickly become a very attractive choice for an IoT application layer protocol for the red edge of the IoT Triangle, at least whenever a client / server approach is considered appropriate. It retains all the architecture benefits of REST, fits in well with the existing HTTP ecosystem, and reduces overhead both regarding bandwidth and processor cycles.
But most importantly: the potential customers for Limmat we have talked to all have existing HTTP-based REST backend services. HTTP/2 will by far be the most natural and painless upgrade
path for them if and when HTTP/1.1 should become a problem.
This is why we are focusing on HTTP/2 as our default protocol for IoT in the Limmat project (along with HTTP/1.1). Of course, specific requirements, desired architecture qualities and
technical constraints need to be taken into account for each project individually, and may lead to different decisions. For this reason, we would also consider supporting other protocols for
Limmat gateways if and when this is needed. But as a general-purpose IoT protocol, our bet is on HTTP/2 for the coming years.
Here, another developer's take on HTTP/2 as an IoT protocol. So the ball has started rolling... And when will your device
Cuno Pfister, Oberon microsystems AG
Next week, I'll give a talk (in Session 24/II) at the largest embedded systems trade fair
in the world, Embedded World in Nürnberg, Germany. Guess what IoT protocol I'll be talking about?
I'll collect links here that refer to HTTP/2 and the IoT. Please send me an email to email@example.com if I am missing a good one. Thanks!
Already mentioned above, here the first such reference I've seen:
Tim Kellog's take on how MQTT could be replaced by HTTP/2: http://timkellogg.me/blog/2015/02/20/can-http2-replace-mqtt/
"HTTP/2 lends itself surprisingly well to the pub/sub pattern, despite being designed for request/response."
Dominique Guinard's first blog post on HTTP/2 for the Web of Things: http://webofthings.org/2015/10/25/http2-for-internet-of-things-1/