Introduction to HTTP/2 support in Java 9

1. Introduction

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.

2. Latency optimization techniques for HTTP/1.1

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.

• 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 particular page request
• Image sprites is a technique similar to bundling CSS and JavaScript files for lowering the number of requests.
• Another technique being is in-lining static resources to the HTML

3. 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 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.

3.1. 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, thus allowing clients for downloading multiple resources over a single connection simultaneously.

3.2. HTTP/2 header compression

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.

3.3. HTTP/2 push

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.

4. Java HTTP clients supporting HTTP/2

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.

◉ 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 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 jdk.incubtor namespace.

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

The first step is import 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 a HTTP/2 compliant web server. It just echoes back that message what 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 and HttpClient, which is the entry point of initiating HTTP requests, is no exception to that.

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

5.1. 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()
);

Method send block as long as the request is being processed, however there’s a way to exchange HTTP messages asynchronously as well.

5.2. 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));
});

5.3. 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));

});

Source: javacodegeeks.com