Interview with Simone Bordet

“HTTP/2 has become the next big thing with respect to web protocols”

JAXenter Editorial Team
Simone Bordet

HTTP/2 is supposed to be the next big thing for the web, after the overwhelming success of HTTP/1. We talked to JAX 2016 speaker Simone Bordet about the HTTP/2 protocol, what is the status of its specification, what features does it offer over HTTP/1, and how websites can benefit from it.

In this interview, Simone Bordet, Lead Architect at Webtide and speaker at JAX 2016, is talking about the features of HTTP/2, what it takes to write HTTP/2 applications in the Java platform, what plans there are to support it in JDK 9. 

JAXenter: Has HTTP/2 managed to become the next big thing for the web?

Simone Bordet: HTTP/2 has certainly become the next big thing with respect to web protocols. The design of the protocol is based on today’s web application needs, and it was a needed update after 20 years of HTTP/1. The web has evolved so much over the past 20 years that we needed a new protocol designed for today’s web needs (not for the needs of 20 years ago).

The major issue of HTTP/1 is the limited number of requests that can be made concurrently.

JAXenter: What features does HTTP/2 offer that HTTP/1 lacks?

Simone Bordet: The two major features of HTTP/2 that HTTP/1 lacks are multiplexing and resource push. Other important features include HTTP headers compression, resource prioritization and request cancellation, but the first two make HTTP/2 sites really shine.

JAXenter: How can websites benefit from HTTP/2?

Simone Bordet: The major issue of HTTP/1.1 is the limited number of requests that can be made concurrently, typically only 6. Today’s web, however, requires 20-100+ requests to render a single page.

Here’s an example: imagine making 60 requests over six connections to render a page: with HTTP/1, 10 roundtrips are required to fetch all resources. With HTTP/2, those 60 requests can be sent immediately thanks to multiplexing, requiring just 1 roundtrip to fetch all resources. This means that the roundtrip latency, which is the major factor that slows down page rendering, has been cut by a factor 10, which is a huge result.

Now, in reality, things are not always so simple, but the performance provided by HTTP/2 multiplexing alone is sufficient to make a website much snappier. Online examples such as or show how impressive HTTP/2 could be with respect to HTTP/1. And a variety of studies have shown that a snappier user experience directly relates to more time spent on the site, more pages navigated, which eventually means more business revenue. It’s not only a technical detail.

Many currently so called “best practices” such has domain sharding, resource inlining and image spriting are actually just (complex) workarounds to HTTP/1 limitations. With HTTP/2, all those workarounds are not needed, making web development simpler and faster.

HTTP/2 is already here, it is just a matter of updating the infrastructure to benefit from it.

JAXenter: What does it take to write HTTP/2 applications in the Java platform?

Simone Bordet: Developers don’t have to do anything, and that’s good. Servlet Containers can already be configured for HTTP/2 and deploy existing web applications without a single change in the web application. Jetty was the first Servlet Container to implement HTTP/2, and it’s now deploying web applications over HTTP/2 for over a year.

Deployers have to be aware that HTTP/2 websites require HTTPS, and therefore have to be ready to set up a public key infrastructure. Fortunately, public key infrastructure providers such as Let’s Encrypt now offer free certificate signing and tools to automate certificate renewal.

HTTP/2 is already here, it is just a matter of updating the infrastructure to benefit from it, and the benefits are potentially very large. Projects like Jetty already provide both client and server libraries that can be used to write HTTP/2 applications of any kind.

JAXenter: Are there plans to support HTTP/2 in JDK 9?

Simone Bordet: JDK 9 will support HTTP/2 via two specific JEPs. JEP 244 will provide the ability to handle ALPN, a TLS extension required to negotiate HTTP/2 over a TLS connection. This is a requisite that is fundamental for HTTP/2 support. While ALPN is already available for JDK 8 via external libraries (an effort also initiated by the Jetty project), having built-in support in JDK 9 will allow implementers to benefit from the standard APIs.

JEP 110 will provide a standard HTTP client API that will be able to speak HTTP/2 as well. This will allow developers to have HTTP/2 client capabilities built-in into JDK 9.

Thank you very much!

Simone Bordet is a Jetty Committer, the CometD project leader and works as Lead Architect at Webtide. Active open source developer, he founded and contributed to various open source projects such as Jetty, CometD, MX4J, Foxtrot, LiveTribe, and others. Simone has been technical speaker at various national and international conferences such as Devoxx, JavaOne, CodeMotion, etc., and is a co-lead of the Java User Group of Torino, Italy. Simone specializes in server-side multi-thread development, J2EE application development, in Comet technologies applied to web development, web network protocols (HTTP, WebSocket, SPDY, HTTP/2) and in high performance JVM tuning.

Inline Feedbacks
View all comments