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
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
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.
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.
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.
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.
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.
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
Other Sources of Information
- Getting Ready For HTTP/2: A Guide For Web Designers And Developers
- HTTP/2 homepage
- Tracking HTTP/2 adoption
- YouTube video What to Expect From HTTP/2
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.