If you’re interested in the evolve of HTTP/2 and following it’s adoption, you will notice the face that Google Chrome from version 51 (released at May 31st, 2016) has dropped supported NPN (Next Protocol Negotiation) which led most of the webservers currently rely on HTTP/2 fall back to HTTP/1.1
Falling back from HTTP/2 to HTTP/1.1 means slower response times, which affect user experience more or less.
Google Chrome confirmed that dropping NPN, and only support HTTP/2 over ANPN (Application-Layer Protocol Negotiation) is
to provide incentives for server deployments to move away from NPN
- So what’s exactly NPN and ALPN?
- Why HTTP/2 the big deal?
- What should we do as developers?
The story of HTTP/1.x and HTTP/2
HTTP/1.x served the web for amost 20 years.
To fix the issues of HTTP/1.x, Google introduce a new transport layer named SPDY. SPDY was accessed over SSL/TLS, and Google developed an SSL/TLS modification called Next Protocol Negotiation (NPN) that allows clients to upgrade their SSL/TLS connections from HTTP/1 to HTTP/2.
Later, The Internet Engineering Task Force (IETF) accepted the SPDY, revised it and introduce a new standard protocal named HTTP/2 (some named it HTTP/2.0 but HTTP/2 should be the only official name).
NPN was also submitted to IETF, revised, and released as a new name: ALPN.
Under the system view, NPN or ALPN is implemented by OpenSSL, the very famous Linux library.
The issue is ALPN only introduced and release in OpenSSL 1.0.2 or above, but most of our Linux distribution is currently rely on OpenSSL 1.0.1
Why HTTP/2 the big deal?
At a high level, HTTP/2:
- is binary, instead of textual
- is fully multiplexed, instead of ordered and blocking
- can therefore use one connection for parallelism
- uses header compression to reduce overhead
- allows servers to “push” responses proactively into client caches
Needless to say, HTTP/2 was born to fix almost all the issues of HTTP/1.x and then to serve mordern web application well. It reduces web server’s load and increase web performance.
What should we do as developers
It’s very hard to upgrade the operating system to have newer version of OpenSSL.
It’s almost impossible to upgrade OpenSSL globally in your machine, since alot of application rely on OpenSSL.
It’s also hard to keep using HTTP/1.X when HTTP/2 is already there. There’re some recommendations for this case:
– Upgrade your operating system
– Recompile NGINX from source and use a private build with OpenSSL 1.0.2
I’m using nginx and I wrote a shell script to compile nginx with latest stable version of OpenSSL (1.0.2h at the writing time). It’s out of context for this blog post, but if you need the shell script, feel free drop me at firstname.lastname@example.org.
This is not much recommended since you must take care of upgrading OpenSSL yourself
– Run NGINX in a container
Make use of Docker and run nginx inside an Ubuntu 16.04 for example to have built-in OpenSSL 1.0.2
This is the preferred way if you have Docker already on production