HTTP 2 0 & Java: Current Status by Simone Bordet
49 0 3813
HTTP 2.0 is supposed to be the next big thing for the web, after the overwhelming success of HTTP 1.1. In this session we will examine the HTTP 2.0 protocol, what is the status of its specification, what features does it offer over HTTP 1.1, and how websites can benefit (in speed and money) from it. The session will also explore what does it take to write HTTP 2.0 applications in the Java platform, what plans there are to support it in JDK 9 and which Servlet Containers are already offering HTTP 2.0 support, finishing up with a demo of HTTP 2.0 new features.
By anonymous 2017-09-20
An alternative solution to adding the
Link headers and have Apache parse them and push the associated resources, is to naturally correlate secondary resources such as
css and image files to the primary resource.
This is the approach that we have taken in Jetty (disclaimer, I am the implementor of that solution).
We use this solution to serve our own Website, based on WordPress, over HTTP/2 with HTTP/2 Push.
The basic idea is that when a browser received an HTML page, it immediately parses it and perform the requests needed to download secondary resources such as
The server, in this case Jetty, can correlate the primary resource (the
html) with the secondary resources.
The next time a request for the same
html page arrives, Jetty already knows what are the secondary resources needed, and can push them.
There is no need for
Link headers, as Jetty "learns" what are the resources needed by a page from the request patterns that the browser performs.
This approach can be fine tuned on basis to basis, but works fine out of the box and provides dramatic performance improvements, see here for the live demo in the video linked above.
I recommend to read/watch the whole slides/video for a larger context about HTTP/2 and HTTP/2 Push, but the point is that the combination Jetty + PHP with HTTP/2 is a powerful solution for HTTP/2 Push and requires no changes to PHP pages - which is perfect when using PHP frameworks such as WordPress or Drupal, and to avoid adding 100+
Link headers to your PHP pages.
By anonymous 2017-09-20
The reason HTTP/2 multiplexing is more efficient than HTTP/1.1 for web pages has very little to do with the cost of opening TCP connections.
In HTTP/1.1, browsers open typically at most 6 connections per domain. After those connections are open, they are kept open and reused over and over, until they go idle.
Yet, HTTP/2 is faster than HTTP/1.1 even after those connections have been opened, so it is clearly not the cost of TCP connection opening in play here.
A typical web page today may have up to 100 resources to be downloaded from the origin server. Let's keep things simple and imagine there is a 200 ms roundtrip between client and server. In order to download the page in HTTP/1.1, the browser has to download the main HTML page (1 roundtrip), then parse the HTML page and arrange to download the 100 resources - but it only has 6 connections. So the browser sends the first 6 requests, then waits for them to come back (1 roundtrip); then another 6 requests, then waits for them to come back (1 roundtrip); etc. In this simple model, to download 100 resources the browser needs 1 + 17 roundtrips, at 200 ms each it means 3.6 seconds.
In HTTP/2, the browser makes the request for the HTML page, but then it is free to make all the requests for the 100 resources without waiting, thanks to the fact that HTTP/2 is multiplexed. In this simple model, to download 100 resources the browser needs 1 + 1 roundtrips, that is 400 ms, for a 10x speedup in download time.
Now, things are not as simple as depicted above, but still the gain due to multiplexing has quite an impact.
You can look at this impact yourself by watching examples online (here and here), and you can watch my HTTP/2 presentation on this and other HTTP/2 benefits (you can watch the demo that explains the multiplexing effect here).