Table of Contents for
Learning HTTP/2
Learning HTTP/2
Published by
O'Reilly Media, Inc., 2017
- nav
- Cover
- Learning HTTP/2
- Learning HTTP/2
- Preface
- Foreword
- 1. The Evolution of HTTP
- 2. HTTP/2 Quick Start
- 3. How and Why We Hack the Web
- 4. Transition to HTTP/2
- 5. The HTTP/2 Protocol
- 6. HTTP/2 Performance
- 7. HTTP/2 Implementations
- 8. Debugging h2
- 9. What Is Next?
- A. HTTP/2 Frames
- B. Tools Reference
- Index
- About the Authors
- Colophon
Chapter 7. HTTP/2 Implementations
A contributor to the success of HTTP/2 is the support it received in terms of the number of implementations available in mainstream tools. Even before the RFC was finalized, a significant portion of the internet user base was talking h2 behind the scenes, unknowingly reaping the benefits of the “next best thing to hit the web.” Support was not limited to a fringe of experimental browsers and web servers. Rather, the most popular browsers, servers, proxies, caches, and command-line tools included h2 early on. Understanding what is available and what options exist for the various implementations is important for your development plan, whether its goal is targeting your web user base, or choosing a web server or proxy.
As the internet moves faster than the speed of the written word, there is no chance we will hit every functionality corner case or list every supporting piece of software. This chapter will at least serve as an overview of features to look for and a good place to start in your selection efforts.
Desktop Web Browsers
Browsers are developed so that you do not need to understand anything about h2 in order to use it. Everyone who uses a modern popular web browser is already using h2 on a daily basis. HTTP/2 causes things to work slightly differently than before, however, and understanding those differences and the different features that surround them can be important for your development and debugging efforts.
TLS Only
All browsers mentioned in this chapter require the use of TLS (HTTPS) in order to speak HTTP/2. This is despite the fact that the HTTP/2 specification itself does not require TLS. See “Is TLS Required?” for a discussion on this topic.
Disabling HTTP/2
HTTP/2 is new, and because of that, when encountering problems you may want to try testing your site with it turned off. Or perhaps you want to look at your request waterfalls with h2 on and with h2 off. In either case you need a way to turn HTTP/2 on and off in a browser. Unfortunately, not all browsers give you this ability. Table 7-1 indicates which ones do.
| Browser | First HTTP/2 Version | Disable | Push | Coalescing | Debugging | Beta channel |
|---|---|---|---|---|---|---|
Chrome |
41 (Mar 2015) |
Yes |
Yes |
Yes |
Yes |
Yes |
Firefox |
36 (Feb 2015) |
Yes |
Yes |
Yes |
Yes |
Yes |
Microsoft Edge |
12 (July 2015) |
No |
Yes |
No |
Yes |
Yes |
Safari |
9 (Sep 2015) |
No |
Yes |
No |
No |
Yes |
Opera |
28 (Mar 2015) |
Yes |
Yes |
Yes |
Yes |
Yes |
Support for HTTP/2 Server Push
Server Push is one of the most exciting features in h2, and one of the hardest to use correctly. Since it is not needed for simple delivery of pages it is sometimes left out in initial h2 implementations. All the major browsers (see Table 7-1) support this feature.
Connection Coalescing
Support for connection coalescing can improve the performance of requests by causing existing connections to be reused when previously a new one would have been needed to be established. This means the TCP and TLS handshakes can be skipped, improving the performance of the first request to the new host. Browsers that support coalescing will first check to see if they have a connection that happens to go to the same place before opening a new one. In this case, same place means that the certificate on the existing connection is valid for the new hostname and the hostname resolved to the IP address of that connection. Under those conditions, the browser will send HTTP/2 requests for the new host on the already established connection.
HTTP/2 Debugging Tools
When working with h2 it is at times important to be able to see what is going on behind the scenes. Some browsers have great support specifically for h2 in their toolset. See Chapter 8 for a deep dive on that topic.
Beta Channel
Though not strictly an HTTP/2 feature, having access to beta (or earlier) versions of a browser can be a great way to stay ahead of changes and play with the bleeding edge of protocol development.
Note
See canisue.com1 for a comprehensive, up-to-date list of browsers that support h2.
Mobile
Mobile browsers generally closely follow on the heels of their desktop brethren these days (Table 7-2).
| Browser | Operating system | First HTTP/2 version | Push | Coalescing |
|---|---|---|---|---|
Chrome |
iOS |
41 (Mar 2015) |
Yes |
No |
Safari |
iOS |
9.2 (Sep 2015) |
Yes |
No |
Chrome |
Android |
12 (July 2015) |
Yes |
Yes |
Android |
Android |
53 (Oct 2016) |
Yes |
Yes |
Microsoft Edge |
Windows Mobile |
12 (July 2015) |
Yes |
No |
Note
No mobile browser at this point supports turning h2 support off.
Mobile App Support
Following the XCode update in June 2015,2 Apple included h2 support in iOS using NSURLSession by default, with app transport security allowing native iOS apps to benefit from the h2 protocol. For Android apps to benefit from h2, the app needs to use an h2-capable library like OkHttp3 and connect to an h2-capable web server over TLS.
Servers, Proxies, and Caches
When it comes to serving content over h2 you have a number of choices. HTTP/2-enabled endpoints come in two basic flavors:
- Web server
-
Traditional processes that serve static and dynamic content.
- Proxy/cache
-
A process that sits between a server and an end user. It can be used to offload a web server (via caching), add additional processing, or both. Many proxies can also fill the role of a web server.
These are often used together to create high-performing websites with high availability; though for smaller sites a proxy layer may be unnecessary.
There are a number of critical areas to examine and evaluate when choosing a server for HTTP/2. Beyond the basics of general performance, OS support, personal knowledge, scalability, and stability, you should also look at support for Server Push and dependencies/priorities.
Push is generally implemented in one of two ways: static inclusion of files and triggering off of link headers and tags. Neither of these methods is perfect, but if configured carefully they can have a positive impact on performance. Perfect push requires coordination with the browser to know what is in its cache to avoid unnecessary pushes. No server supports that—at least not yet.
Proper support of dependencies and priorities is one of the most important tools for getting the most out of HTTP/2 for web performance. This is where much of the “science” goes into building an h2-capable server. It may be worthwhile testing a few servers against a few different browsers to get a feel for what is performing best for your use case.
Table 7-3 summarizes the common servers and their capabilities as of this writing.
| Server | Type | Push |
|---|---|---|
Apache |
Server |
Yes |
Nginx |
Server / Proxy / Cache |
No |
IIS |
Server |
Yes |
Jetty |
Server |
Yes |
h2o |
Server / Proxy |
Yes |
Squid |
Proxy / Cache |
Yes |
Caddy |
Sever |
No |
Varnish |
Proxy / Cache |
No |
Traffic Server |
Proxy / Cache |
Yes |
Content Delivery Networks (CDNs)
A Content Delivery Network (CDN) is a globally distributed network of reverse proxy servers deployed in multiple data centers. The goal of a CDN is to serve content to end users with high availability and high performance mostly by being closer to the average end user and therefore reducing the round-trip network latency. CDNs are a critical cog in the performance and scaling of the internet. They range from “free to use” for low-volume web properties up through enterprise class services that provide performance, reliability, and security to some of the largest web properties on the planet.
Most major CDNs support HTTP/2, though overall protocol support and functionality vary somewhat between them. Similar to looking at web servers, two of the most important areas to examine are support for push and how they handle priorities. Those items can make a world of difference when it comes to real-world performance.
Summary
It is remarkable how much support exists today for h2 considering how young the protocol is. The most popular web servers, proxies, and CDNs—as well as over 70% of all browsers in use—already fully support h2. On the other hand, h2 features like Server Push are still on earlier stages, and tuning around dependencies and priorities continues to evolve. We will undoubtedly see advances on these fronts in the near future.