A new HTTP protocol eases server-side development
The HTTP protocol is finally getting its first major overhaul, bringing a number of improvements to managing the connections between servers and users.
HTTP/1.1, the dominant HTTP protocol for creating Web applications since the early 1990s, led to the development of REST API interfaces for server-to-server and mobile communication. But a number of new alternatives are starting to emerge that promise better performance and simpler applications. Google's work on SPDY led to a variety of improvements that were baked into HTTP/2, which was finalized in February 2015.
SPDY and HTTP/2 brought a number of improvements to managing the connections between servers and users. Google saw a 15% to 43% performance improvement with SPDY, depending on the application.
HTTP/2 is here, is fast and you should just implement it. SPDY was the test bed for HTTP/2 so the protocol is really not new, it has just been finalized.
Jonathan Klein,
lead engineer, Attend Inc.
Addressing the shortcomings of HTTP/1.1
With head-of-line blocking, a single slow request will block subsequent requests. A browser can stall when a Web application is requesting an HTML file and the CSS file required for rendering the HTML file is sent over a slow connection.
One practice developers have used is to make multiple connections to each domain to improve download speed. Developers have been able to mitigate the risk of a stall by creating multiple connections to the server, said Jonathan Klein, lead engineer at Attend Inc. and formerly software engineer at Etsy. Multiple TCP connections use extra connections but won't require more bandwidth.
Another kludge developers have implemented has been domain sharding, where the application will open up more than six connections per subdomain. But this requires an extra DNS lookup and some implementation complexity.
The benefits of HTTP/2
HTTP/2 allows the server to interleave multiple connections with the client. This reduces the need to combine CSS and JavaScript files, which means that developers don't have to in-line small CSS and JavaScript files. It also reduces the need for data URIs and domain sharding.
This HTTP protocol also removes redundancy from response headers. When a second request sees that the header is the same, it can send that as part of encoded headers in the data, which reduces the payload size.
Request prioritization makes it easier for developers to specify which bytes to send to the client first. This allows the top-of-the-line webpage to be rendered first and the content at the bottom of the page to be received later. As a result, a user can begin interacting with the page more quickly.
Server-push allows developers to serve resources to the client that will be needed later on. Klein said, "Some people get nervous about pushing later on. The client has not asked for it, but, really, this is just like in-lining. The benefit is that this can be cashed by the client and prioritized by the server. This provides the same benefits of in-lining with no downsides."
Changing practices for the new HTTP protocol
"If you are already combining CSS/JavaScript, there is no reason to stop," Klein said. These larger files may even benefit from better compression, so it is a good idea to look at performance before choosing larger combined files or smaller ones.
Applications also should be crafted to serve actual requests rather than in-lining content so that the browser can cache the content better. It's also a good idea to stop domain sharding, which hurts HTTP/2 connections.
Klein said, "HTTP/2 is here, is fast and you should just implement it. SPDY was the test bed for HTTP/2, so the protocol is really not new, it has just been finalized."
