HTTP/2 – concepts and status quo for Java EE developers

The HTTP/2 specification was finished by the end of 2015 and is the first significant protocal update since HTTP1.1, which was released in 1997.
HTTP/2’s main goals are shortened loading times and decreased latency. Additionally, performance tweaks that are currently used for HTTP1.1 (domain sharding, image sprites,…) ought to be obsolete.

The browser and web server support is already quite good and Java delevopers can start to write HTTP/2 clients.

Let’s have a look at the concepts of HTTP/2 and how Java developers can use them.

The problems of HTTP1.1

Before we get to the goals and features of HTTP/2 we take a step back and look at the problems of HTTP1.1.

  • Many many many request-response-cycles
  • The multiple TCP-connections between client and server harm the web server
  • The Head-of-line blocking problem

    „Head-of-line blocking in computer networking is a performance-limiting phenomenon that occurs when a line of packets is held up by the first packet, for example in input buffered network switches, out-of-order delivery, and multiple requests in HTTP pipelining.” [1]

Goals of HTTP/2

Based on these drawbacks, the main goals of HTTP/2 are:

  • Speed up the client-server-communication
  • Decrease loading times and latency
  • Maintain compatability to HTTP1.1
    • Existing web sites or servers relying on HTTP1.1 should not need to be changed if the browser supports HTTP/2 for example
    • The HTTP methods (GET, PUT, POST, DELETE), status codes and header fields stay the same for the most parts

Fundamental terms of HTTP/2

  • Connection
    • A TCP-connection between client and server
  • Stream
    • A “channel” inside a connection
    • Connection 1:n Streams
  • Message
    • A HTTP Request or Response
  • Frame
    • The smallest unit of communication in HTTP/2
    • Message 1:n Frames


Binary framing mechanism

  • A request/response in HTTP1.1 is a single enclosed unit, in HTTP/2 messages are split up in frames
  • Every frame can be assigned to a stream by its stream-id
  • These frames can be sent/received asynchronously
  • -> Enables multiplexing on one TCP connection

binary framing layer[2]

streams and messages 2[3]

Parallel loading of resources based on one TCP connection

  • Based on the binary framing mechanism, the data transfer in HTTP/2 can be executed in parallel on one TCP connection
  • Every connection consists of one to many streams
  • The independent frames are transmitted on a certain stream

streams and messages[4]

Compression of HTTP headers

  • HTTP/2 uses hpack compression for the headers
  • Client and server maintain a list with already transmitted values, so that only new values need to be sent

Support for Server-Push

  • HTTP/2 offers the possibility to anwer a request with multiple responses
  • -> A server can send resources to the client that he has not requested yet
    • If for example a client requests the “index.html” file, the server can answer with the HTML page and additionally send along the needed CSS/JS files or other resources
  • -> The amount of request-response-cycles is reduced


  • The Application-Layer protocol Negotiation is used to negotiate the protocol to be used (HTTP1.1 or HTTP/2) between client and server


  • In most drafts of the HTTP/2 specification the support for TLS was declared as a fixed requirement
  • In the final specification, TLS was finally declared as optional
  • However, the browser vendors only support HTTP/2 with TLS at the moment

Browser support

browsersupport_can i use[5]

General Web-/AppServer support

  • Apache, version 2.4.17+ (complete)
  • Citrix NetScaler, version 11+
  • Jetty, version 9.3+
  • Microsoft IIS (in Windows 10 and Windows Server 2016)
  • nginx, version 1.9.5+
  • Wildfly, version 9+

AppServer support today

Wildfly (respectively the included webserver Undertow) offers basic support for HTTP/2 as of version 9.0.0. Unfortunately it is not as easy to set up as HTTP1.1, mainly due to the requirement to support TLS and ALPN.

“The upcoming Wildfly 9.0.0.Beta1 release supports HTTP2, which includes new features like request multiplexing and server push, unfortunately due to a few different factors it is not as straightforward to set up as HTTP1. The complexity comes because HTTP2 as implemented by major browsers requires the use of TLS. This is further complicated by the fact that it does not use straight TLS, but requires a extension called ALPN (application layer protocol negotiation).
Support for ALPN will be coming in Java 9, however unfortunately it is not present in JDK7 or JDK8. To get around this we need to install a jar that provides ALPN support into the JVM’s boot class path. The version of the jar file that you need is tied to the JVM version in use, so you must make sure you are using the correct version for you JVM.” [6]

Standardized Java EE support

HTTP/2 will officially be supported in the upcoming Servlet 4.0 specification, which will be part of Java EE 8 (scheduled for release in the first half of 2017).

An example of how the programming model might look like (and a nice summary about HTTP/2 in general) can be found here.


  • (Only) 5.6% of the top 10million websites use HTTP/2 (December 2015, [7])
  • The compression of message headers lead to reduction of 85-88% [8]
  • Loading times could be reduced by 23-44% [9]
  • Latency could be reduced by ~30% [9]


Short URL for this post:
This entry was posted in Java EE and tagged , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *