HTTP/2: 5 things every Enterprise Architect needs to know

Interservice communication is a critical aspect of any distributed architecture. The rise of the internet powered by the HTTP protocol attests to this fact. HTTP/1.1, the most commonly used version of the protocol, has been around for years. It’s used in everything from rendering pictures of cats on web pages to providing the foundational layer for data exchange in REST. But HTTP/1.1 has shortcomings. It’s synchronous in nature and gobbles up TCP connections in no time at all.

The future is the next-generation version of HTTP, HTTP/2. However, it’s not a solution that’s suitable for all situations. Enterprise Architects need to be well aware of some of the basics of HTTP/2 to use the protocol effectively. Thus, we offer the following five things that every Enterprise Architect needs to know about HTTP/2. This list is but the tip of the iceberg when it comes to using HTTP/2. Still, we need to begin somewhere, and these items are a good place to start.

1. It’s supported by all the major browsers, sort of...

Support for HTTP/2 is in force for all the major browsers, which is big win for the protocol. But getting a browser to actually use HTTP/2 can be a challenge. Part of the research for this article involved creating the HTTP/2 server that’s demonstrated in the associated Katacoda scenario and exercising it in a browser and under curl.

It turns out that this wasn’t just a point-and-shoot undertaking. First, Chrome browsers do not like self-signed TLS certificates by default. The same is true of curl. You need a special option, -k, as shown in Figure 2 below, to get curl to work with an HTTP/2 server.

Image

In terms of browser to server connections, some sites that support HTTP/1.1 and HTTP/2 will connect via HTTP/1.1 by default. This isn’t a show stopper, but it does indicate that there is still a ways to go to have HTTP/2 supported for general use by typical, consumer-oriented websites. According to W3Techs.com, only a little over 50% of the websites on the internet support HTTP/2.

HTTP/2 is growing in popularity, but it’s not yet universal. However, where HTTP/2 shows a lot of promise is with technologies designed to use HTTP/2 from the git-go, for example, gRPC.

2. It’s foundational to gRPC

One place where HTTP/2 really shines is with gRPC. gRPC is an application protocol built upon HTTP/2 that allows point-to-point interaction between functions represented on the network. RESTful applications use stateless request/response communication under HTTP/1.1. REST is popular and versatile. However, blocking requests between client and server, which are inherent in HTTP/1.1, can incur performance bottlenecks for applications using REST.

gRPC, on the other hand, exchanges data in binary formats, usually Protocol

Buffers, and the exchange can take place by way of streams or a multitude of parallel requests over a single TCP connection. The performance benefit can be astounding.

You find gRPC used in mission-critical technologies such as Kubernetes and Envoy, to name a couple. gRPC is considered by many to be a “data center” technology. While gRPC and HTTP/2 can be awkward as a way of exchanging data for browser-based, consumer-facing web applications, it’s hard to beat when used in the controlled environment of a data center. gRPC operating over HTTP/2 is perfectly suited to very large, server-side applications, particularly those based on microservice oriented architectures and the serverless computing paradigm.

3. HTTP/2 supports multiple requests on a single TCP connection

HTTP/2 supports multiple requests over a single TCP connection. This is a big deal because browsers have limits on TCP connections. In industrial use, some applications might require hundreds of TCP connections from browser to server. Yet, most browsers support between six and eight parallel connections under HTTP/1.1. This has the result of impeding performance. However, under HTTP/2, browser performance increases significantly because a large number of requests can be made under a single connection.

Things get interesting on the server-side too. Some companies have applications that need to exchange data beyond the connection/file descriptor capability supported by the server’s operating system. Instigating many requests of a single TCP connection significantly reduces the burden caused by the limitation.

4. HTTP/2 supports multiplexed, bidirectional streaming

HTTP/2 supports multiplexed, bidirectional streaming. This means that you can set up an unbroken TCP connection that allows data to flow continuously between client and server. (See Figure 1, below) And, because the connection is bidirectional, the client can stream data to the server while the server is streaming data out to the client. Yes, you could use technology such as WinSockets to keep an open pipe between client and server over the internet. However, HTTP/2 gives it to you for free.

Image

(The illustration shown above in Figure 1 is a screenshot using the demonstration HTTP/2 described in the Katacoda scenario that corresponds to this article.)

5. Security is at the forefront

Last but not least, security is baked into HTTP/2. As of this writing, all implementations of HTTP/2 require the use of Transport Layer Security (TLS). This means that valid public and private key certificates need to be in force on any server implementing HTTP/2 for data exchange between the client and server. Also, TLS provides the encryption mechanism that obfuscates all data exchanged between client and server. HTTP/2 puts security at the forefront of data exchange and makes encryption implicit. It’s a big deal.

Putting it all together

HTTP/2 has been around since 2014. During that time, it has become commonplace. It has experienced some bumps among those adopting it for consumer-based browser applications, but it has broad acceptance in the data center. It is a game-changer in terms of how to do data exchange over the internet, particularly on the server-side. HTTP/2 provides the ability to support a large number of parallel requests over a single TCP connection. Also, the protocol supports multiplex streaming over a single TCP connection. This means that a client can connect to an HTTP/2 powered server and send and receive data in a continuous unbroken stream.

Streaming data easily using HTTP/2 will have an impact on how an Enterprise Architect designs web-scale systems. The impact will be tellingly profound for those architects designing systems based on microservice oriented architectures.