Day 19 - HTTP/2

Written by: Anthony Elizondo (@complex)
Edited by: Tobias Brunner (@tobruzh)

The World Wide Web. You use it everyday. It might even be as old as you are (born in March of 1989). And it all runs over Hypertext Transfer Protocol.

The first draft of the HTTP specification was pretty simple. Just ~650 words, ~25 lines. Since then we've improved on it with HTTP 1.0 and 1.1. It can stream video and retrieve your email.aspx). We've wrapped some security around it with SSL and now TLS. And now we're moving on to the largest change in the protocol in its history: HTTP/2.

Oooh shiny

In the last 26 years HTTP has enveloped the world. Other protocols such as gopher and FTP have fallen in prominence, and seemingly everything runs over HTTP. HTTP APIs are preferred over all other transports, the Web is arguably the world's largest application platform, and web browsers are the planet's most widely distributed runtime.

HTTP/2 was finalized in May of 2015 in RFC 7540 after ~3 years of work. It builds on an earlier protocol from Google called SPDY. SPDY is due to be deprecated in January 2016.

Changes

The main drive in development of HTTP/2 was performance. With so much of the Internet consisting of Web traffic, optimizations in speed and efficiency would have large payoffs. In addition, end users are shifting to a more mobile (or mobile-only) world of increased latency. Plus, web pages are becoming more and more complex, in both size and composition. Security was also an area of focus, with internet privacy at the forefront of many web users’ minds.

HTTP/2 uses a single persistent connection

Over this single connection requests and replies are multiplexed. Like SSH multiplexing, this means less time spent doing connection setup/teardown. (For instance, SSL handshakes are minimized) It also prevents "head of line" blocking which means one slow request will no longer delay subsequent requests.

HTTP/2 is a binary format. This means it can be extremely fast (think Protocol Buffers instead of parsing XML or JSON). The downside of this is we lose the ability to debug connections with "telnet host 80" and "GET /". But hey, with encryption everywhere we couldn't do that anyways, right? If you do need to look at HTTP/2 "on the wire" Wireshark already has a plugin. And for debugging curl 7.43.0 and higher has HTTP/2 support built-in.

TLS Required

Speaking of security, one of the contentious points during the protocol's development was the requirement of transport-level encryption (with TLS). In the end TLS was left as an optional flag; servers are not required to use HTTPS when serving content. However, as it happens, all of the browser makers have agreed to only support HTTP/2 when used over TLS, making it a de-facto standard.

Deployment

What do you have to do? On the client side, nothing! You're likely already running a browser that speaks HTTP/2. Thank you, auto-updating browsers.

And many servers already support HTTP/2. Facebook, Google, and Twitter all already support HTTP/2, enjoying decreased bandwidth usage and better performance, among other benefits. (Oracle, Amazon, Apple, get with it.) If you help maintain a website, consider working with the web developers to upgrade the servers to support HTTP/2.

Enabling HTTP/2 in nginx is a single entry in the server listen directive. In Apache it is 3 extra lines.

And surprise: you're likely reading this article over HTTP/2 right now! https://sysadvent.blogspot.com is HTTP/2 enabled. Check your website, courtesy of KeyCDN. You can also install plugins to add handy indicators to Chrome and Firefox. If plugins aren’t your style you can use Chrome Developer Tools (Network - Right click on columns and show Protocol) or Firefox Developer Tools (Headers - Version). Safari and Edge will show it as well.

Is it better? You can test it for yourself at https://www.cloudflare.com/http2/

(Can you turn HTTP/1.1 off? Probably not a good idea. HTTP/1.1 traffic will likely be around for a while.)

Holiday Easter Eggs

An HTTP server that is seeing too many requests from a client can respond with a RST_STREAM frame containing error code 0xb, ENHANCE_YOUR_CALM. In the future all restaurants are Taco Bell.

There is a "magic string" that browsers send in a header to servers to indicate that they can speak HTTP/2. In 2013 this string was modified in the HTTP/2 specification to contain a reference to PRISM). http://blog.jgc.org/2015/11/the-secret-message-hidden-in-every.html contains further comments from John-Graham Cunning and Mark Nottingham.

Conclusion

HTTP/2 is a major, exciting change in the protocol we all know and love. Hope you enjoyed this quick tour of HTTP/2.

Thanks

Thank you my editor, Tobias Brunner @tobruzh, for his suggestions and corrections. A very large hug to Chris Webber and the organizers of SysAdvent for pulling this project together each year.

References

Ilya Grigorik’s fabulous book High Performance Browser Networking has an excellent chapter on HTTP/2.

Mark Nottingham’s "What to Expect from HTTP/2".

HTTP/2 FAQ https://http2.github.io/faq/

Day 7 - Website Performance Optimization

This article was written by Bob Feldbauer (@bobfeldbauer)

Optimizing website performance can dramatically increase conversions and loyalty, and decrease costs. Although it may be traditionally viewed as a responsibility of developers, the reality is that sysadmins are also often asked to work on website performance optimization.

The following is intended as a busy sysadmin's "crash course" in optimizing website performance.

As with trying to optimize any process, you should establish a baseline to measure any changes against. Install the Firebug Firefox plugin and Yahoo!'s YSlow add-on to measure your initial performance and verify improvements as you make changes. To see performance changes over time from a consistent external source, you can use free tools like Pingdom's Full Page Test or Octagate's SiteTimer. Also, Google's Webmaster Tools shows optimization suggestions based on the Page Speed tool, and crawl stats for the average time spent downloading a page from your site.

Yahoo!'s research shown in the table below shows 62-95% of the time required to load a page is spent making HTTP requests for non-HTML components like images, scripts, and stylesheets. See the following table for the time spent loading HTML vs non-HTML components for popular websites:

Site	Time Retrieving HTML	Time Elsewhere
Yahoo!	10%	90%
Google	25%	75%
MySpace	9%	91%
MSN	5%	95%
eBay	5%	95%
Amazon	38%	62%
YouTube	9%	91%
CNN	15%	85%

As the table indicates, reducing the number of HTTP requests can provide one of the biggest increases in performance. Aggregating CSS and JavaScript into as few files as possible and using CSS Sprites are two ways to reduce the number of HTTP requests.

In addition to reducing the number of HTTP requests, being able to load scripts in parallel instead of serially can improve performance. A newly developed tool called Head JS can be used to load JavaScript scripts in parallel, while retaining execution order. This allows scripts to load without blocking other components from loading.

Most sites include static files that change infrequently (CSS, images, JavaScript, etc) and can benefit from appropriate HTTP caching. See the Google's Page Speed team's guide to HTTP caching for more information.

Another important step in website performance optimization is configuring your web or application server to deliver gzip compressed content. On typical sites, gzipping content reduces text size by 75% and total size by 37%.

In addition to gzip compression, making images, scripts, and CSS files smaller also helps - especially when loading a site on lower bandwidth connections like mobile devices. Even if you gzip scripts or CSS files, you can "minify" them to further reduce their size by 5% or more. Yahoo!'s YUI Compressor can minify both CSS and JavaScript, while Yahoo's Smush.it can optimize image sizes without losing quality.

Although there are many other things you can do to optimize website performance, this "crash course" in optimization should get you started.

Further reading:

1. Yahoo!'s Exceptional Performance team's
2. Web Performance Best Practices by Google's Page Speed team