Java 9: An Intro to HTTP/2 Support

The IETF streaming group approved the HTTP/2 protocol in 2015, 16 years after HTTP/1.1 had been released. HTTP/2 comes with the promise of lowering latency and makes many workarounds necessary for HTTP/1.1 obsolete 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 will look into the 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 impatient 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 times are below 100ms.

When response time goes up to 1 second, that does get noticed, and when it takes longer than 10 seconds 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 1-second delay could cause a 7% loss in revenue.

Latency Optimization Techniques for HTTP/1.1

HTTP/1.1 has needed (sometimes heavy) workarounds to meet today’s requirements.

• As one HTTP connection can download one resource at a time, browsers fetch them concurrently in order to be able to render the page faster. However, the number of parallel connections per domain is limited, and domain sharding was used to work that around.
• A similar optimization technique was to combine multiple resources (CSS, JavaScript) into a single bundle in order to be able to get them with a single request. The trade-off is sparing a network round-trip with the risk of not using some parts of the assembled resource bundle at all. In some cases, complicated server-side logic takes care of selecting the pertinent static resources and merging them for a particular page request.
• Image sprites are a technique similar to bundling CSS and JavaScript files for lowering the number of requests.
• Another technique is inlining static resources to the HTML.

A Brief Introduction to HTTP/2

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 anymore. Clients establish a connection as an HTTP/1.1 request and requests an upgrade. From then on, HTTP/2 talks in binary data frames.

HTTP/2 Multiplexing

HTTP/2 multiplexing makes all of the HTTP/1.1 workarounds above obsolete because a single connection can handle multiple bi-directional streams, allowing clients to download multiple resources over a single connection simultaneously.

HTTP/2 Header Compression

The HTTP 1.x protocols were text-based and, thus, verbose. Sometimes, the same set of HTTP headers were exchanged all over and over again. HTTP/2 diminishes the required bandwidth drastically by maintaining an HTTP header table across requests. Essentially, this is de-duplication and not compression in the classical sense.

HTTP/2 Push

You might think that HTTP/2 push is the continuation or an upgrade of some kind to WebSockets, but that's not the case. While WebSockets are 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 from 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 request them.

Java HTTP Clients Supporting HTTP/2

According to one of the HTTP/2 Wiki pages, at the time of writing, the following Java client libraries are available for establishing HTTP/2 connections.

• Jetty
• Netty
• OkHttp
• Vert.x
• Firefly

In this article, however, we’re focusing on the HTTP/2 support provided by Java 9. JEP 110 specifies the requirements and states that the project is still in the 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 the java.net package. In the meantime, however, it will live underneath the jdk.incubtor namespace.

Explore the HTTP/2 Client of Java 9

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 the existing alternatives (see above).

The first step is to import the module jdk.incubator.httpclient.

module com.springui.echo.client {
    requires jdk.incubator.httpclient;
}

For the sake of this example, we’ll be using Undertow as an HTTP/2-compliant web server. It just echoes back the message that clients send to it.

public class EchoServer {

    private static final Logger LOGGER = Logger.getLogger(EchoServer.class.getSimpleName());

    private static final int PORT = 8888;
    private static final String HOST = "localhost";

    public static void main(final String[] args) {
        Undertow server = Undertow.builder()
            .setServerOption(UndertowOptions.ENABLE_HTTP2, true)
            .addHttpListener(PORT, HOST)
            .setHandler(exchange - > {
                LOGGER.info("Client address is: " + exchange.getConnection().getPeerAddress().toString());
                exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");
                exchange.getRequestReceiver().receiveFullString((e, m) - > e.getResponseSender().send(m));
            }).build();

        server.start();
    }

}

The new API follows the builder pattern everywhere. HttpClient, which is the entry point of initiating HTTP requests, is no exception to that.

HttpClient client = HttpClient
    .newBuilder()
    .version(Version.HTTP_2)
    .build();

Sending a Request in Blocking Mode

Once we have an HttpClient instance, HttpRequest instances can also be constructed with a builder.

HttpResponse<String> response = client.send(
    HttpRequest
        .newBuilder(TEST_URI)
        .POST(BodyProcessor.fromString("Hello world"))
        .build(),
    BodyHandler.asString()
);

The send method blocks as long as the request is being processed, but there’s a way to exchange HTTP messages asynchronously as well.

Sending Requests in Non-Blocking Mode

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.

List < CompletableFuture < String >> responseFutures = new Random()
    .ints(10)
    .mapToObj(String::valueOf)
    .map(message - > client
        .sendAsync(
            HttpRequest.newBuilder(TEST_URI)
            .POST(BodyProcessor.fromString(message))
            .build(),
            BodyHandler.asString()
        )
        .thenApply(r - > r.body())
    )
    .collect(Collectors.toList());

CompletableFuture.allOf(responseFutures.toArray(new CompletableFuture << ? > [0])).join();

responseFutures.stream().forEach(future - > {
    LOGGER.info("Async response: " + future.getNow(null));
});

Processing Push-Promise Frames

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.

Map < HttpRequest, CompletableFuture < HttpResponse < String >>> responses =
    client.sendAsync(
        HttpRequest.newBuilder(TEST_URI)
        .POST(BodyProcessor.fromString(TEST_MESSAGE))
        .build(),
        MultiProcessor.asMap(request - > Optional.of(BodyHandler.asString()))
    ).join();

responses.forEach((request, responseFuture) - > {
    LOGGER.info("Async response: " + responseFuture.getNow(null));
});

Conclusion

HTTP/2 renovates an old text-based protocol with much-needed improvements and makes many of the nasty HTTP/1.1 workarounds obsolete — however, it doesn’t solve every known problem.

From the perspective of Java 9, the new HTTP/2 client looks nice, but 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.