The IETF streaming group approved the HTTP/2 protocol in 2015, sixteen years after HTTP/1.1 had been released. HTTP/2 comes with the promise of lowering latency and makes many of those workarounds obsolete which were necessary for HTTP/1.1 in order to be able to keep up with today’s response time requirements. In this article, I introduce HTTP/2 briefly and how it renews the text-based HTTP/1.1 and then we look into the upcoming HTTP/2 support in Java 9.
As I mentioned in the introduction HTTP/1.1 had become old and the Web has changed a lot since 1999.
People are getting more and more inpatient on the Internet, but they wouldn’t notice that the actions they’re performing on the web aren’t being performed by themselves directly, if response time if below 100ms.
When response time goes up to 1sec that does get noticed and when it takes longer than 10s for a site to respond, it’s considered to be out of order. According to some research the average attention span has decreased to 7-8 seconds and even a 1sec delay could cause 7% loss in revenue.
HTTP/1.1 has needed (sometimes heavy) workarounds to meet today’s requirements.
HTTP/2 is meant to alleviate the pain stemming from maintaining complex infrastructures for HTTP/1.1 in order to make it perform well. Although HTTP/2 is still backward compatible with HTTP/1.1, it’s not a text based protocol any more. Clients establish a connection as an HTTP/1.1 request and requests and upgrade. From that on, HTTP/2 talks in binary data frames.
HTTP/2 multiplexing makes all of the HTTP/1.1 workarounds above obsolete, because a single connection can handle multiple bi-directional streams, thus allowing clients for downloading multiple resources over a single connection simultaneously.
The HTTP 1.x protocols were text-based and thus they were verbose. Sometime the same set of HTTP headers were exchanged all over and over again. HTTP/2 diminishes the required bandwidth drastically by maintaining a HTTP header table across requests. Essentially this is de-duplication and not compression in the classical sense.
You might think that HTTP/2 push is the continuation or an upgrade of some kind to WebSocket, but it’s not the case. While WebSocket is a means to full-duplex communication between the client and the server in order to allow the server to send data to clients once a TCP connection has been established, HTTP/2 solves a problem separate to that.
HTTP/2 push is about sending resources to clients proactively without having to ask for it from the client’s perspective. This practically means that the server side knows that a website needs some images and it sends them all at once (ahead of time) long before clients requests them.
According to one of the Wiki pages of the HTTP/2, at the time of writing the following Java client libraries are available for establishing HTTP/2 connections.
In this article however, we’re focusing on the HTTP/2 support provided by Java 9. JEP 110 specifies the requirements and it also states that the project is still in incubation state, which practically means that it’s not going to replace the existing UrlConnection API in java 9.
Only with Java 10 will the standard Java HTTP/2 client be moved under package java.net. In the meantime however, it will live underneath the
JEP 110 sets requirements for the new, built-in HTTP/2 client so that it provide a high-level, easy to use API and comparable (or higher) performance than existing alternatives (see above).
The first step is import module
For the sake of this example, we’ll be using Undertow as a HTTP/2 compliant web server. It just echoes back that message what clients send to it.
The new API follows the builder pattern everywhere and HttpClient, which is the entry point of initiating HTTP requests, is no exception to that.
Method send block as long as the request is being processed, however there’s a way to exchange HTTP messages asynchronously as well.
In the following example 10 random integers get sent to our HTTP echo server asynchronously and when all of the requests have been initiated, the main thread waits for them to be completed.
All of the examples above could have been normal, old fashioned HTTP/1.1 requests. Apart from creating the HttpClient, nothing HTTP/2 specific can be observed.
Probably the most relevant HTTP/2 feature of the client API is the way it handles multiple responses when HTTP/2 push is used.
HTTP/2 renovates an old text based protocol with much needed improvements and makes many of the nasty HTTP/1.1 workarounds obsolete, yet it doesn’t solve every known problem however.
From the perspective of Java 9, the new HTTP/2 client looks nice, however, it’s going to be production ready only in the next release. In the meantime, the aforementioned libraries above can be used if HTTP/2 support is needed.