HTTP/2 In A Nutshell

The Goal of HTTP2

The goal of HTTP/2 is to increase the perceived performance of the web browsing experience.

Why Do We Need HTTP2

A web page has many resources that need to be loaded. In HTTP 1.0 requests for all resources are sent all at once and the server responds to each request. If one of the resources takes a long time to response then all other resources are blocked because of head-of-line blocking.

Solution to Head-of-Line Blocking

We can load the resources over multiple connections however this is not an efficient use of TCP sockets and there is a restriction on the number of connections per hosts from the browser.

I often post about HTTP/2 and Servlets 4.0 on Twitter. Follow @readlearncode

Workarounds to Host Restrictions

File Concatenation and Image Sprites

Instead of having two style sheets we have just one and we can do the same with JavaScript. An image sprite is a single image file made up of all the sprites you use on the web page. Instead of 10 images, we have just one. Each sprite is cut from the sprite sheet on the client side before use.

Domain Sharding

To overcome the maximum number of connection to a host by the browser we can host the style sheets on one host and the JavaScript on another. This way we are not bound to one host.

Inlined Assets

You can embed the style sheet and JavaScript in the HTML page and even the image can be embedded in the page as a binary. The image is decoded back to an image which is expensive and caching is difficult.

Back to Network Basics

HTTP2 is a new transport layer underneath HTTP/1.1. It is the same request and response model as HTTP1.1. There are no new methods or headers nor are there new usage patterns from the application layer nor new usage of the URL specification.

OSI 7-Layer Model

The HTTP/2 protocol borrows ideas from the 7-layer network protocol stack.

HTTP/2 has taken the ideas of Frames from networks, Streams which is a Session idea, Connections from transport and all of this sits under the HTTP 1.1 protocol.

What HTTP1.1 Says About Sockets

The specification says very little about how many sockets can be opened. It was really only industry standards that decided how many should be opened. They are seen as a throwaway resource so browsers are free to open as many sockets to the same server.

What HTTP/2 Says About Sockets

In contrast, they are seen as a scares resources and the specification says a lot about how they are to be used. Ideally, you should open only one socket to the server and everything you need to do is done over this socket.

Top Line-Features of HTTP/2

Request/Response Multiplexing

Over a single TCP connection request and response is multiplexed with full bi-directional communication.

Lets defined some terms used when talking about multiplexing:

Connection – A single TCP socket
Stream – A channel within a connection
Message – A logical message, such as a request or a response and control message
Frame – The smallest unit of communication in HTTP/2. For a given request it is broken down into smaller parts.

For a given connection you can have multiple streams and for a given stream you can have multiple messages and for a given message you can have multiple frames.

Now that communication has been broken down into frames you can interweave the logical streams over a single TCP connection and the issue of head-of-line blocking is removed.

Binary Framing

The basic unit of communication is the frame. Each frame contains header data that contains length, type, flags, and a stream identifier. This identifier is used to track the frames membership of a logical stream.

Type fields can be DATA, HEADERS, PRIORITY, RST_STREAM, SETTINGS, PUSH_PROMISE, PING, GOAWAY, WINDOW_UPDATE, CONTINUATION.

DATA is the body data, HEADERS corresponds to the HTTP headers, PRIORITY refers to the streams priority.

Header Compression

Headers in the request and response are mapped to the HEADERS in the frame. This results in duplication of header information: most headers are the same except for the path. The solution to this is header compression also known as HPACK.

Both the server and the client maintains a table of the headers and send only a reference and updates to the table.

Stream Prioritization

The stream priority is not an integer, it is more. It is a dependency tree of streams weighted to the resources to be used on that stream. It is just a suggestion to the parser and so it can be ignored.

Server Push

Server push lets the server push resources to the browser and then sends an SSE (Server Side Event) to the browser’s cache with the name of the resources. The browser can then use JavaScript to look for those resources and will find it in the cache and therefore will not need to request it from the server. This eliminates the requirement for resource inlining.

Upgrade From HTTP1.1

Most websites are using HTTP1.1. To talk in HTTP/2.

You can use the upgrade header (101 switching protocols) to send h2c to the server, the server will upgrade to h2c (c means clear text). However, there is no h2c in Firefox or Chrome.

What if it is secure? We can use ALPN which is a TLS extension and in the handshake, you send an extension and the server will determine that the communication is h2 and will continue using h2.

JavaEE Support

Servlet 4.0 fully supports HTTP/2 and is due for final release in Q4 2016. It is guaranteed 100% compliant and exposes the key features to the API.

Java 9 Support

There will be an easy to use API which covered most use cases scenarios. it will be backward compatible to HTTP/1.1 and in fact, builds on the Java API classes going back to Java 1.2.

This is all taken care of in JEP 110.

Configure Tomcat 9

As Tomcat 9 must have TLS configured for HTTP/2 to function in Firefox and Chrome I wrote the article Configure in Tomcat 9 for HTTP/2 in which I demonstrate how to configure TLS in Tomcat’s server.xml file.

Tracking HTTP/2.0 Adoption

The adoption of HTTP/2 can be tracked by searching Shodan for servers and the protocols that they support. The state of adoption was reported on by John Matherly who blogged about its adoption in December 2015. I wrote a follow-up post looking at the state of adoption of HTTP/2 in April 2016 and the progress that has been made.

How to Get Involved

You can Adopt a JSR, become a Java EE Guardian and follow their twitter @javaee_guardian and follow Arun Gupta’s Github JavaEE8.

Other Sources of Information

Acknowledgements

Thank you to Ed Burns and Shing Wai Chan (Servlet 4 specification leads) for the presentation they gave at JavaOne 2015 on which much of the information in this article is based. You can watch the full video on You Tube.