Architectural considerations for choosing a communication protocol
The purpose of this article to give a high-level overview with some practical insights into the current state of communication protocols frequently used across internet-enabled devices.HTTP/2 is an IETF proposed standard (referenced as RFC 7540) that has been issued in May 2015. It is the continuation of the widely used HTTP 1.1 version that has been published in 1997. HTTP/2 is still a relatively new piece of technology, according to caniuse.com, about 76% of internet-connected clients can take advantage of its presence on a web server.
One could ask: why do we need a new core protocol for the internet, when the previous served us great for almost two decades? The answer lies in the fact that Internet changed from being niche to the basic fabric of our societies. In 1997, there were about 120 million internet users. Today, this number is more than 3,4 billion. Web pages become increasingly complex, popular sites often creating as many as forty TCP connections for a single client (check netstat | grep http). This and many other workarounds, such as embedding CSS or JS in HTML documents to avoid extra file transfers, show that delivering a rich web experience needs a more fundamental redesign, in this case on the transport protocol level.
HTTP/2 provides a set of well-thought improvements over its predecessor: sharing a TCP connection between resources becomes possible without one blocking another. This is achieved by multiplexing that creates small chunks of data and interleaves them with each other. Header compression reduce the HTTP overhead while preserving the trait of being a stateless protocol. Changing to a binary wire format from text-based will mandate the use of special tools (e.g. WireShark 2.0 or newer) but it will also make processing faster and straightforward.
HTTP/1.1
|
HTTP/2
| |
Format
|
Text-based
|
Binary
|
Multiplexing (a single TCP connection for multiple data streams)
|
No
|
Yes
|
Header compression
|
No
|
Yes
|
Server push
|
No
|
Yes
|
Prioritization
|
No
|
Yes
|
WebSockets
|
HTTP/2
| |
Format
|
Binary
|
Binary
|
Multiplexing
|
No
|
Yes
|
Header compression
|
N/A
|
Yes
|
gRPC
|
Socket.io
| |
Format
|
Binary
|
Binary (WebSocket)
|
Multiplexing
| ||
Header compression
| ||
If the goal is to keep connection through an unlocked arrive at the data, it may be that we should use HTTP instead of WebSocket was.
But if you insist on for HTTP, then the implementation will depend on the client side to receive the data in order to manage. The solution is probably the most reliable Server Sent Events. To do that you can imagine in this Node.js library to use: https://www.npmjs.com/package/sse but it may be that the server does not work with HTTP2 (in this case, if you send an error report, you can count on it that the the problem will be fixed deadline but I can not guarantee :)).
If the client-side JavaScript code will not, but the browser itself will process the data (eg, video streaming, etc.) You can use the standard Node.js stream classes to make more installments submit the data to the client, this class is a descendant of HTTP Response object. Such a receiving stream from JS is not fully reliable, that the package can be shifted borders, etc. so I do not recommend it if you want to receive the incoming data in JS.
But there are higher-level abstractions, for example. socket.io the library, which hides the details of implementation and provides bi-directional packet data communication between the client and the server. This is probably the easiest solution if you do not care about the transmission medium, you receive only the data simply and reliably.
Actually, all of which they are independent from the HTTP2, only the HTTP2 push server could be used for something similar, but this is not yet used by JS API, so you think it will fail.
---
Now let's abstract away from browser-specific details.
The HTTP2 would also be a good choice if Browser server communication is not the case. The GRPC, which Google RPC framework for the HTTP2 from buildings, for instance.
If the low-level streams to HTTP2 are accessible (not just through the browser JS APIs), it give much more flexibility in the protocol. The node http2 in such a low level of access gives the http2.protocol API, which is broadly documented here: https://github.com/molnarg/node-http2/blob/master/lib/protocol/index.js
Low-level stream of calls handled are Node.js Stream API (cork / uncork I will destroy used indefinitely flush roughing), en thought that the browser is not something :) JS APIjaban but TCP is not recommended in some cases based on this, if luggage based communication you want to implement, because the area may want to package the client can shift due to the buffering. Instead, the HTTP2 has a framing layer, which in turn can be used for packet based communication when approaching low-level access to the HTTP2 implementations (such as http2.protocol API).
The HTTP2 push API can be interesting if you look at your ass non-browser client. The only strange saga that's always a push to stream should have a pre-existing non-streaming push you. The Web is about both the validity, to say the HTML file is download the client and the server push to the corresponding CSS, JS, etc. files. If you are not a web of context, it is not unique to mar what belongs push streams, in many contexts does not make sense to declare it.
If the framing layer is HTTP2, push, or other low-level HTTP2 things you want to use a PoC establishment, good question which one should you use HTTP2 lib, I suspect that this sort of thing is no one is too good documentation and API
Selecting the most suitable communication protocol for industry devices or Internet of Things (IoT) is a challenging task. Changing an existing architecture is even more so. Creating a migration plan is required to ensure a good fit with existing deployments and network characteristics. Other protocols, such as CoAP or MQTT are also popular in the IoT world, but HTTP/2 can be also satisfactory in many use cases where resource constraints are not so low as described in RFC 7228 (10 KiB of RAM and 100 KiB of code space). This could be especially true when used with a battle-hardened framework like gRPC. Which has just been released on 23 August 2016 with version 1.0.
A small remark: we can remember Gmail being titled as “Beta” even when it far surpassed any other mail provider in quality, so version 1.0 at Google means a different thing than in other large software houses.
gRPC perfectly fits other criteria as well: it is based on standards, it’s open-source and even the wire-level data format is well-documented – therefore vendor lock-in can be easily avoided.
Before we go further, let’s see what other architectural approaches we could consider.
Should a communication middleware be used?
Middleware solutions provide loose coupling and extra features to deal with communication tasks in a complex enterprise environment. However, these extra features come with an added installation and management complexity that are not rationalised by all use cases. So as always, a careful analysis should take place regarding pros and cons.
Robust communication
Middleware solutions provide services like guaranteed delivery that are useful if a client or network error occurs.
Deploying middleware
Firewall ports
Firewall management is a cumbersome process in corporate environments. Well, for good reasons, firewall policies are fundamental to IT security. In addition to providing a business rationale, usually more than one managers need to authorize such a change. Therefore it often takes days or even weeks to get through.
Reasons for choosing HTTP-REST as a base protocol
· Port 80 and 443 is open everywhere
· Lo-REST (using GET and POST requests) can pass almost all firewalls even where other HTTP methods may not get through
· Middleware solutions need a special port (AMQP: 5672, MQTT: 1883/8883), managing it in corporate IT environment can be cumbersome
Choosing HTTP-REST as a base protocol
Developers know it, easy to start with, go through firewalls
Challenges
TCP is bidirectional but how to realise in practice with request-response semantics
Low-level approach – streams and frames
· Browser focus
· API documentations
GRPC
· Features
· Characteristics of a truly open and mature communication protocol
