Birth of new IoT protocol was TODAY

Archive
1

HTTP/2 as the new IoT protocol, coming out of stealth 8)

http://robbysimpson.com/2015/01/26/http2-and-the-internet-of-things/#comment-14

As I say in my blog post: maybe not suitable for [em]every[/em] IoT application. But for every project I’ve personally been confronted with so far :wink:

Cuno

15 Likes
2

oooo, just in time for Carbon :slight_smile:

4 Likes
3

@ Cuno - Good stuff. Thanks for sharing.

4

When will we be using HTTP2 on our NETMF devices?

4 Likes
5

A quote fro the article, for those too lazy to read the entire thing on what this “http2” is

"Well, I’m hoping that the next version of HTTP, HTTP/2, helps to lessen those problems. Of course it will not be as efficient and great for embedded devices as a protocol designed for the embedded space, but consideration was given to the embedded space during the design of HTTP/2. And the goals of the large Web servers often align with those of the embedded space — less memory and bandwidth also matter if you are serving millions of clients!

How does HTTP/2 help? Well, for starters, it employs a very efficient, yet low memory (unlike gzip) compression technique, HPACK. HPACK works by assigning header names and values to entries in tables. Then, only the entry number needs to be used. This allows for efficient use of bandwidth while not sacrificing the original syntax of HTTP. The sizes of the tables can be limited via negotiation, limiting RAM usage.

What about the complex parsing, you ask? Well, it’s not entirely gone, but HTTP/2 did a lot to try and tighten the syntax and thus the parsing. As with all new protocols, a lot of the legacy could be dropped or tightened. Finally, for those header names and values that may not warrant entry into the tables built up between server and client, Huffman codes can be used. Canonical Huffman codes, in fact.

HTTP/2 also encourages each client/server pair to use a single TCP connection. Individual requests and their responses are sent in streams over this connection. Once again, the number of simultaneous streams can also be limited via negotiation. This connection reuse means less network overhead - no more three-way handshake for each request/response, no more slow start over and over again, no more TLS renegotiation over and over again. You get the point. And considering IoT devices tend to focus on short messages, the benefits really add up.
"

6

@ Cuno - thank you for sharing this :clap: