This post is part two of a two-part series detailing HTTP/2 best practices. Part one—How HTTP/2 is Changing Web Performance Best Practices—introduced HTTP/2 and explained how it changes Web-performance best practices.
In the first post in this series about HTTP/2, we discussed different ways the new protocol affects Web performance best practices. Although HTTP/2 offers several improvements over its predecessor—including new features like TCP connection multiplexing, header compression, and server push—an instant performance boost when making the transition isn’t guaranteed as Web developers are still determining best practices. This post covers what’s required to implement and debug HTTP/2-capable Web applications in production environments.
4/4 major browser vendors agree: HTTPS is required
Firefox, Internet Explorer, Safari, and Chrome all agree: HTTPS is required to use HTTP/2 in the first place. This is critical because of a new extension to Transport Layer Security (TLS) that allows browsers and clients to negotiate which application-layer protocol to use. When a TLS connection is established for the first time, the server broadcasts support for HTTP 1.1, SPDY, or HTTP/2 without an additional round trip.
Because of changes Google recently announced, it’s critical that backend SSL libraries are updated before Chrome drops support for the older Next Protocol Negotiation standard in favor of Application Layer Protocol Negotiation. Unfortunately, for almost every modern Linux distribution, this means compiling Web server software from source code with OpenSSL version 1.0.2 (not a trivial task).
With the latest version of OpenSSL installed on servers, however, it’s possible it check hosts for HTTP/2 support from the command line:
me@ubuntu-trusty-64:~$ echo | openssl s_client -alpn h2 -connect google.com:443 | grep ALPN
ALPN protocol: h2
DONE
A Web-based tool from KeyCDN and the is-http2 package can also help determine host support.
The transition to the new protocol is relatively straightforward for sites that are already delivered securely. For non-secure sites, Web servers (and potentially CDNs) will need to be correctly configured for HTTPS. New open-source projects such as Let’s Encrypt aim to make this process as easy, free, and automated as possible. Of course, regardless of HTTP/2 support, moving to HTTPS is becoming more important. Some search engines now use secure sites as a positive signal in page ranking and privacy advocates and industry experts strongly recommend it.
Determining backend and content-delivery network support
If HTTPS is properly configured, the next step is determining if the server or proxy software supports HTTP/2. The IETF HTTP Working Group maintains a comprehensive list of known implementations on its website and popular Web servers have all released or committed to support. Most popular application development languages have HTTP/2 packages as well.
Support for the full suite of HTTP/2 features, especially server push, is not guaranteed. It’s necessary to read the releases notes to determine which features are fully supported.
If your site uses assets delivered by a Content Delivery Network (CDN), major vendors like CloudFlare and KeyCDN already support the new protocol even if your backend doesn’t. With some providers, enabling HTTP/2 between your client and the edge locations can be as easy as toggling a radio button on a Web form.
Using Wireshark for debugging
HTTP/2 tooling still has a long way to go before catching up with HTTP 1.1. Because HTTP/2 is a binary protocol, simple debugging using telnet won’t work and standard debugging proxies like Charles and Fiddler do not offer support as of January 2016.
In part one of our HTTP/2 series, we discussed how to use Chrome Net Internals (chrome://net-internals#http2) to debug traffic. For more advanced analysis, using the low-level C (or Python bindings) of the nghttp2 library or Wireshark 2.0 is needed. Here, we’ll focus on Wireshark.
Configuring Wireshark to view HTTP/2 frame requires additional setup because all traffic is encrypted. To view Firefox or Chrome HTTP/2 traffic, you have to log TLS session information to a file specified by the environment variable SSLKEYLOGFILE. On Mac OS X, set the environment variable before launching the browser from the command line (you can see Windows instructions here):
$ export SSLKEYLOGFILE=~/Desktop/tls_fun.log
$ open -a Google\ Chrome https://nghttp2.org/
Wireshark must be configured to use the SSLKEYLOGFILE in the preferences menu under the “SSL” protocol listing:
Configuring Wireshark for the location of SSLKEYLOGFILE
When starting Wireshark for the first time, a network interface needs to be selected. Filtering only on port 443 is a good idea since all HTTP/2 traffic in Chrome is secure.
Filtering HTTPS traffic on a Wi-Fi network card
After clicking on the shark icon, recording begins for all traffic sent over that interface. The output can be overwhelming, but it’s easy to filter HTTP/2-only traffic by typing “http2” into the filter text box. When HTTP/2 packets are captured, they can now be decrypted into individual HTTP2 binary frames:
Debugging encrypted HTTP/2 traffic in Wireshark
Using the tabs at the bottom of the data panel, it’s possible to see the decrypted frames. HEADERS frames, which are always compressed, can also be displayed decompressed.
The transition is not yet straightforward
For many Web applications in early 2016, transitioning to HTTP/2 is not yet straightforward. Not only is HTTPS required in order to use the new protocol in browsers, it’s likely that server software will also need to be upgraded. In some cases, particularly with Backend-as-a-Service providers or Content Delivery Networks, HTTP/2 support might not be available—or even promised—yet. Lastly, easy-to-use debugging tools are still being worked on.
As many teams have already discovered, it is likely that migrating any large site to HTTP/2 will likely contain surprises. Despite these challenges, many large Web properties have successfully launched HTTP/2 support with significant performance benefits. Carefully measuring real-user performance and understanding the limitations of current tooling is helpful to making the transition as smooth as possible.
Additional resources
Be sure to read part one of this two-part series: How HTTP/2 Is Changing Web Performance Best Practices
Jeff Martens, Product Manager for New Relic Browser, and Web performance expert Andy Davies contributed to this post with technical feedback and invaluable suggestions.
Background image courtesy of Shutterstock.com.