Up and Running

Realistically, you have likely been experiencing HTTP/2 on a daily basis. Open a modern browser (e.g., Edge, Safari, Firefox, Chrome) and point it at a major website like Facebook, Instagram, or Twitter, and voila! you are using h2. Truth be told, this is likely anticlimactic and not the reason you are holding this book in your hands. Let’s get things up and running so that you can be running the next major website over h2.

There are two major steps to getting an h2 server up and running:

• Get and install a web server that speaks h2

• Get and install a TLS certificate so the browser will speak h2 with the server

Neither of these are trivial, but we are going to try to make it as simple as possible. There is a more exhaustive treatment of the subject in “Servers, Proxies, and Caches”, but hopefully you will be running an h2 server by the end of this chapter.

Get and Run Your First HTTP/2 Server

There are numerous choices for obtaining and running a web server that speaks HTTP/2. (“Servers, Proxies, and Caches” describes several options.) Our goal here is to be quick and simple, and for that we will look toward the nghttp2 package. nghttp2,³ developed by Tatsuhiro Tsujikawa, provides a number of useful tools for working with and debugging h2. For now, we are interested in the nghttpd tool.

There is more information on nghttp2 in “nghttp2”, but we’ll try to get you started here. Install nghttp2 via your favorite package manager or (for the brave) from the source. For example, on Ubuntu 16:

$ sudo apt-get install nghttp2

Once installed, with certificates in hand, run nghttpd as:

$ ./nghttpd -v -d <webroot> <port> <key> <cert>

where <webroot> is the path to your website, <port> is the port you want the server to listen to, and <key> and <cert> are paths to the key and certificate you generated. For example:

$ ./nghttpd -v -d /usr/local/www 8443 \
            /etc/letsencrypt/live/yoursite.com/privkey.pem \
            /etc/letsencrypt/live/yoursite.com/cert.pem

Pick a Browser

Finally, the reward for the hard work. Pick a modern browser and point it at your new server. See “Desktop Web Browsers” for a very comprehensive list of browsers that support HTTP/2. If you created a self-signed certificate, you should see a security warning. Confirm that it is complaining about the cert you created, and accept the warnings. You should see your website now.

And it is being served over h2!

Performance Challenges Today

Delivering a modern web page or web application is far from a trivial affair. With hundreds of objects per page, tens of domains, variability in the networks, and a wide range of device abilities, creating a consistent and fast web experience is a challenge. Understanding the steps involved in web page retrieval and rendering, as well as the challenges faced in those steps, is an important factor in creating something that does not get in the way of users interacting with your site. It also provides you with the insight needed to understand the motivations behind HTTP/2 and will allow you to evaluate the relative merits of its features.

The Anatomy of a Web Page Request

Before we dig in, it is important to have a baseline understanding of what we are trying to optimize; specifically, what goes on in the time between when users click a link in a web browser and the page being displayed on their screen. When a browser requests a web page, it goes through a repetitive process to get all of the information it needs to paint the page on the screen. It is easiest to think of this in two parts: the object fetching logic, and the page parsing/rendering logic. Let’s start with fetching. Figure 3-1 shows the components of this process.

Figure 3-1. Object request/fetching flowchart

Walking through the flowchart, we:

1. Put the URL to fetch in the queue

2. Resolve the IP address of the hostname in the URL (A)

3. Open a TCP connection to the host (B)

4. If it is an HTTPS request, initiate and finish a TLS handshake (C)

5. Send the request for the base page URL

Figure 3-2 describes receiving the response and rendering the page.

Figure 3-2. Object response/page rendering flowchart

Continuing on with our walk through the flowchart, we:

6. Receive the response

7. If this is the base HTML, parse it and trigger prioritized fetches for the objects on the page (A)

8. If the critical objects on a page have been received, start rendering (B)

9. As additional objects are received, continue to parse and render until done (C)

The preceding process needs to be repeated for every page click. It puts a strain on the network and device resources. Working to optimize or eliminate any of these steps is core to the art of web performance tuning.

The Problems with HTTP/1

HTTP/1 has gotten us to were we are today, but the demands of the modern web put focus on its design limitations. Following are some of the more significant issues the protocol faces, and consequently the core problems that HTTP/2 was designed to address.

Note

There is no such thing as HTTP/1. We are using that (and h1) as a shorthand for HTTP/1.0 (RFC 1945) and HTTP/1.1 (RFC 2616).

Head of line blocking

A browser rarely wants to get a single object from a particular host. More often it wants to get many objects at the same time. Think of a website that puts all of its images on a particular domain. HTTP/1 provides no mechanism to ask for those objects simultaneously. On a single connection it needs to send a request and then wait for a response before it can send another. h1 has a feature called pipelining that allows it to send a bunch of requests at once, but it will still receive the responses one after another in the order they were sent. Additionally, pipelining is plagued by various issues around interop and deployment that make its use impractical.

If any problems occur with any of those requests or responses, everything else gets blocked behind that request/response. This is referred to as head of line blocking. It can grind the transmission and rendering of a web page to a halt. To combat this, today’s browser will open up to six connections to a particular host and send a request down each connection. This achieves a type of parallelism, but each connection can still suffer from head of line blocking. In addition, it is not a good use of limited device resources; the following section explains why.

Inefficient use of TCP

TCP (Transmission Control Protocol) was designed to be conservative in its assumptions and fair to the different traffic uses on a network. Its congestion avoidance mechanisms are built to work on the poorest of networks and be relatively fair in the presence of competing demand. That is one of the reasons it has been as successful as it has—not necessarily because it is the fastest way to transmit data, but because it is one of the most reliable. Central to this is a concept called the congestion window. The congestion window is the number of TCP packets that the sender can transmit out before being acknowledged by the receiver. For example, if the congestion window was set to one, the sender would transmit one packet, and only when it gets the receiver’s acknowledgment of that packet would it send another.

Sending one packet at a time is not terribly efficient. TCP has a concept called Slow Start to determine what the correct congestion window should be for the current connection. The design goal for Slow Start is to allow a new connection to feel out the state of a network and avoid making an already congested network worse. It allows the sender to send an additional unacknowledged packet for every acknowledgment it receives. This means that on a new connection after the first acknowledgment, it could send two packets, and when those two are acknowledged, it could send four, and so on. This geometric growth soon reaches an upper limit defined in the protocol, at which point the connection will enter what is called the congestion avoidance phase. See Figure 3-4.

Figure 3-4. TCP congestion control (Reno algorithm)

It takes a few round-trips to get to the optimal congestion window size. And those few round-trips are precious time when it comes to addressing performance. Modern operating systems commonly use an initial congestion window size between 4 and 10 packets. When you consider a packet has a maximum size of around 1,460 bytes on the lower end, only 5,840 bytes can be sent before the sender needs to wait for acknowledgments. Today’s web pages are averaging around 2 MB of data, including the HTML and all dependent objects. In a perfect world and with some generous hand waving, that means it will take around nine round-trips to transmit the page. On top of that, since browsers are commonly opening six connections to a particular host, they need to do this for each connection.

Note

Traditional TCP implementations employ congestion control algorithms that use loss as a feedback mechanism. When a packet is determined to have been lost, the algorithm will react by shrinking the congestion window. This is similar to navigating a dark room by deciding to turn when your shin collides with the coffee table. In the presence of timeouts where an expected response does not come in time, it will even reset the congestion window completely and reenter slow start. Newer algorithms take other factors into account, such as latency to provide a better feedback mechanism.

As previously mentioned, because h1 does not support multiplexing, a browser will commonly open up six connections to a particular host. This means this congestion window dance needs to occur six times in parallel. TCP will make certain that those connections play nicely together, but it does not guarantee that their performance will be optimal.

Fat message headers

Though h1 provides a mechanism for the compression of the requested objects, there is no way to compress the message headers. Headers can really add up, and though on responses the ratio of header size to object size may be very small, the headers make up the majority (if not all) of the bytes on requests. With cookies it is not uncommon for request headers to grow to a few kilobytes in size.

According to the HTTP archives, as of late 2016, the median request header is around 460 bytes. For a common web page with 140 objects on it, that means the total size of the requests is around 63 KB. Hark back to our discussion on TCP congestion window management and it might take three or four round-trips just to send the requests for the objects. The cost of the network latency begins to pile up quickly. Also, since upload bandwidth is often constrained by the network, especially in mobile cases, the windows might never get large enough to begin with, causing even more round-trips.

A lack of header compression can also cause clients to hit bandwidth limits. This is especially true on low-bandwidth or highly congested links. A classic example is the “Stadium Effect.” When tens of thousands of people are in the same place at the same time (such as at a major sporting event), cellular bandwidth is quickly exhausted. Smaller requests with compressed headers would have an easier time in situations like that and put less overall load on the system.

Limited priorities

When a browser opens up multiple sockets (each of which suffers from head of line blocking) to a host and starts requesting objects, its options for indicating the priorities of those requests is limited: it either sends a request or not. Since some objects on a page are much more important than others, this forces even more serialization as the browser holds off on requesting objects to get the higher priority objects firsts. This can lead to having overall longer page downloads since the servers do not have the opportunity to work on the lower priority items as the browser potentially waits for processing on the higher priority items. It can also result in cases where a high-priority object is discovered, but due to how the browser processed the page it gets stuck behind lower priority items already being fetched.

Third-party objects

Though not specifically a problem with HTTP/1, we will round out the list with a growing performance issue. Much of what is requested on a modern web page is completely out of the control of the web server, what we refer to as third-party objects. Third-party object retrieval and processing commonly accounts for half of the time spent loading today’s web pages. Though there are many tricks to minimize the impact of third-party objects on a page’s performance, with that much content out of a web developer’s direct control there is a good chance that some of those objects will have poor performance and delay or block the rendering of the page. Any discussion of web performance would be incomplete without mentioning this problem. (But, spoiler: h2 has no magic bullet with dealing with it either.)

Web Performance Techniques

While working at Yahoo! in the early 2000s, Steve Souders and his team proposed and measured the impact of techniques aimed at making web pages load faster on client web browsers. This research led him to author two seminal books, High Performance Websites² and its follow-up Even Faster Websites,³ which laid the ground work for the science of web performance.

Since then, more studies have confirmed the direct impact of performance on the website owner’s bottom line, be it in terms of conversion rate, user engagement, or brand awareness. In 2010, Google added performance as one of the many parameters that come into play in its search engine to compute a given URL ranking.⁴ As the importance of a web presence keeps growing for most businesses, it has become critical for organizations to understand, measure, and optimize website performance.

As discussed earlier in this chapter, for the majority of web pages the bulk of the browser’s time is not spent serving the initial content (generally the HTML) from the hosting infrastructure, but rather fetching all the assets and rendering the page on the client. This fact is captured by the diagram in Figure 3-5.⁵

Figure 3-5. Timeline frontent and backend

As a result, there has been an increased emphasis among web developers on improving the performance by reducing the client’s network latency and optimizing page render time. Quite literally, time is money.

Best Practices for Web Performance

As previously noted, the web has changed significantly—even in just the past few years. The relatively recent prevalence of mobile devices, the advances in JavaScript frameworks, and the evolution of the use of HTML warrant revisiting the rules laid out in the books referenced earlier, and going over the latest optimization techniques observed in the field.

Optimize DNS lookups

Since a DNS lookup needs to take place before a connection can be made to a host, it is critical that this resolution process be as fast as possible. The following best practices are a good place to start:

• Limit the number of unique domains/hostnames. Of course, this is not always in your control; however, the relative performance impact of the number of unique hostnames will only grow when moving to HTTP/2.

• Ensure low resolution latencies. Understand the topology of your DNS serving infrastructure and perform regular resolution time measurements from all the locations where your end users are (you can achieve this by using synthetic/real user monitoring). If you decide to rely on a third-party provider, select one best suited to your needs, as the quality of the services they offer can differ widely.

• Leverage DNS prefetch⁶ from your initial HTML or response. This will start DNS resolution of specific hostnames on the page while the initial HTML is being downloaded and processed. For example, the following will prefetch a DNS resolition for ajax.googleapis.com:

<link rel="dns-prefetch" href="//ajax.googleapis.com">

These techniques will help ensure the fixed overhead of DNS is minimized.

Optimize TCP connections

As discussed earlier in this chapter, opening new connections can be a time-consuming process. If the connection uses TLS (as they all should), the overhead is even higher. Mitigations for this overhead include:

• Leverage preconnect,⁷ as it will remove connection times from the waterfall critical path by having the connection established before it is needed. For example:

<link rel="preconnect" href="//fonts.example.com" crossorigin>

• Use early termination. Leveraging a Content Delivery Network (CDN), connections can be terminated at the edges of the internet located close to the requesting client, and therefore can greatly minimize the round-trip latencies incurred by establishing a new connection. See “Content Delivery Networks (CDNs)” for more information on CDNs.

• Implement the latest TLS best practices⁸ for optimizing HTTPS.

If a lot of resources are requested from the same hostname, the client browsers will automatically open parallel connections to the server to avoid resource-fetching bottlenecks. You don’t have direct control over the number of parallel connections a client browser will open for a given hostname, although most browsers now support six or more.

Avoid redirects

Redirects usually trigger connections to additional hostnames, which means an extra connection needs to be established. On radio networks (think mobile phones), an additional redirect may add hundreds of ms in latency, which is detrimental to the user experience, and eventually detrimental to the business running the websites. The obvious solution is to remove redirects entirely, as more often than not there is no “good” justification for some of them. If they cannot be simply removed, then you have two options:

• Leverage a CDN to perform the redirect “in the cloud” on behalf of the client

• If it is a same host redirect, use rewrite rules on the web server to avoid the redirect and map the user to the needed resource

Oftentimes, redirects are used to help with the dark art of Search Engine Optimization (SEO) to avoid short-term search result pain or consequent backend information layout changes. In such cases, you have to decide whether the redirect cost is worth the SEO benefits. Sometimes tearing the Band-Aid off in one go is the best long-term solution.

Cache on the client

Nothing is faster than retrieving an asset from the local cache, as no network connection is involved. As the saying goes (or at least will starting now), the fastest request is the one you do not make. In addition, when the content is retrieved locally, no charge is incurred either by the ISP or the CDN provider. The directive that tells the browser how long to cache an object is called the Time to Live, or TTL. Finding the best TTL for a given resource is not a perfect science; however, the following tried-and-tested guidelines are a good starting point:

• So-called truly static content, like images or versioned content, can be cached forever on the client. Keep in mind, though, that even if the TTL is set to expire in a long time, say one month away, the client may have to fetch it from the origin before it expires due to premature eviction or cache wipes. The actual TTL will eventually depend on the device characteristics (specifically the amount of available disk storage for the cache) and the end user’s browsing habits and history.

• For CSS/JS and personalized objects, cache for about twice the median session time. This duration is long enough for most users to get the resources locally while navigating a website, and short enough to almost guarantee fresh content will be pulled from the network during the next navigation session.

• For other types of content, the ideal TTL will vary depending on the staleness threshold you are willing to live with for a given resource, so you’ll have to use your best judgment based on your requirements.

Client caching TTL can be set through the HTTP header “cache control” and the key “max-age” (in seconds), or the “expires” header.

Cache at the edge

Caching at the edge of the network provides a faster user experience and can offload the serving infrastructure from a great deal of traffic as all users can benefit from the shared cache in the cloud.

A resource, to be cacheable, must be:

• Shareable between multiple users, and

• Able to accept some level of staleness

Unlike client caching, items like personal information (user preferences, financial information, etc.) should never be cached at the edge since they cannot be shared. Similarly, assets that are very time sensitive, like stock tickers in a real-time trading application, should not be cached. This being said, everything else is cacheable, even if it’s only for a few seconds or minutes. For assets that don’t change very frequently but must be updated on very short notice, like breaking news, for instance, leverage the purging mechanisms offered by all major CDN vendors. This pattern is called “Hold ’til Told”: cache it forever until told not to.

Conditional caching

When the cache TTL expires, the client will initiate a request to the server. In many instances, though, the response will be identical to the cached copy and it would be a waste to re-download content that is already in cache. HTTP provides the ability to make conditional requests, which is effectively the client asking the server to, “Give me the object if it has changed, otherwise just tell me it is the same.” Using conditional requests can have a significant bandwidth and performance savings when an object may not often change, but making the freshest version of the object available quickly is important. To use conditional caching:

• Include the Last-Modified-Since HTTP header in the request. The server will only return the full content if the latest content has been updated after the date in the header, else it will return a 304 response, with a new timestamp “Date” in the response header.

• Include an entity tag, or ETag, with the request that uniquely identifies the object. The ETag is provided by the server in a header along with the object itself. The server will compare the current ETag with the one received from the request header, and if they match will only return a 304, else the full content.

Most web servers will honor these techniques for images and CSS/JS, but you should check that it is also in place for any other cached content.

Compression and minification

All textual content (HTML, JS, CSS, SVG, XML, JSON, fonts, etc.), can benefit from compression and minification. These two methods can be combined to dramatically reduce the size of the objects. Fewer bytes means fewer round-trips, which means less time spent.

Minification is a process for sucking all of the nonessential elements out of a text object. Generally these objects are written by humans in a manner that makes them easy to read and maintain. The browser does not care about readability, however, and removing that readability can save space. As a trivial example, consider the following HTML:

<html>
<head>
  <!-- Change the title as you see fit -->
  <title>My first web page</title>
</head>
<body>
<!-- Put your message of the day here -->
<p>Hello, World!</p>
</body>
</html>

This is a perfectly acceptable HTML page and will render perfectly (if boringly) in a browser. But there is information in it that the browser does not need, including comments, newlines, and spaces. A minified version could look like:

<html><head><title>My first web page</title></head><body>
<p>Hello, World!</p></body></html>

It is not as pretty nor as maintainable, but it takes half the number of bytes (92 versus 186).

Compression adds another layer of savings on top of minification. Compression takes objects and reduces their size in an algorithmic way that can be reversed without loss. A server will compress objects before they are sent and result in a 90% reduction in bytes on the wire. Common compression schemes include gzip and deflate, with a relative newcomer, Brotli, beginning to enter the scene.

Avoid blocking CSS/JS

CSS instructions will tell the client browser how and where to render content in the viewing area. As a consequence, clients will make sure to download all the CSS before painting the first pixel on the screen. While the browser pre-parser can be smart and fetch all the CSS it needs from the entire HTML early on, it is still a good practice to place all the CSS resource requests early in the HTML, in the head section of the document, and before any JS or images are fetched and processed.

JS will by default be fetched, parsed, and executed at the point it is located in the HTML, and will block the downloading and rendering of any resource past the said JS, until the browser is done with it. In some instances, it is desirable to have the downloading and execution of a given JS block the parsing and execution of the remainder of the HTML; for instance, when it instantiates a so-called tag-manager, or when it is critical that the JS be executed first to avoid references to nonexisting entities or race conditions.

However, most of the time this default blocking behavior incurs unnecessary delays and can even lead to single points of failure. To mitigate the potential negative effects of blocking JS, we recommend different strategies for both first-party content (that you control) and third-party content (that you don’t control):

• Revisit their usage periodically. Over time, it is likely the web page keeps downloading some JS that may no longer be needed, and removing it is the fastest and most effective resolution path!

• If the JS execution order is not critical and it must be run before the onload event triggers, then set the “async”⁹ attribute, as in:

  <script async src=”/js/myfile.js”>.

  This alone can improve your overall user experience tremendously by downloading the JS in parallel to the HTML parsing. Watch out for document.write directives as they would most likely break your pages, so test carefully!

• If the JS execution ordering is important and you can afford to run the scripts after the DOM is loaded, then use the “defer” attribute,¹⁰ as in:

  <script defer src="/js/myjs.js">

• If the JS is not critical to the initial view, then you should only fetch (and process) the JS after the onload event fires.

• You can consider fetching the JS through an iframe if you don’t want to delay the main onload event, as it’ll be processed separately from the main page. However, JS downloaded through an iframe may not have access to the main page elements.

If all this sounds a tad complicated, that’s because it is. There is no one-size-fits-all solution to this problem, and it can be hazardous to recommend a particular strategy without knowing the business imperatives and the full HTML context. The preceding list, though, is a good starting point to ensure that no JS is left blocking the rendering of the page without a valid reason.

Optimize images

The relative and absolute weight of images for the most popular websites keeps increasing over time. The chart¹¹ in Figure 3-6 shows the number of requests and bytes size per page over a five-year period.

Figure 3-6. Transfer size and number of requests from 2011–2016 (source: httparchive.com)

Since most modern websites are dominated by images, optimizing them can yield some of the largest performance benefits. Image optimizations all aim at delivering the fewest bytes to achieve a given visual quality. Many factors negatively influence this goal and ought to be addressed:

• Image “metadata,” like the subject location, timestamps, image dimension, and resolution are often captured with the binary information, and should be removed before serving to the clients (just ensure you don’t remove the copyright and ICC profile data). This quality-lossless process can be done at build time. For PNG images, it is not unusual to see gains of about 10% in size reduction. If you want to learn more about image optimizations, you can read High Performance Images (O’Reilly 2016) by Tim Kadlec, Colin Bendell, Mike McCall, Yoav Weiss, Nick Doyle, and Guy Podjarny.

• Image overloading refers to images that end up being scaled down by the browsers, either because the natural dimensions exceed the placement size in the browser viewport, or because the image resolution exceeds the device display’s capability. This scaling down not only wastes bandwidth, but also consumes significant CPU resources, which are sometimes in short supply for handheld devices. We commonly witness this effect in Responsive Web Design (RWD) sites, which indiscriminately serve the same images regardless of the rendering device. Figure 3-7 captures this over-download issue.

Figure 3-7. Average RWD bytes served per pixel. Source: http://goo.gl/6hOkQp

Techniques for mitigating image overloading involve serving images that are tailored (in terms of size and quality) to the user’s device, network conditions, and the expected visual quality.

Summary

HTTP/1.1 has bred a messy if not exciting world of performance optimizations and best practices. The contortions that the industry has gone through to eek out performance have been extraordinary. One of the goals of HTTP/2 is to make many (though not all) of these techniques obsolete. Regardless, understanding them and the reasons they work will provide a deeper understanding of the web and how it works.

Browser Support

As of publishing time, around 80% of web browsers in use support h2 to some degree.¹ This means a significant portion of people will start reaping the benefits of h2 as soon as it is turned on. Since the protocol negotiation is transparent to non-h2 supporting browsers, anyone who does not speak h2 will simply fall back to h1 and still access your infrastructure. (You did keep h1 support for now, right?)

Table 4-1 lists browsers and the latest version supporting HTTP/2.

Moving to TLS

Since all major browsers will only access h2 over TLS (i.e., an HTTPS request), that means you need to support TLS or you do not get to play. On top of that the TLS bar has been set quite high: you need to support at least TLS 1.2 with a specific set of ephemeral ciphers (see section 9.2 of RFC 7540 for details). Most modern security-conscious websites are already on the “TLS everywhere” bandwagon so it might just be a no-op for you, but if not, then there is an investment in time and resources to be made.

Much has been done over the past five years or so to make moving to and using TLS on your website as painless as possible, but it is still additional work. Items to consider are:

Understand your web server

Every web server has a slightly different way to configure its HTTPS settings.

Obtain a certificate

EV, OV, DV, CN, CSR, X509, SAN—there’s a whole new alphabet soup of acronyms to wade through. Getting a certificate for your site generally involves a number of steps, including the creation of a Certificate Signing Request, verifying your identity and the ownership of the names the certificate is for, and purchasing the certificate from a Certificate Authority (CA). There are many CAs to choose from. Organizations such as Let’s Encrypt² are working to make it simple, fast, and even free to get a certificate.

Protect your private key

Your certificate is only as secure as you make it. To safely run a site over TLS, you need to consider how and where your private keys are stored and who has access to them. Solutions range from using very expensive Hardware Security Modules (HSMs) through finger crossing and good practices. If TLS is new to you, this will be an important aspect of your operational plan.

Prepare for increased server load

There has been a lot of effort to make TLS as inexpensive as possible, but it is a game of three steps forward and two back. Optimizations in symmetric ciphers have helped enormously, but moving to ephemeral key exchange has done the opposite (though it has made everything a lot more secure). Here are some best practices to get you started:

• Keep connections open as long as possible. The most expensive part of TLS is the handshake at connection time. If you keep the connection open for as long as possible, you will reduce the number of handshakes needed.

• Use session tickets. Session tickets allow a client to reconnect to the server, reusing the computationally expensive crypto work done in a previous handshake.

• Use a chipset with built-in crypto support. Intel’s AES-NI³ instructions in its modern processors make very quick work of symmetric cryptography.

Keep up with changes

Web security is a dynamic world. There is a new vulnerability in servers and HTTPS seemingly every couple of months. It is important to keep up with the “latest and greatest” to ensure your work of yesterday is not useless tomorrow.

Regularly check your site

You should use tools such as Qualys Lab’s SSL Test⁴ to check your site’s TLS configuration.

These best practices are good things to internalize for anyone standing up a service dependent on TLS, but TLS is a rich subject that requires a significant investment in time to fully appreciate. Remember:

A little learning is a dangerous thing; Drink deep, or taste not the Pierian spring.

Alexander Pope

Undoing HTTP 1.1 “Optimizations”

Web developers have put a lot of effort into getting the most out of h1. Best practices have emerged such as concatenation, sharding, minification, cookieless domains, and spriting, to name a few. So you may be surprised to learn that some of these patterns become anti-patterns under h2. For example, concatenation (taking many CSS or JavaScript files and melding them into one) can potentially save a browser from making a bunch of requests. This was important with h1 where requests were expensive, but under h2 they are much more optimized. Skipping concatenation might mean very little request overhead and better fine-grained browser caching of the individual files.

Table 4-2 lists some common tricks used to optimize h1 requests, and notes considerations for h2.

Assuming you take the time to fully optimize your site for h2, a problem immediately surfaces: you still have 25% of your traffic coming from h1 clients and you want to maximize their performance as well. Making everyone happy is an onerous task. Careful analysis of your users might tell you which group you should optimize for. Alternatively, you can conditionally serve different content for your h1 and h2 users, or use a CDN or similar tool that can do the magic for you.⁶

Third Parties

We love them and hate them, but third-party content on our sites is a reality. The problem with third-party content is you do not directly control it and are therefore at the mercy of what those third parties do and do not support. If h2 works best when everything is on a single socket, where do third parties come in? Being realistic, they do not, and they can become a major drag on any potential performance gain you might see from HTTP/2. The headache becomes even bigger if the third parties you use do not have a TLS option. Research⁷ into the effect of third-party content on page performance has determined that, in many cases, it is one of the largest factors in a page’s performance.

So what to do about third-party content? Start by finding out the answers to the following questions:

• Does your third party have a TLS option?

• Do they have plans to support HTTP/2?

• Do they see minimizing performance impact as a critical element of what they provide?

If the answer to any of these questions is “no,” then there are two follow-up questions: “Are there other third parties that provide what I need?” and “Do I really need this third-party content, or could I live without?”

Supporting Older Clients

Some people do not like change. Their current browser works for them, and upgrading can be a nuisance. The problem is that these people may be your customers or users and you may not be ready to abandon them. Here is a real example. Microsoft ended support of Windows XP on April 8, 2014. This means that users on XP are falling farther and farther behind in terms of modern browsers and security. Needless to say, Internet Explorer on XP cannot talk h2, but more importantly, depending on how your TLS settings are configured and whether you have a clear-text fallback site, those users might not be able to even access your site over h1! On one hand this is the inevitability of progress, but on the other hand these could be important users and customers for you. This reality is yet one more item to consider before making the move to HTTP/2.

Summary

Though a transition to HTTP/2 is generally seen as a good thing and should be completely transparent to your website, there are certainly considerations that you need to take into account before flipping the switch. Even though many major websites have been running h2 for some time now, that does not mean it is a guaranteed win for your situation. It should be treated the same as any other significant change: test, test, test.

Layers of HTTP/2

HTTP/2 can be generalized into two parts: the framing layer, which is core to h2’s ability to multiplex, and the data or http layer, which contains the portion that is traditionally thought of as HTTP and its associated data. It is tempting to completely separate the two layers and think of them as totally independent things. Careful readers of the specification will note that there is a tension between the framing layer being a completely generic reusable construct, and being something that was designed to transport HTTP. For example, the specification starts out talking generically about endpoints and bidirectionality—something that would be perfect for many messaging applications—and then segues into talking about clients, servers, requests, and responses. When reading about the framing layer it is important to not lose sight of the fact that its purpose is to transport and communicate HTTP and nothing else.

Though the data layer is purposely designed to be backward compatible with HTTP/1.1, there are a number of aspects of h2 that will cause developers familiar with h1 and accustomed to reading the protocol on the wire to perform a double take:

Binary protocol

The h2 framing layer is a binary framed protocol. This makes for easy parsing by machines but causes eye strain when read by humans.

Header compression

As if a binary protocol were not enough, in h2 the headers are heavily compressed. This can have a dramatic effect on redundant bytes on the wire.

Multiplexed

When looking at a connection that is transporting h2 in your favorite debugging tool, requests and responses will be interwoven with each other.

Encrypted

To top it off, for the most part the data on the wire is encrypted, making reading on the fly more challenging.

We will explore each of these topics in the ensuing pages.

The Connection

The base element of any HTTP/2 session is the connection. This is defined as a TCP/IP socket initiated by the client, the entity that will send the HTTP requests. This is no different than h1; however, unlike h1, which is completely stateless, h2 bundles connection-level elements that all of the frames and streams that run over it adhere to. These include connection-level settings and the header table (which are both described in more detail later in this chapter). This implies a certain amount of overhead in each h2 connection that does not exist in earlier versions of the protocol. The intent is that the benefits of that overhead far outweigh the costs.

In order to doubly confirm to the server that the client endpoint speaks h2, the client sends a magic octet stream called the connection preface as the first data over the connection. This is primarily intended for the case where a client has upgraded from HTTP/1.1 over clear text. This stream in hex is:

0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a

Decoded as ASCII you get:

PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n

The point of this string is to cause an explicit error if by some chance the server (or some intermediary) did not end up being able to speak h2. The message is purposely formed to look like an h1 message. If a well-behaving h1 server receives this string, it will choke on the method (PRI) or the version (HTTP/2.0) and will return an error, allowing the h2 client to explicitly know something bad happened.

This magic string is then followed immediately by a SETTINGS frame. The server, to confirm its ability to speak h2, acknowledges the client’s SETTINGS frame and replies with a SETTINGS frame of its own (which is in turn acknowledged) and the world is considered good and h2 can start happening. Much work went into making certain this dance was as efficient as possible. Though it may seem on the surface that this is worryingly chatty, the client is allowed to start sending frames right away, assuming that the server’s SETTINGS frame is coming. If by chance the overly optimistic client receives something before the SETTINGS frame, the negotiation has failed and everyone gets to GOAWAY.

Frames

As mentioned before, HTTP/2 is a framed protocol. Framing is a method for wrapping all the important stuff in a way that makes it easy for consumers of the protocol to read, parse, and create. In contrast, h1 is not framed but is rather text delimited. Look at the following simple example:

  GET / HTTP/1.1  <crlf>
  Host: www.example.com <crlf>
  Connection: keep-alive <crlf>
  Accept: text/html,application/xhtml+xml,application/xml;q=0.9... <crlf>
  User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4)... <crlf>
  Accept-Encoding: gzip, deflate, sdch <crlf>
  Accept-Language: en-US,en;q=0.8 <crlf>
  Cookie: pfy_cbc_lb=p-browse-w; customerZipCode=99912|N; ltc=%20;... <crlf>
  <crlf>

Parsing something like this is not rocket science but it tends to be slow and error prone. You need to keep reading bytes until you get to a delimiter, <crlf> in this case, while also accounting for all of the less spec-compliant clients that just send <lf>. A state machine looks something like this:

loop
 while( ! CRLF )
  read bytes
 end while

 if first line
   parse line as the Request-Line
 else if line is empty
   break out of the loop # We are done
 else if line starts with non-whitespace
   parse the header line into a key/value pair
 else if line starts with space
   add the continuation header to the previous header
 end if
end loop

# Now go on to ready the request/response based on whatever was
# in the Transfer-encoding header and deal with all of the vagaries
# of browser bugs

Writing this code is very doable and has been done countless times. The problems with parsing an h1 request/response are:

• You can only have one request/response on the wire at a time. You have to parse until done.

• It is unclear how much memory the parsing will take. This leads to a host of questions: What buffer are you reading a line into? What happens if that line is too long? Should you grow and reallocate, or perhaps return a 400 error? These types of questions makes working in a memory efficient and fast manner challenging.

Frames, on the other hand, let the consumer know up front what they will be getting. Framed protocols in general, and h2 specifically, start with some known number of bytes that contain a length field for the overall size of the frame. Figure 5-1 shows what an HTTP/2 frame looks like.

Figure 5-1. HTTP/2 frame header

The first nine bytes (octets) are consistent for every frame. The consumer just needs to read those bytes and it knows precisely how many bytes to expect in the whole frame. See Table 5-1 for a description of each field.

Because everything is deterministic, the parsing logic is more like:

loop
 Read 9 bytes off the wire
 Length = the first three bytes
 Read the payload based on the length.
 Take the appropriate action based on the frame type.
end loop

This is much simpler to write and maintain. It also has a second extremely significant advantage over h1’s delimited format: with h1 you need to send a complete request or response before you can send another. Because of h2’s framing, requests and responses can be interwoven, or multiplexed. Multiplexing helps get around problems such as head of line blocking, which was described in “Head of line blocking”.

There are 10 different frame types in the protocol. Table 5-2 provides a brief description, and you are welcome to jump to Appendix A if you’d like to learn more about each one.

Streams

The HTTP/2 specification defines a stream as “an independent, bidirectional sequence of frames exchanged between the client and server within an HTTP/2 connection.” You can think of a stream as a series of frames making up an individual HTTP request/response pair on a connection. When a client wants to make a request it initiates a new stream. The server will then reply on that same stream. This is similar to the request/response flow of h1 with the important difference that because of the framing, multiple requests and responses can interleave together without one blocking another. The Stream Identifier (bytes 6–9 of the frame header) is what indicates which stream a frame belongs to.

After a client has established an h2 connection to the server, it starts a new stream by sending a HEADERS frame and potentially CONTINUATION frames if the headers need to span multiple frames (see “CONTINUATION Frames” for more on the CONTINUATIONS frame). This HEADERS frame generally contains the HTTP request or response, depending on the sender. Subsequent streams are initiated by sending a new HEADERS frame with an incremented Stream Identifier.

Messages

An HTTP message is a generic term for an HTTP request or response. As mentioned in the previous section, a stream is created to transport a pair of request/response messages. At a minimum a message consists of a HEADERS frame (which initiates the stream) and can additionally contain CONTINUATION and DATA frames, as well as additional HEADERS frames. Figure 5-2 is an example flow for a common GET request.

Figure 5-2. GET Request message and response message

And Figure 5-3 illustrates what the frames may look like for a POST message. Remember that the big difference between a POST and a GET is that a POST commonly includes data sent from the client.

Figure 5-3. POST request message and response message

Just like h1 requests/responses are split into the message headers and the message body, an h2 request/response is split into HEADERS and DATA frames.

For reference, HTTP messages are defined in HTTP/1.1’s RFC 7230.³

Here are a few notable difference between HTTP/1 and HTTP/2 messages:

Everything is a header

h1 split messages into request/status lines and headers. h2 did away with this distinction and rolled those lines into magic pseudo headers. For example, a sample request and response in HTTP/1.1 might look like:

GET / HTTP/1.1
Host: www.example.com
User-agent: Next-Great-h2-browser-1.0.0
Accept-Encoding: compress, gzip

HTTP/1.1 200 OK
Content-type: text/plain
Content-length: 2
...

And its HTTP/2 equivalent:

:scheme: https
:method: GET
:path: /
:authority: www.example.com
User-agent: Next-Great-h2-browser-1.0.0
Accept-Encoding: compress, gzip

:status: 200
content-type: text/plain

Note how the request and status lines are split out into the :scheme, :method, :path, and :status headers. Also note that this representation of the h2 headers is not what goes over the wire. Skip to “HEADERS Frame Fields” for a description of the HEADERS frame and “Header Compression (HPACK)” for more on that.

No chunked encoding

Who needs chunking in the world of frames? Chunking was used to piece out data to the peer without knowing the length ahead of time. With frames as part of the core protocol there is no need for it any longer.

No more 101 responses

The Switching Protocols response is a corner case of h1. Its most common use today is probably for upgrading to a WebSocket connection. ALPN provides more explicit protocol negotiation paths with less round-trip overhead.

Server Push

The best way to improve performance for a particular object is to have it positioned in the browser’s cache before it is even asked for. This is the goal of HTTP/2’s Server Push feature. Push gives the server the ability to send an object to a client proactively, presumably because it knows that it will be needed at a near future date. Allowing a server to arbitrarily send objects down to a client could cause problems, including performance and security issues, so it is not just a matter of doing it, but also a matter of doing it well.

Pushing an Object

When the server decides it wants to push an object (referred to as “pushing a response” in the RFC), it constructs a PUSH_PROMISE frame. There are a number of important attributes to this frame:

• The stream ID in the PUSH_PROMISE frame header is the stream ID of the request that the response is associated with. A pushed response is always related to a request the client has already sent. For example, if a browser asks for a base HTML page, a server would construct a PUSH_PROMISE on that request’s stream ID for a JavaScript object on that page.

• The PUSH_PROMISE frame has a header block that resembles what the client would send if it were to request the object itself. This gives the client a chance to sanity check what is about to be sent.

• The object that is being sent must be considered cacheable.

• The :method header field must be considered safe. Safe methods are those that are idempotent, which is a fancy way of saying ones that do not change any state. For example, a GET request is considered idempotent as it is (usually) just fetching an object, while a POST request is considered nonidempotent because it may change state on the server side.

• Ideally the PUSH_PROMISE should be sent down to the client before the client receives the DATA frames that might refer to the pushed object. If the server were to send the full HTML down before the PUSH_PROMISE is sent, for example, the client might have already sent a request for the object before the PUSH_PROMISE is received. The h2 protocol is robust enough to deal with this situation gracefully, but there is wasted effort and opportunity.

• The PUSH_PROMISE frame will indicate what Stream Identifier the future sent response will be on.

Note

When a client chooses Stream Identifiers, it starts with 1 and then increments by two for each new stream, thus using only odd numbers. When a server initiates a new stream indicated in a PUSH_PROMISE it starts with 2 and sticks to even numbers. This avoids a race condition between the client and server on stream IDs and makes it easy to tell what objects were pushed. Stream 0 is reserved for overall connection-level control messages and cannot be used for new streams.

If a client is unsatisfied with any of the preceding elements of a PUSH_PROMISE, it can reset the new stream (with an RST_STREAM) or send a PROTOCOL_ERROR (in a GOAWAY frame), depending on the reason for the refusal. A common case could be that it already has the object in cache. The error responses are reserved for protocol-level problems with the PUSH_PROMISE such as unsafe methods or sending a push when the client has indicated that it would not accept push in a SETTINGS frame. It is worth noting that the server can start the stream right after the promise is sent, so canceling an in-flight push still may result in a good deal of the resource being sent. Pushing the right things and only the right things is an important performance feature.

Assuming the client does not refuse the push, the server will go ahead and send the object on the new stream identifier indicated in the PUSH_PROMISE (Figure 5-4).

Figure 5-4. Server Push message processing

Header Compression (HPACK)

As mentioned in “Fat message headers”, the average web page requires around 140 requests and the median size of an HTTP request is 460 bytes, totaling 63 KB of requests. That can cause quite the delay in the best of circumstances, but when you think about a congested WiFi or a poor cellular connection, things can get downright painful. The real crime is that between those requests there are generally very few new and unique bytes. They are screaming out for some type of compression.

It was known from the start that header compression would be a key element of HTTP/2. But how should they be compressed? The browser world was just recovering from from the CRIME vulnerability in SPDY, which leveraged the deflate header compression in a creative way to decrypt the early encrypted frames, so that approach was out. There was a need for a CRIME-proof mechanism that would have similar compression ability as GZIP.

After much innovative deliberation, HPACK was proposed. HPACK is a table lookup compression scheme that leverages Huffman encoding to get compression rates that approach GZIP. The best way to understand how HPACK works is probably with a simplified example.

Downloading a web page and its dependent objects involves many requests. This number commonly reaches into the hundreds for a single web page. These requests tend to be extremely similar. Take, for example, the following two requests. They are two requests that are likely to follow one another in a browser session requesting a full web page. The few unique bytes are emphasized in bold.

Request #1:

:authority: www.akamai.com
:method: GET
:path: /
:scheme: https
accept: text/html,application/xhtml+xml
accept-language: en-US,en;q=0.8
cookie: last_page=286A7F3DE
upgrade-insecure-requests: 1
user-agent: Awesome H2/1.0

Request #2:

:authority: www.akamai.com
:method: GET
:path: /style.css
:scheme: https
accept: text/html,application/xhtml+xml
accept-language: en-US,en;q=0.8
cookie: last_page=*398AB8E8F
upgrade-insecure-requests: 1
user-agent: Awesome H2/1.0

You can see that much of the latter request is a repeat of the former. The first request is about 220 bytes, and the second about 230. But only 36 bytes are unique. Just sending those 36 bytes will mean roughly an 85% savings in bytes sent. At a high level that is how HPACK works.

The following is a contrived and simplified example to help explain what HPACK is doing. The reality is much more of a stark, dystopian landscape, and if you’re curious to learn more, you should read RFC 7541, “HPACK: Header Compression for HTTP/2.”⁴

Let’s assume a client sends the following headers, in order:

Header1: foo
Header2: bar
Header3: bat

When the client sends the request, it can indicate in the header block that a particular header and its value should be indexed. It would create a table like:

On the server side, when it reads the headers it would create the same table. On the next request when the client sends the request, if it sends the same headers it can simply send a header block like:

62 63 64

which the server will then look up and expand into the full headers that those indexes represent.

One of the major implications of this is that each connection is maintaining state, something that was nonexistent at the protocol level for h1.

The reality of HPACK is much more complicated. Here are a few tidbits for the curious:

• There are actually two tables maintained on each side of a request or response. One is a dynamic table created in a manner similar to the preceding example. One is a static table made up of the 61 most common header names and value combinations. For example, :method: GET is in the static table at index 2. The static table is defined to be 61 entries long, hence why the example started at 62.

• There are a number of controls on how items are indexed. These include:

  • Send literal values and indexes (as in the preceding example)

  • Send literal values and do not index them (for one-off or sensitive headers)

  • Send an indexed header name with a literal value and do not index it (for things like :path: /foo.html where the value is always changing)

  • Send an indexed header and value (as in the second request of the previous example)

• It uses integer compression with a packing scheme for extreme space efficiency.

• Leverages Huffman coding table for further compression of string literals.

Experiments show that HPACK works very well, especially on sites with large repeated headers (think: cookies). Since the bulk of the headers that are sent from request to request to a particular website are duplicated, HPACK’s table lookup mechanisms effectively eliminate those duplicate bytes from the communication.

On the Wire

Let’s look at an hHTTP/2 request and response and break it down. Note again, though we are spelling them out in text here for easy visual consumption, h2 on the wire is in a binary format and is compressed.

:authority: www.akamai.com
:method: GET
:path: /
:scheme: https
accept: text/html,application/xhtml+xml,...
accept-language: en-US,en;q=0.8
cookie: sidebar_collapsed=0; _mkto_trk=...
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (Macintosh;...

:status: 200
cache-control: max-age=600
content-encoding: gzip
content-type: text/html;charset=UTF-8
date: Tue, 31 May 2016 23:38:47 GMT
etag: "08c024491eb772547850bf157abb6c430-gzip"
expires: Tue, 31 May 2016 23:48:47 GMT
link: <https://c.go-mpulse.net>;rel=preconnect
set-cookie: ak_bmsc=8DEA673F92AC...
vary: Accept-Encoding, User-Agent
x-akamai-transformed: 9c 237807 0 pmb=mRUM,1
x-frame-options: SAMEORIGIN

<DATA Frames follow here>

$ nghttp -v -n --no-dep -w 14 -a -H "Header1: Foo" https://www.akamai.com

[  0.047] Connected
The negotiated protocol: h2 
[  0.164] send SETTINGS frame <length=12, flags=0x00, stream_id=0> 
          (niv=2)
          [SETTINGS_MAX_CONCURRENT_STREAMS(0x03):100]
          [SETTINGS_INITIAL_WINDOW_SIZE(0x04):16383]  

[  0.164] send HEADERS frame <length=45, flags=0x05, stream_id=1>
          ; END_STREAM | END_HEADERS 
          (padlen=0)
          ; Open new stream
          :method: GET
          :path: /
          :scheme: https
          :authority: www.akamai.com
          accept: */*
          accept-encoding: gzip, deflate
          user-agent: nghttp2/1.9.2
          header1: Foo 

[  0.171] recv SETTINGS frame <length=30, flags=0x00, stream_id=0> 
          (niv=5)
          [SETTINGS_HEADER_TABLE_SIZE(0x01):4096]
          [SETTINGS_MAX_CONCURRENT_STREAMS(0x03):100]
          [SETTINGS_INITIAL_WINDOW_SIZE(0x04):65535]
          [SETTINGS_MAX_FRAME_SIZE(0x05):16384]
          [SETTINGS_MAX_HEADER_LIST_SIZE(0x06):16384]
[  0.171] send SETTINGS frame <length=0, flags=0x01, stream_id=0> 
          ; ACK
          (niv=0)
[  0.197] recv SETTINGS frame <length=0, flags=0x01, stream_id=0>
          ; ACK
          (niv=0)

[  0.278] recv (stream_id=1, sensitive) :status: 200  
[  0.279] recv (stream_id=1, sensitive) last-modified: Wed, 01 Jun 2016 ...
[  0.279] recv (stream_id=1, sensitive) content-type: text/html;charset=UTF-8
[  0.279] recv (stream_id=1, sensitive) etag: "0265cc232654508d14d13deb...gzip"
[  0.279] recv (stream_id=1, sensitive) x-frame-options: SAMEORIGIN
[  0.279] recv (stream_id=1, sensitive) vary: Accept-Encoding, User-Agent
[  0.279] recv (stream_id=1, sensitive) x-akamai-transformed: 9 - 0 pmb=mRUM,1
[  0.279] recv (stream_id=1, sensitive) content-encoding: gzip
[  0.279] recv (stream_id=1, sensitive) expires: Wed, 01 Jun 2016 22:01:01 GMT
[  0.279] recv (stream_id=1, sensitive) date: Wed, 01 Jun 2016 22:01:01 GMT
[  0.279] recv (stream_id=1, sensitive) set-cookie: ak_bmsc=70A833EB...
[  0.279] recv HEADERS frame <length=458, flags=0x04, stream_id=1> 
          ; END_HEADERS
          (padlen=0)
          ; First response header

[  0.346] recv DATA frame <length=2771, flags=0x00, stream_id=1> 
[  0.346] recv DATA frame <length=4072, flags=0x00, stream_id=1>
[  0.346] recv DATA frame <length=4072, flags=0x00, stream_id=1>
[  0.348] recv DATA frame <length=4072, flags=0x00, stream_id=1>
[  0.348] recv DATA frame <length=1396, flags=0x00, stream_id=1>
[  0.348] send WINDOW_UPDATE frame <length=4, flags=0x00, stream_id=1>
          (window_size_increment=10915)

[  0.348] send HEADERS frame <length=39, flags=0x25, stream_id=15> 
          :path: /styles/screen.1462424759000.css
[  0.348] send HEADERS frame <length=31, flags=0x25, stream_id=17>
          :path: /styles/fonts--full.css
[  0.348] send HEADERS frame <length=45, flags=0x25, stream_id=19>
          :path: /images/favicons/favicon.ico?v=XBBK2PxW74

[  0.378] recv DATA frame <length=2676, flags=0x00, stream_id=1>
[  0.378] recv DATA frame <length=4072, flags=0x00, stream_id=1>
[  0.378] recv DATA frame <length=1445, flags=0x00, stream_id=1>
[  0.378] send WINDOW_UPDATE frame <length=4, flags=0x00, stream_id=13>
          (window_size_increment=12216)
[  0.379] recv HEADERS frame <length=164, flags=0x04, stream_id=17> 
[  0.379] recv DATA frame <length=175, flags=0x00, stream_id=17>
[  0.379] recv DATA frame <length=0, flags=0x01, stream_id=17>
          ; END_STREAM
[  0.380] recv DATA frame <length=2627, flags=0x00, stream_id=1>
[  0.380] recv DATA frame <length=95, flags=0x00, stream_id=1>
[  0.385] recv HEADERS frame <length=170, flags=0x04, stream_id=19> 
[  0.387] recv DATA frame <length=1615, flags=0x00, stream_id=19>
[  0.387] recv DATA frame <length=0, flags=0x01, stream_id=19>
          ; END_STREAM
[  0.389] recv HEADERS frame <length=166, flags=0x04, stream_id=15> 
[  0.390] recv DATA frame <length=2954, flags=0x00, stream_id=15>
[  0.390] recv DATA frame <length=1213, flags=0x00, stream_id=15>
[  0.390] send WINDOW_UPDATE frame <length=4, flags=0x00, stream_id=0>
          (window_size_increment=36114)
[  0.390] send WINDOW_UPDATE frame <length=4, flags=0x00, stream_id=15> 
          (window_size_increment=11098)
[  0.410] recv DATA frame <length=3977, flags=0x00, stream_id=1>
[  0.410] recv DATA frame <length=4072, flags=0x00, stream_id=1>
[  0.410] recv DATA frame <length=1589, flags=0x00, stream_id=1>   
[  0.410] recv DATA frame <length=0, flags=0x01, stream_id=1>
[  0.410] recv DATA frame <length=0, flags=0x01, stream_id=15>

[  0.457] send GOAWAY frame <length=8, flags=0x00, stream_id=0>
          (last_stream_id=0, error_code=NO_ERROR(0x00), opaque_data(0)=[])

Summary

The HTTP/2 protocol was many years in development and is full of design ideas, decisions, innovations, and compromises. This chapter has provided the basics for being able to look at a Wireshark dump (see “Wireshark”) of h2 and understand what is going on, and even find potential problems in your site’s use of the protocol (constantly changing cookie, perhaps?). For those who would like to go deeper, the ultimate resource is the RFC 7540 itself.⁷ It will provide every detail needed for the implementor, debugger, or masochist that lurks inside you.

Client Implementations

HTTP/2 is a young protocol and as is often the case, implementations, though spec compliant, can vary in subtle but important ways. For example, browsers like Chrome, Firefox, Safari, and Microsoft Edge all have different quirks that may affect a user’s experience on your site. The performance of the same website using different clients from within the same network connection can show considerable differences in page load times. Understanding these differences can be a critical part of tuning your site for the largest possible audience.

Akamai’s Foundry Team performed a study of HTTP/1.1 versus HTTP/2 performance with a goal of understanding how different browsers compare. It involved looking at billions of Real User Monitoring (RUM) measurements from real devices under real network conditions. The results showed differences between the browsers, and for the most part h2 requests were faster than h1 requests (Figure 6-1).

Figure 6-1. Percentage of URLs with a statistically significant performance improvement with HTTP/2

Mission accomplished, right? As it turns out, no. The study also showed that some URLs experienced a drop in performance when running h2 (see Figure 6-2 for details).

Figure 6-2. Percentage of URLs with a statistically significant drop in performance with HTTP/2

Why would h2 ever be slower? It is important to understand that the study was looking at individual requests, not full page loads. That means the only room for improvement lies in header compression, connection reuse, and an avoidance of head of line blocking. Items such as multiplexing and Server Push, which are more focused on improving the performance of a group of requests on a page, will not have an effect. Even so, many more URLs show a performance improvement with h2 versus a loss. The difference in the data highlights two important points: first, implementations matter, and second, not all requests will benefit from HTTP/2 under all circumstances.

Latency

In computer networks, latency is how much time it takes for a packet of data to get from one point to another. It is sometimes expressed as the time required for a packet to travel to the receiver and back to the sender, or Round-Trip Time (RTT), and it is generally measured in milliseconds (ms).

Many factors contribute to latency, but two of the more influential are the distance between the two points and the speed of the transmission medium used. For wired networks those mediums are generally made of optical fiber and/or copper wires, while mobile/wireless networks leverage radio waves. To determine the theoretical smallest latency between two points, you need to look at the speed of light in those mediums and the length of the lines between them. For example, the speed of light in optical fiber is about 2/3 the speed of light in a vacuum or around 200,000,000 meters per second. So if you stretched a fiber-optic cable straight from San Francisco to London, which is around 8500 km, you would have a lowest possible latency of about 43 ms. The only way to lower that latency would be to bring the endpoints closer together (or develop a faster medium).

Of course, if you check you will never actually see a latency measurement that low. First, the networks are not laid out in straight lines. Second, delays are introduced by the various gateways, routers, switches, cell towers, etc. (as well as your server application itself), that your data needs to pass through in order to get from A to B.

You can measure the latency between a client and a server easily by using the ping command tool, which is available in most operating systems.

Here’s how to use the ping command to measure the RTT to the Wikipedia website:

$ ping -c 4 www.wikipedia.org
PING www.wikipedia.org (208.80.154.224) 56(84) bytes of data.
64 bytes from text-lb.eqiad.wikimedia.org (...): icmp_req=1 ttl=50 time=70.4 ms
64 bytes from text-lb.eqiad.wikimedia.org (...): icmp_req=2 ttl=50 time=70.7 ms
64 bytes from text-lb.eqiad.wikimedia.org (...): icmp_req=3 ttl=50 time=70.5 ms
64 bytes from text-lb.eqiad.wikimedia.org (...): icmp_req=4 ttl=50 time=70.5 ms

--- www.wikipedia.org ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 70.492/70.571/70.741/0.284 ms

Table 6-1 provides sample average latency values, depending on the transport medium.

To measure the impact of latencies in h2, we configured a simple website that represents an average web page of the top 1000 websites in terms of size, in bytes, and number of objects. We then used a CDN (see “Content Delivery Networks (CDNs)”) in front of the site so that we could manually hit servers in different areas of the world to get a variety of “real” latencies. Using the free web-based performance testing tool Web Page Test (aka WPT; see “WebPagetest”) we loaded the page over h1 and h2 using Chrome and Firefox agents.

Table 6-2 shows the impact of latency on page load time when using h1 versus h2. The PLT times are the average of repeating the test 20 times over a period of 2 days; each test consists of 9 “First View” WPT runs.

One thing that should jump out from the data is that generally, as the distance from the origin increases and hence the latency, the performance of h2 relative to h1 improves.

Packet Loss

Packet loss happens when packets of data traveling across a computer network fail to reach their destination; this is usually caused by network congestion. Packet loss is measured as a percentage of packets lost with respect to the number of packets sent. High packet loss has a detrimental impact on pages delivered over h2, mostly because h2 opens a single TCP connection, and the TCP protocol reduces the TCP window size each time there is loss/congestion (see “Inefficient use of TCP”).

A recent study on HTTP/2 performance in cellular networks² by Montana State University and Akamai’s Foundry team analyzed the effect of packet loss on different types of content (small objects and larger objects).

The study found that:

• For web pages containing many small objects (365 x 2 KB), page load times over h2 are faster than over h1, because in the case of h1 (with six TCP connections) the server can only send six objects in parallel (due to head of line blocking), whereas in h2 many streams can be multiplexed over one connection. Further, as the network condition becomes poor, the PLTs increase for both h1 and h2—but the effect is more dramatic for h2. This is due to the single connection architecture. When that one connection is hit by loss, the whole works slows down (see the lefthand graph in Figure 6-4).

• For web pages containing a small number of larger objects (10 x 435 KB), h1 outperforms h2 across all network conditions. This possibly surprising finding is because of the initial congestion window (see Figure 3-4). With six connections opened, h1 effectively has six times the initial congestion window size as h2. That means it can get much more data faster early on in the session as the h2 connection window grows to its optimal size. There is ongoing work to address this limitation as it results in initial congestion windows being too small for h2, yet arguably too large for h1. And again, loss has a bigger effect on h2 than h1 (see the righthand graph in Figure 6-4).

• For web pages with a couple of extremely large objects, the differences disappear. The h2 initial congestion window disadvantage is mitigated by the length of the overall download, and its multiplexing does not really have an advantage any longer.

The majority of web pages fall into the first bucket (they contain many small objects) where h2 has the biggest advantage. This is no accident as it is precisely the use case the designers were optimizing for. Regardless, packet loss is h2’s Achilles heel.

Figure 6-4. HTTP/2 performance in cellular networks

Server Push

As discussed in “Server Push”, Server Push gives the server the ability to send an object to a client before the client requests it. Testing has shown push speeding up page render times by as much as 20% to 50% if used properly.

However, push can also waste bandwidth as the server may try to push objects that the client already has in the local cache, causing the client to receive extra bytes that it does not need. The client can send RST_STREAM frames in order to reject the server’s PUSH_PROMISE frames, but due to the timing of the frames the server generally will end up sending out the unwanted data regardless.

The true value of Server Push is achieved when pushing the critical CSS and JS objects needed for rendering a page the first time someone visits it. The server implementation needs to be smart enough to avoid push promises competing for bandwidth with the delivery of the base HTML page, however. Ideally, the server will push while it is processing the request for the base HTML page. At times, the server needs to do some backend work to generate the HTML. While it is thinking and the client is waiting, there is a perfect opportunity to start pushing down objects that the client will need. See Figure 6-5 for an illustration of how this can improve performance.

Figure 6-5. Push while processing

Time to First Byte (TTFB)

Time to First Byte (TTFB) is a measurement used as an indication of the responsiveness of a web server.

TTFB measures the duration from the client making an HTTP request to the first byte of the object being received by the client’s browser. This duration is a combination of the socket connection time, the time taken to send the HTTP request, and the time taken to get the first byte of the page. Although sometimes misunderstood as a post-DNS calculation, the original calculation of TTFB in networking always includes network latency in measuring the time it takes for a resource to begin loading.

In h1 the client requests one object at a time per hostname per connection, and the server sends those objects in order, one after the other. Once the client receives all the objects, it requests the next set of objects, and the server sends them, and this process continues until the client receives all the objects needed to render the page.

However, with h2 multiplexing, once the client has loaded the HTML, it will send a much higher number of simultaneous requests to the server as compared to h1. In aggregate these requests will generally return in a shorter amount of time than with h1, but since the clock starts sooner for the requested objects, the TTFB for those will be reported as higher. So, because the mechanics of how the protocols work are different, the meaning of TTFB changes from h1 to h2.

HTTP/2 does do a bit more work than h1, the goal of which is to gain better overall performance. Here are a few of the things h2 does that h1 doesn’t:

• Adjusting window sizes

• Building the dependency tree

• Maintaining static and dynamic tables of header information

• Compressing and decompressing headers

• Adjusting priorities (h2 allows a client to adjust the priority several times for a single request)

• Pushing additional streams not requested yet by the client

Figures 6-6 and 6-7 show a clear picture of the advantage of h2 over h1. To produce the results shown in those figures, the same page was loaded over h1 and h2. Though some of the metrics such as TTFB and “Time to Title” may be comparable or in h1’s favor, the overall experience is better with h2.

Figure 6-6. Timings h1 versus h2

Figure 6-7. Page rendering h1 versus h2

Third Parties

Many websites today use analytics, tracking, social, and advertising platforms that must be added to the website using snippets of code called third-party tags. Third-party tags are snippets of code provided by third-party vendors, and which generate browser calls to external third-party servers.

Numerous studies show that third-party calls can slow down your site, and even cause it to fail like in the case of blocking JavaScript. Pages that have a significant amount of third-party content showed no significant improvement in performance over h2. Third-party content can affect performance in general, but it affects h2 especially because:

• A third-party request is delivered over a different hostname, which causes a performance hit as the browser needs to resolve DNS, establish a TCP connection, and negotiate TLS.

• Due to being on a different hostname, the request won’t be able to benefit from h2 features like Server Push, dependencies, and priorities as it is reserved for objects on the same hostname only.

• You can’t control the performance of the third party or whether the resource is delivered over h2.

Another way to think of it is if third-party content accounts for half of your page’s load time, then h2 can only address half of any performance problems.

To test the impact of third-party calls on performance, we set up four simple HTML pages, each of them with just five images loading from a given hostname. The HTML body looks like this:

<html>
  <head lang="en">
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>What is your Ikigai?</title>
  </head>
  <body>
    <img src="https://akah1san.h2book.com/what.png">
    <img src="https://akah1san.h2book.com/is.png">
    <img src="https://akah1san.h2book.com/your.png">
    <img src="https://akah1san.h2book.com/ikigai.png">
    <img src="https://akah1san.h2book.com/question-mark.png">
  </body>
</html>

The hostname of the images is changed to control whether h1 or h2 is used. Test cases were created by varying the following parameters:

• Whether the base page is on h2 or h1

• Whether the objects are on h2 or h1

• Whether the hostnames for the objects are on the same certificate as the base page (hence allowing connection coalescing)

Although the results are pretty similar due to the small number of objects, we can see the images starting to show up 100 ms earlier when using h2 due to only having to open a single connection, as seen in Figure 6-8. The savings will increase as the latency to the server increases.

Figure 6-8. WPT filmstrip and timeline comparing loading a page that uses two hostname shards on h1 versus h2

We can see the impact on performance of opening more connections in h1 more clearly if we increase the number of domain shards to four with the same number of objects per domain. The HTML was modified from the previous example to repeat the same five images over three additional hostnames (note that all four hostnames are part of the same SAN certificate):

<html>
  <head lang="en">
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>What is your Ikigai?</title>
  </head>
  <body>
    <img src="https://akah2san.h2book.com/what.png">
    <img src="https://akah2san.h2book.com/is.png">
    <img src="https://akah2san.h2book.com/your.png">
    <img src="https://akah2san.h2book.com/ikigai.png">
    <img src="https://akah2san.h2book.com/question-mark.png">
    <img src="https://akah2san1.h2book.com/what.png">
    <img src="https://akah2san1.h2book.com/is.png">
    <img src="https://akah2san1.h2book.com/your.png">
    <img src="https://akah2san1.h2book.com/ikigai.png">
    <img src="https://akah2san1.h2book.com/question-mark.png">
    <img src="https://akah2san2.h2book.com/what.png">
    <img src="https://akah2san2.h2book.com/is.png">
    <img src="https://akah2san2.h2book.com/your.png">
    <img src="https://akah2san2.h2book.com/ikigai.png">
    <img src="https://akah2san2.h2book.com/question-mark.png">
    <img src="https://akah2san3.h2book.com/what.png">
    <img src="https://akah2san3.h2book.com/is.png">
    <img src="https://akah2san3.h2book.com/your.png">
    <img src="https://akah2san3.h2book.com/ikigai.png">
    <img src="https://akah2san3.h2book.com/question-mark.png">
  </body>
</html>

Figure 6-9 shows the results of loading the preceding web page. You can see that the page delivered over h2 loads roughly 25% faster.

Figure 6-9. WPT filmstrip comparing loading a page that uses four hostname shards on h1 versus h2

If we take a deeper look at the timeline for the page loaded over h1 (Figure 6-10), you will see most of connections loading the embedded images start with indicators of the initial connection and SSL handshake time. This shows the cost of opening multiple connections under h1.

Figure 6-10. WPT timeline comparing loading a page that uses four hostname shards using h1

On the other hand, when the page loads over h2 (Figure 6-11) only the first object is preceded by time spent doing connection and TLS establishment, meaning the rest of objects were sent over the same connection.

Figure 6-11. WPT timeline comparing loading a page that uses four hostname shards using h2

The exercises described in this section show that it is possible to migrate a website that uses domain sharding to h2 and achieve a single connection by means of grouping different hostnames under a common certificate, and benefiting from the connection coalescence implemented by browsers like Chrome and Firefox.

HTTP/2 Anti-Patterns

As seen in “Undoing HTTP 1.1 ‘Optimizations,’” some of the h1 performance patterns become anti-patterns in h2. This section reviews the more common of those workarounds and describes the performance implications of using them in h2.

<link rel="prefetch" href="/important.css">

Link: </important.css>; rel=prefetch

Real-World Performance

Theory and tests are great up to a point, but the IETF has a saying that “code speaks and data speaks louder.” Let’s look at a couple of real-world websites using HTTP/2 and see how they perform.

Study 1: www.facebook.com

The engineers at Facebook manage to get consistent improvements on the tests with h2 versus h1. It is evident that they spent some time tuning their delivery for h2. For example, they configured their servers to undo domain sharding on their home page when the client requests it over h2 to maximize the benefits of multiplexing on a single connection that using h2’s prioritization provides.

In terms of perceived performance, the main Facebook page over h2 started displaying 33% faster, a whopping 1.5 seconds earlier than over h1 (see Figure 6-12). Open http://goo.gl/m8GPYO to see this test.

Figure 6-12. h1 versus h2 for www.facebook.com on simulated 3G conditions

If you take a deeper look at the waterfalls in Figure 6-12, you will see the main reason for this difference is the single TCP connection of h2—on the h1 waterfall you can see the performance penalty of opening six extra connections. See the waterfall for h2 (http://goo.gl/w4vSLg) when compared to h1 (http://goo.gl/sWjL3M).

If you inspect the waterfall for the h2 test, you will see that most of the critical objects for rendering are loaded from the same hostname as the one delivering the HTML (www.facebook.com). In the h1 version, the HTML loads from www.facebook.com, but most of the stylesheets and JavaScript load from static.xx.fbcdn.net. Although in this case the performance penalty was caused by h1 opening extra TCP connections, if you click the h2 waterfall on the embedded objects, you will see WPT displaying dependencies and priorities like those listed in Table 6-4. (Note the WPT agent was Chrome. This is important, as at the time of writing, WPT displays stream information differently depending on the selected browser.)

Table 6-4. HTTP/2 dependencies and priorities (weights)

URL	Priority	HTTP/2 stream information (dependencies)
https://www.facebook.com/	VeryHigh	1, weight 256, depends on 0, EXCLUSIVE
https://www.facebook.com/rsrc.php/v3/yE/r/uqWZrDdEiFq.css	High	3, weight 220, depends on 0, EXCLUSIVE
https://www.facebook.com/rsrc.php/v3/yQ/r/g6_SC5FY4N_.css	High	5, weight 220, depends on 3, EXCLUSIVE
https://www.facebook.com/rsrc.php/v3/yD/r/og9BgEKiuOt.css	High	7, weight 220, depends on 5, EXCLUSIVE
https://www.facebook.com/rsrc.php/v3/yn/r/Fn0ud8qGK_Q.css	High	9, weight 220, depends on 7, EXCLUSIVE
https://www.facebook.com/rsrc.php/v3/yE/r/ONtm-h2cd4a.css	High	11, weight 220, depends on 9, EXCLUSIVE
https://www.facebook.com/rsrc.php/v3/yG/r/UxUWeZqSvQ7.css	High	13, weight 220, depends on 11, EXCLUSIVE
https://www.facebook.com/rsrc.php/v3/yh/r/sXFjO0knRDN.js	Medium	15, weight 183, depends on 13, EXCLUSIVE
https://www.facebook.com/rsrc.php/v3/yb/r/GsNJNwuI-UM.gif	VeryLow	17, weight 110, depends on 15, EXCLUSIVE
https://scontent.xx.fbcdn.net/t39.2365-6/851565_602269956474188_918638970_n.png	VeryLow	1, weight 110, depends on 0, EXCLUSIVE
https://scontent.xx.fbcdn.net/t39.2365-6/851585_216271631855613_2121533625_n.png	VeryLow	3, weight 110, depends on 0, EXCLUSIVE
https://scontent.xx.fbcdn.net/t39.2365-6/851558_160351450817973_1678868765_n.png	VeryLow	5, weight 110, depends on 3, EXCLUSIVE
https://www.facebook.com/rsrc.php/v2/ye/r/0qx-vnsuxPL.png	VeryLow	19, weight 110, depends on 0, EXCLUSIVE
…

Study 2: www.yahoo.com

HTTP/2 looks great on www.yahoo.com. The h2 page for yahoo.com starts being displayed in 4 seconds, while the h1 version starts displaying in 5.5 seconds (see Figure 6-13). Open http://goo.gl/eRUilp to see this test.

Figure 6-13. h1 versus h2 for www.yahoo.com on simulated 3G conditions in the US

Similar to the Facebook example, www.yahoo.com loads resources differently depending on whether the client negotiates h2 or h1. HTTP/2 delivers the HTML and assets both on www.yahoo.com, while when using h1, the HTML is delivered using www.yahoo.com and the assets using s.yimg.com. With h1 the browser opens six connections for the s.yimg.com hostname, which causes a considerable delay. Also the page elements load in a different order over h2, causing faster DOM complete and PLT, as seen in Figure 6-13. The Yahoo website showed positive improvements when loaded from WPT agents in the US. Interestingly, h1 loads much faster when using a WPT agent in Ireland. The h2 page starts being displayed in 7.5 seconds, while the h1 version starts displaying in 4.5 seconds. See https://goo.gl/GrySYa for details.

You can see in Figure 6-14 that it seems Yahoo’s home page in Ireland is generated slightly differently than its US counterpart. In this case the domain sharding has not been undone when loading the page over h2. Most of the embedded objects (like, for example, http://bit.ly/2pOgTiG) are delivered over a different domain than the one delivering the base HTML. The data shows that a couple of the runs took significantly longer with h2, which skewed the averages.

Figure 6-14. h1 versus h2 for www.yahoo.com on simulated 3G conditions in Ireland

But why was h2 slower? It could be dismissed with the wave of a hand and some statistical mumbo jumbo about small data sets and lack of significance, but that would be hiding an extremely important point: h2 will not always be faster in every case. The use of multiple connections (rather than one) and network conditions are the likely culprit in this particular case; a dropped packet could have thrown everything off. Other times the cause will be the makeup of the site. Or, in these early days of h2, it could also be undiscovered implementation bugs. Regardless, seeing performance drop in certain cases is to be expected, and it is almost always addressable.

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.

Mobile

Mobile browsers generally closely follow on the heels of their desktop brethren these days (Table 7-2).

Mobile App Support

Following the XCode update in June 2015,² 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 OkHttp³ 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.

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.

Web Browser Developer Tools

Most modern web browsers include web developer tools that are useful for debugging h2. The following sections are a few examples of how you can follow an h2 stream, identify h2 priorities and dependencies, and understand Server Push using Chrome and Firefox Developer Tools. Note that similar concepts can be applied to other popular browsers like Safari, Edge, or Opera.

Chrome Developer Tools

Over the past few years the Chrome browser has gained adoption among web developers in part due to the increasing functionality of its Web Developer tools.¹ Being familiar with their capabilities can provide you an advantage for solving your next technical snafu. Pull up the developer tool by choosing View → Developer → Developer Tools in the Chrome menu.

Net internals

Chrome net-internals² can be accessed by typing chrome://net-internals in Chrome’s address bar. These tools provide a look at the network data, including capturing/exporting/importing low-level network data, checking network and DNS logs, and visualizing network activity.

The net-internal tools can be used to capture HTTP/2 traffic, which is useful to illustrate some HTTP/2 concepts like:

• Stream IDs

• Priorities

• Dependencies

• Server-Push promises

• Session PINGs

Here are the steps to do a capture of HTTP/2 traffic:

1. Type chrome://net-internals in Chrome’s address bar.

2. Select HTTP/2 from the left sidebar.

3. Open a new tab and type the your favorite URL in the address bar.

4. Go back to the net-internals tab, where you will see a list of all the active sessions to hostnames that use the HTTP/2 protocol.

5. Click the ID link located on the right side of the hostname of the entered URL (see Figure 8-1).

Figure 8-1. Net-internals HTTP/2

6. The context will change to Events. Click the checkbox located on the left side of the hostname (Figure 8-2).

Figure 8-2. Net-internals Events

7. On the right side of this page you should see a capture of all the traffic between the web server and the client.

Let’s review some of the fields used in the capture. Each “event” starts with something like this:

t=timestamp [st=  milliseconds]    EVENT_TYPE

For example:

t=123808 [st=    1]    HTTP2_SESSION_SEND_HEADERS

• The first field “t” indicates the timestamp, in milliseconds, since the browser session started. For example, a value of 123808 indicates the HTTP/2 session has started 123.8 seconds after the browser’s session started.

• The second field “st” indicates the relative number of milliseconds since the HTTP/2 session started. For example, a value of 1 indicates the event happened 1 millisecond after the HTTP/2 was started.

• The third field shows the type of event recorded.

Note

Some of the Chrome h2 events correspond directly to h2 frame types. For example, HTTP2_SESSION_RECV_PUSH_PROMISE indicates a PUSH_PROMISE frame type, an HTTP2_SESSION_PING corresponds to a PING frame, and so on.

Let’s look at a sample capture to give you a feel for how to read them and to see what HTTP/2 information we can pull out:

t=791301 [st=   1]    HTTP2_SESSION_SEND_HEADERS 
                      --> exclusive = true
                      --> fin = true             
                      --> has_priority = true    
                      --> :method: GET           
                          :authority: akah2san.h2book.com
                          :scheme: https
                          :path: /
                          cache-control: max-age=0
                          upgrade-insecure-requests: 1
                          user-agent: Mozilla/5.0 (Macintosh; Intel Mac...
                          accept: text/html,application/xhtml+xml,...
                          accept-encoding: gzip, deflate, sdch, br
                          accept-language: en-US,en;q=0.8
                          cookie: [30 bytes were stripped]
                          if-none-match: "11168351bd3324ad3e43ed68195063c5:1464989325"
                      --> parent_stream_id = 0   
                      --> stream_id = 1          
                      --> weight = 256           
...

Here is the event information line as described previously

fin = true indicates that there is no additional head frame coming

This request has priorities set

The HTTP headers on the frame start here

The associated parent stream in stream 0

This stream has ID 1 (the first client request)

The relative weight for dependencies is 256

By looking at the net-internal events you can get a clear picture of precisely what is happening when and even look inside the protocol.

Note

If reading this output from Chrome makes you cross-eyed, you are not alone—and there is help. Rebecca Murphy created a brilliant little tool called chrome-http2-log-parser that, as she says, takes the HTTP/2 net-internals output and turns “it into something more useful.” We agree.

Server Push visualization

The Network tab of Chrome’s Developer Tools panel is useful for visually following the communication between the client and the server, while displaying a bunch of useful information in a table format like:

• Object’s name

• Object’s size

• Status code

• Priority

• Total load time

• Breakdown of load times within a timeline

Let’s look at an example. Load the web page https://akah2san.h2book.com/ (a simple page that loads over HTTP/2 and uses Server Push).

In the Network tab, you should see something like Figure 8-3.

Figure 8-3. Server Push timeline

The Network tab tells us that the HTML loads three stylesheets and four PNG images. From those seven objects, two of them (/resources/push.css and /resources/http2-banner-0614.png) are “pushed” to the client, while the other five load normally.

If we mouse over one of the objects in the waterfall on the righthand side of the pane, we will see a breakdown on the different stages while the object was fully loaded. Here is the explanation of the information displayed (see Figure 8-4):

• Connection Setup

  • Queueing: Time the request was postponed by the rendering engine or network layer.

  • Stalled: Time the request spent waiting before it could be sent.

• Request/Response

  • Request Sent: Time spent issuing the network request.

  • Waiting (TTFB): Time spent waiting for the initial response, also known as the Time To First Byte. This number captures the latency of a round-trip to the server in addition to the time spent waiting for the server to deliver the response.

  • Content Download: Time spent receiving the response data.

• Total time (labeled Explanation)

Figure 8-4. Server Push timeline h2.css

If we mouse over one of the objects that are pushed by the server, we will see the information shown in Figure 8-5:

• Server Push

  • Receiving Push: Time it takes to receive all the bytes for the pushed object

• Connection Setup

  • Queueing: Time the request was postponed by the rendering engine or network layer

• Request/Response

  • Reading Push: Time it takes for the browser to read the bytes pushed from the temporary cache

• Total time (labeled Explanation)

Figure 8-5. Server Push timeline push.css

Chrome session key logging

Both Chrome and Firefox provide the ability to log the TLS session key used for encrypting particular encrypted connections in the browser. It is incredibly useful for using external tools such as Wireshark (see “Wireshark”) to examine the traffic and look at the HTTP/2 frames. This functionality is triggered by setting the appropriate environment variable to the location you want the keys logged before you launch the browser. For example, on OS X you could do:

$ SSLKEYLOGFILE=~/keylog.txt
$ open /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome

Mozilla has a good description of this process written up at https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format.

cd c:\
set NSPR_LOG_MODULES=timestamp,nsHttp:5,nsSocketTransport:5,nsStreamPump:5, ^
   nsHostResolver:5
set NSPR_LOG_FILE=%TEMP%\firefox_http_log.txt
cd "Program Files (x86)\Mozilla Firefox"
.\firefox.exe

or MAC OS terminal:

export NSPR_LOG_MODULES=timestamp,nsHttp:5,nsSocketTransport:5, \
   nsStreamPump:5,nsHostResolver:5
export NSPR_LOG_FILE=~/Desktop/firefox_http_log.txt
cd /Applications/Firefox.app/Contents/MacOS
./firefox-bin

WebPagetest

WebPagetest is a free web-based performance monitoring tool for measuring various aspects of a website’s performance. It leverages server farms of web browsers distributed around the world, allowing you to test how your site performs under various different network conditions and browser types. Other features that are worth noting are:

• Ability to script a test in various ways to emulate a full browser session

• Saving filmstrips and videos of the web page loading for later comparison across runs

• Getting full packet traces for use in tools like Wireshark (see “Wireshark”)

• Adjusting various network parameters to limit bandwidth, increase latency, and introduce loss

It is a great way to see how your changes might perform in a wide variety of situations. It is a subject that requires much more detail than can be provided here, and for that detail we recommend checking out the book Using WebPagetest, by Rick Viscomi, Andy Davies, and Marcel Duran (O’Reilly) to learn more.

OpenSSL

OpenSSL⁵ is an open source implementation of the SSL and TLS protocols in the form of a software library (delivered over Apache and BSD license agreements) that allows applications to secure communications. This section focuses on the command-line tool also known as openssl, and how to use it to debug HTTP/2.

$ echo | openssl s_client -connect \
         akah2san.h2book.com:443 -servername akah2san.h2book.com \
           -alpn spdy/2,h2,h2-14 | grep ALPN
...
ALPN protocol: h2

nghttp2

nghttp2 is an implementation of HTTP/2 and its header compression algorithm HPACK in C.

The framing layer of HTTP/2 is implemented as a form of reusable C library. On top of that, nghttp2 provides the tools listed in Table 8-2.

This section focuses on the command-line client, known as nghttp.

$ nghttp -ns https://akah2san.h2book.com/hello-world.html
***** Statistics *****

Request timing:
  responseEnd: the  time  when  last  byte of  response  was  received
               relative to connectEnd
 requestStart: the time  just before  first byte  of request  was sent
               relative  to connectEnd.   If  '*' is  shown, this  was
               pushed by server.
      process: responseEnd - requestStart
         code: HTTP status code
         size: number  of  bytes  received as  response  body  without
               inflation.
          URI: request URI

see http://www.w3.org/TR/resource-timing/#processing-model

sorted by 'complete'

id  responseEnd requestStart  process code size request path
  2   +142.85ms *   +35.89ms 106.96ms  200   64 /resources/push.css
 13   +175.46ms       +128us 175.33ms  200  169 /hello-world.html

curl

curl⁶ is a software project originally authored by Daniel Stenberg providing a library (libcurl) and command-line tool (curl) for transferring data using various protocols. Though it uses the nghttp2 libraries for its HTTP/2 support, it is much more common than nghttp and different enough to merit its own slot in your debugging toolbox. As of the time of writing, curl was available in 261 packages, across 34 operating systems. You can use the curl download wizard⁷ to help find the right package for you.

$ curl -v --http2 https://akah2san.h2book.com/hello-world.html
*   Trying 2001:418:142b:19c::2a16...
* Connected to akah2san.h2book.com (2001:418:142b:19c::2a16) port 443 (#0)
* ALPN, offering h2                                
...
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:                              
*  subject: CN=akah2san.h2book.com
*  start date: Aug 12 17:59:00 2016 GMT
*  expire date: Nov 10 17:59:00 2016 GMT
*  subjectAltName: host "akah2san.h2book.com" matched cert's
     "akah2san.h2book.com"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
...
* Using Stream ID: 1 (easy handle 0x7f8d59003e00)  
> GET /hello-world.html HTTP/1.1
> Host: akah2san.h2book.com
> User-Agent: curl/7.49.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
* HTTP 1.0, assume close after body
< HTTP/2 200                                       
< server: Apache
< content-length: 169
...
<
<html>                                             
	<head lang="en">
		<meta http-equiv="Content-Type" content=
		  "text/html; charset=UTF-8">
		<title>Hello HTTP/2</title>
	</head>
	<body>Hello HTTP/2</body>
</html>
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1):

-w "Connection time: %{time_connect}\t1st byte transfer:
  %{time_starttransfer}\tDownload time: %{time_total}
    (sec)\tDownload Speed: %{speed_download} (bps)\n"

$ curl -v --http2 https://akah2san.h2book.com/hello-world.html -w \
       "Connection time: %{time_connect}\t                        \
       1st byte transfer: %{time_starttransfer}\t                 \
       Download time: %{time_total} (sec)\t                       \
       Download Speed: %{speed_download} (bps)\n"

...omitting a bunch of lines...
* Connection #0 to host akah2san.h2book.com left intact
Connection time: 0.054  1st byte transfer: 0.166  Download time: 0.166 (sec)
Download Speed: 1016.000 (bps)

h2i

h2i⁹ is an interactive HTTP/2 console debugger created by Brad Fitzpatrick, which allows sending “raw” HTTP/2 frames to the server. It will allow you to interact with an HTTP/2 server directly in much the same way you could do with h1 previously with tools like telnet or openssl.

h2i just requires indicating the hostname of a website that supports HTTP/2. Once you connect you will see an h2i> prompt, which allows sending HTTP/2 frames to the server.

The following example shows using the h2i client to request https://www.google.com/ (note that long lines are truncated with <cut> as needed):

$ h2i www.google.com
Connecting to www.google.com:443 ...
Connected to 172.217.5.100:443
Negotiated protocol "h2"
[FrameHeader SETTINGS len=18]
  [MAX_CONCURRENT_STREAMS = 100]
  [INITIAL_WINDOW_SIZE = 1048576]
  [MAX_HEADER_LIST_SIZE = 16384]
[FrameHeader WINDOW_UPDATE len=4]
  Window-Increment = 983041

h2i> headers
(as HTTP/1.1)> GET / HTTP/1.1
(as HTTP/1.1)> Host: www.google.com
(as HTTP/1.1)>
Opening Stream-ID 1:
 :authority = www.google.com
 :method = GET
 :path = /
 :scheme = https
[FrameHeader HEADERS flags=END_HEADERS stream=1 len=445]
  :status = "200"
  date = "Wed, 01 Mar 2017 00:08:06 GMT"
  expires = "-1"
  cache-control = "private, max-age=0"
  content-type = "text/html; charset=ISO-8859-1"
  p3p = "CP=\"This is not a P3P policy! See <cut>
  server = "gws"
  x-xss-protection = "1; mode=block"
  x-frame-options = "SAMEORIGIN"
  set-cookie = "NID=98=OOy2zBP3TY9GM37WXG9PFtN <cut>
  alt-svc = "quic=\":443\"; ma=2592000; v=\"35,34\""
  accept-ranges = "none"
  vary = "Accept-Encoding"
[FrameHeader DATA stream=1 len=16384]
  "<!doctype html><html itemscope=\"\" itemtype=\"http://schema.org/WebPage\"
   lang=\"en\"> <head><meta content=\"Search the world's information, including
   webpages, images, videos and more. Google has many special features to help
   <cut>
[FrameHeader PING len=8]
  Data = "\x00\x00\x00\x00\x00\x00\x00\x00"
h2i> quit

Wireshark

Wireshark¹⁰ is a popular network packet analyzer with a built-in understanding of hundreds of higher-level protocols, including HTTP/2. This means it can not only pull packets off the wire similar to venerable tools like tcpdump, it can reassemble those packets into the higher-level protocol you want to examine. It comes in the form of a GUI as well as a command-line tool called tshark.

The Wireshark website¹¹ has binaries for Windows and macOS for download and simple installation. In addition there are links to port and packages for another 20 or so various Unix/Linux flavors. It is well supported and easy to get.

Using Wireshark to look at h2 is made complicated by the fact that most all HTTP/2 is over TLS. This means in a Wireshark dump you will see TLS packets but the sniffer will not be able to see inside those packets. This is the general idea behind TLS, after all. In “Firefox session key logging” and “Chrome session key logging” we discussed how to get Firefox and Chrome to log the keying material so Wireshark can use it to look inside the TLS packet. That feature plus the HTTP/2 plug-in that currently ships with Wireshark make it possible to see precisely what is going on in an HTTP/2 session.

Using the tshark command you can get output like the following:

$ tshark port 443 and host www.example.com
Capturing on 'Wi-Fi'
  1   0.000000 TCP 78 65277→443 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
       WS=32 TSval=1610776917 TSecr=0 SACK_PERM=1
  2   0.096399 TCP 74 443→65277 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460
       SACK_PERM=1 TSval=2815107851 TSecr=1610776917 WS=128
  3   0.096489 TCP 66 65277→443 [ACK] Seq=1 Ack=1 Win=131744 Len=0
       TSval=1610777007 TSecr=2815107851
  4   0.096696 SSL 264 Client Hello
...
 33   0.386841 TCP 66 65277→443 [ACK] Seq=1043 Ack=7845 Win=128160
       Len=0 TSval=1610777288 TSecr=2815108131
 34   0.386842 TCP 66 [TCP Window Update] 65277→443 [ACK] Seq=1043
       Ack=7845 Win=131072 Len=0 TSval=1610777288 TSecr=2815108131
 35   0.386887 TCP 66 65277→443 [ACK] Seq=1043 Ack=9126 Win=129760
       Len=0 TSval=1610777288 TSecr=2815108131
 36   0.436502 HTTP2 143 HEADERS
 37   0.535887 TCP 1514 [TCP segment of a reassembled PDU]
 38   0.536800 HTTP2 1024 HEADERS, DATA
 39   0.536868 TCP 66 65277→443 [ACK] Seq=1120 Ack=11532
       Win=130112 Len=0 TSval=1610777433 TSecr=2815108271

This example dump gives you visibility into TCP, TLS, and HTTP/2. Other options¹² allow you to dig deep into all of those items to see precisely what is going on.

Summary

You can use the tools described in this chapter for quick tasks like verifying if your existing certificate includes the required h2 ciphers, low-level debugging of the HTTP communication, or setting up a simple h2 web server for more advanced testing. Knowing how to do these types of things will help you learn more about h2 and aid you in the transition of your website to the h2 protocol.

TCP or UDP?

This is a debate you hear a lot these days, and though the question is valid it is also misleading. We discussed TCP in Chapter 3 when looking at the underlying motivations behind h2. To quickly recap, TCP is an IP datagram–based protocol that provides an agreed concept of a connection, reliability, and congestion control. These are the elements that allow TCP to be dependable and work consistently in a crowded internet. UDP (User Datagram Protocol), on the other hand, is much more basic. In this protocol datagrams (packets) are individual with no relation to any other UDP packet. There is no “connection,” no guarantee of delivery, and no ability to adapt to different network conditions. It is perfect for building simple protocols like DNS that have small individual queries and small responses.

In order to make an application based on UDP be something that our next generation web can be built upon, we need to implement the idea of a connection, introduce reliability, and have some sort of congestion control. In other words, we need to reimplement much of what TCP already give us. So, if at the packet level these two protocols are mostly similar, and given the fact that in order for UDP to be useful for browsers we need to reimplement much if not all of the TCP stack, what is the motivation for a move from TCP to UDP? Why not just make changes to TCP and be done with it?

The answer has to do with where TCP is implemented. Most modern operating systems have their TCP stack in the kernel. It was long ago placed there for performance reasons. Changing the kernel is difficult, however. It is not something that a developer of the next great browser can generally do on her own. Kernel changes come from the operating system vendor and require an OS update to take effect. Since updating an operating system is a very high-overhead task when compared to upgrading your browser, the inertia of such a change is large enough to make such changes few and far between. When you consider that in order to work properly, much of the infrastructure on the internet would have to be updated as well, you can see that though revising TCP may be possible, it is not terribly practical.

So why would someone want to essentially reimplement the TCP stack in user space based on UDP? The short answer is control. By moving the TCP stack into user space—for example, in the browser itself—the developer gets unprecedented control over the network stack and can rapidly develop, deploy, and iterate new versions as quickly as people can auto-update their browsers. This is the experimenter’s dream, and is the crux of the TCP versus UDP debate.

Thus the question should not be “TCP or UDP?” but rather “Kernel Space or User Space?” Keep that in mind the next time you hear someone extolling the virtues of one protocol over the other.

QUIC

Now that we have that debate out of the way we can intelligently discuss some of the technologies that are on the horizon, and even in use today.

One of the weaknesses of HTTP/2 is its reliance on popular TCP implementations. As discussed in “Inefficient use of TCP”, TCP connections are stuck in the cage of TCP slow start, congestion avoidance, and irrational reaction to missing packets. By placing all of the requests for all of the objects of a page on a single connection, you get the benefits of multiplexing, but you are vulnerable to the head of line blocking that can occur at the TCP level. A single TCP connection is still a great thing, but all great things can be improved upon.

QUIC, developed by Google, is an acronym for Quick UDP Internet Connection. QUIC takes HTTP/2, places it atop a user space resident UDP-based transport protocol (see “TCP or UDP?”), and folds in crypto, authentication, and other features to form a complete bundle of protocol goodness. Here is a description from the draft version of the RFC¹:

QUIC provides multiplexing and flow control equivalent to HTTP/2, security equivalent to TLS, and connection semantics, reliability, and congestion control equivalent to TCP.

That is quite an impressive list. HTTP/2 put great effort into keeping the underlying TCP mechanism in place. QUIC leaves those constraints behind and makes a good thing better. Newton summed up this type of progress in 1676 when he said:

If I have seen further, it is by standing on the shoulders of giants.

Sir Isaac Newton

QUIC has a number of important features that will help it pick up where h2 leaves off:

Out of order packet processing

With h2 if a packet is lost on a TCP stream, the entire connection stalls until the packet is resent and received. QUIC will allow the application layer to continue to receive and process packets from streams that were unaffected by the loss.

Flexible congestion control

QUIC’s congestion control is designed to be pluggable. This will make it extremely easy to experiment with new algorithms or even swap in different algorithms depending on real-time conditions.

Low connection establishment overhead

QUIC’s goal is to have a zero round-trip time (0-RTT) connection establishment, including encryption and authentication. Using today’s technologies (TCP and TLS 1.2) the minimum number of round-trips to establish a connection is three.

Authentication of transport details

TCP is vulnerable today to injection attacks and similar concepts that take advantage of its trusting nature. QUIC will authenticate the packet header, making such attacks significantly more difficult (if not impossible).

Connection migration

In a mobile and moving world, IP addresses may change during a long-lived connection. In a TCP world the connection will need to be broken down and reestablished. QUIC endeavors to make it possible to preserve connection semantics even when confronted by a moving client.

Though the RFC is not complete, a version of QUIC is available today in Chrome and many Google properties so you do not need to wait to try it out.

TLS 1.3

TLS (Transport Layer Security) is the Encryption and Authentication layer that HTTP/2 requires. Though it may feel that we only just moved to TLS 1.2, it is actually already approaching a decade since the RFC was published.² TLS 1.3 is currently in the works and as of March 2017 was at draft 19 of the RFC.³ It represents a significant cleanup of TLS 1.2 and most importantly for our discussion addresses some performance-enhancing features while it shores up the protocol.

The most significant proposed improvement in TLS 1.3 is a 1-RTT for new connection (down from 3-RTT), and a 0-RTT for resumed connections. This trend can be summarized as “Round-trips are bad, let’s eliminate them.”

HTTP/3?

Will there be an HTTP/3? If so, what will it be?

The answer to the first question is undoubtedly, “yes.” We are in a period of rapid experimentation and implementation of web protocols. Speed matters and has a direct effect on getting and retaining users on a website, which in turn has a direct effect on a site accomplishing its goals whether they be revenue generation, information dissemination, or human connection. In addition, implementors, web operators, and others are increasingly aware that though the internet may be a global phenomenon, internet access and quality vary greatly. Not everyone has a low-latency, high-bandwidth connection. That is all a grandiose way of saying that performance matters, and we will continue to work to approach the speed-of-light limitations of communications.

What will HTTP/3 be like is the more interesting question. HTTP/2 was inspired by the concepts in SPDY and used it as a starting point for its first draft. Will HTTP/3 do a similar thing with QUIC or will something new come along in the meantime that is better by all measures? We cannot say at this point, but it is fair to say that whatever coalesces into h3 will be faster, more reliable, more secure, and more resilient in more diverse internet conditions.

Summary

HTTP/2 is new. What that means is that the fun stuff is likely still to be discovered. We spent 20 years optimizing for HTTP/1—in fact, we built an industry around it. Some of the things that will feed into HTTP/3 are likely known, but it is probable that the best ideas are still out there to be discovered. Get out there and start using h2, push the boundaries, break things, learn—and when you are done, share. That is where HTTP/3 will come from.

Up and Running

Realistically, you have likely been experiencing HTTP/2 on a daily basis. Open a modern browser (e.g., Edge, Safari, Firefox, Chrome) and point it at a major website like Facebook, Instagram, or Twitter, and voila! you are using h2. Truth be told, this is likely anticlimactic and not the reason you are holding this book in your hands. Let’s get things up and running so that you can be running the next major website over h2.

There are two major steps to getting an h2 server up and running:

• Get and install a web server that speaks h2

• Get and install a TLS certificate so the browser will speak h2 with the server

Neither of these are trivial, but we are going to try to make it as simple as possible. There is a more exhaustive treatment of the subject in “Servers, Proxies, and Caches”, but hopefully you will be running an h2 server by the end of this chapter.

Get and Run Your First HTTP/2 Server

There are numerous choices for obtaining and running a web server that speaks HTTP/2. (“Servers, Proxies, and Caches” describes several options.) Our goal here is to be quick and simple, and for that we will look toward the nghttp2 package. nghttp2,³ developed by Tatsuhiro Tsujikawa, provides a number of useful tools for working with and debugging h2. For now, we are interested in the nghttpd tool.

There is more information on nghttp2 in “nghttp2”, but we’ll try to get you started here. Install nghttp2 via your favorite package manager or (for the brave) from the source. For example, on Ubuntu 16:

$ sudo apt-get install nghttp2

Once installed, with certificates in hand, run nghttpd as:

$ ./nghttpd -v -d <webroot> <port> <key> <cert>

where <webroot> is the path to your website, <port> is the port you want the server to listen to, and <key> and <cert> are paths to the key and certificate you generated. For example:

$ ./nghttpd -v -d /usr/local/www 8443 \
            /etc/letsencrypt/live/yoursite.com/privkey.pem \
            /etc/letsencrypt/live/yoursite.com/cert.pem

Pick a Browser

Finally, the reward for the hard work. Pick a modern browser and point it at your new server. See “Desktop Web Browsers” for a very comprehensive list of browsers that support HTTP/2. If you created a self-signed certificate, you should see a security warning. Confirm that it is complaining about the cert you created, and accept the warnings. You should see your website now.

And it is being served over h2!

Performance Challenges Today

Delivering a modern web page or web application is far from a trivial affair. With hundreds of objects per page, tens of domains, variability in the networks, and a wide range of device abilities, creating a consistent and fast web experience is a challenge. Understanding the steps involved in web page retrieval and rendering, as well as the challenges faced in those steps, is an important factor in creating something that does not get in the way of users interacting with your site. It also provides you with the insight needed to understand the motivations behind HTTP/2 and will allow you to evaluate the relative merits of its features.

The Anatomy of a Web Page Request

Before we dig in, it is important to have a baseline understanding of what we are trying to optimize; specifically, what goes on in the time between when users click a link in a web browser and the page being displayed on their screen. When a browser requests a web page, it goes through a repetitive process to get all of the information it needs to paint the page on the screen. It is easiest to think of this in two parts: the object fetching logic, and the page parsing/rendering logic. Let’s start with fetching. Figure 3-1 shows the components of this process.

Figure 3-1. Object request/fetching flowchart

Walking through the flowchart, we:

1. Put the URL to fetch in the queue

2. Resolve the IP address of the hostname in the URL (A)

3. Open a TCP connection to the host (B)

4. If it is an HTTPS request, initiate and finish a TLS handshake (C)

5. Send the request for the base page URL

Figure 3-2 describes receiving the response and rendering the page.

Figure 3-2. Object response/page rendering flowchart

Continuing on with our walk through the flowchart, we:

6. Receive the response

7. If this is the base HTML, parse it and trigger prioritized fetches for the objects on the page (A)

8. If the critical objects on a page have been received, start rendering (B)

9. As additional objects are received, continue to parse and render until done (C)

The preceding process needs to be repeated for every page click. It puts a strain on the network and device resources. Working to optimize or eliminate any of these steps is core to the art of web performance tuning.

The Problems with HTTP/1

HTTP/1 has gotten us to were we are today, but the demands of the modern web put focus on its design limitations. Following are some of the more significant issues the protocol faces, and consequently the core problems that HTTP/2 was designed to address.

Note

There is no such thing as HTTP/1. We are using that (and h1) as a shorthand for HTTP/1.0 (RFC 1945) and HTTP/1.1 (RFC 2616).

Head of line blocking

A browser rarely wants to get a single object from a particular host. More often it wants to get many objects at the same time. Think of a website that puts all of its images on a particular domain. HTTP/1 provides no mechanism to ask for those objects simultaneously. On a single connection it needs to send a request and then wait for a response before it can send another. h1 has a feature called pipelining that allows it to send a bunch of requests at once, but it will still receive the responses one after another in the order they were sent. Additionally, pipelining is plagued by various issues around interop and deployment that make its use impractical.

If any problems occur with any of those requests or responses, everything else gets blocked behind that request/response. This is referred to as head of line blocking. It can grind the transmission and rendering of a web page to a halt. To combat this, today’s browser will open up to six connections to a particular host and send a request down each connection. This achieves a type of parallelism, but each connection can still suffer from head of line blocking. In addition, it is not a good use of limited device resources; the following section explains why.

Inefficient use of TCP

TCP (Transmission Control Protocol) was designed to be conservative in its assumptions and fair to the different traffic uses on a network. Its congestion avoidance mechanisms are built to work on the poorest of networks and be relatively fair in the presence of competing demand. That is one of the reasons it has been as successful as it has—not necessarily because it is the fastest way to transmit data, but because it is one of the most reliable. Central to this is a concept called the congestion window. The congestion window is the number of TCP packets that the sender can transmit out before being acknowledged by the receiver. For example, if the congestion window was set to one, the sender would transmit one packet, and only when it gets the receiver’s acknowledgment of that packet would it send another.

Sending one packet at a time is not terribly efficient. TCP has a concept called Slow Start to determine what the correct congestion window should be for the current connection. The design goal for Slow Start is to allow a new connection to feel out the state of a network and avoid making an already congested network worse. It allows the sender to send an additional unacknowledged packet for every acknowledgment it receives. This means that on a new connection after the first acknowledgment, it could send two packets, and when those two are acknowledged, it could send four, and so on. This geometric growth soon reaches an upper limit defined in the protocol, at which point the connection will enter what is called the congestion avoidance phase. See Figure 3-4.

Figure 3-4. TCP congestion control (Reno algorithm)

It takes a few round-trips to get to the optimal congestion window size. And those few round-trips are precious time when it comes to addressing performance. Modern operating systems commonly use an initial congestion window size between 4 and 10 packets. When you consider a packet has a maximum size of around 1,460 bytes on the lower end, only 5,840 bytes can be sent before the sender needs to wait for acknowledgments. Today’s web pages are averaging around 2 MB of data, including the HTML and all dependent objects. In a perfect world and with some generous hand waving, that means it will take around nine round-trips to transmit the page. On top of that, since browsers are commonly opening six connections to a particular host, they need to do this for each connection.

Note

Traditional TCP implementations employ congestion control algorithms that use loss as a feedback mechanism. When a packet is determined to have been lost, the algorithm will react by shrinking the congestion window. This is similar to navigating a dark room by deciding to turn when your shin collides with the coffee table. In the presence of timeouts where an expected response does not come in time, it will even reset the congestion window completely and reenter slow start. Newer algorithms take other factors into account, such as latency to provide a better feedback mechanism.

As previously mentioned, because h1 does not support multiplexing, a browser will commonly open up six connections to a particular host. This means this congestion window dance needs to occur six times in parallel. TCP will make certain that those connections play nicely together, but it does not guarantee that their performance will be optimal.

Fat message headers

Though h1 provides a mechanism for the compression of the requested objects, there is no way to compress the message headers. Headers can really add up, and though on responses the ratio of header size to object size may be very small, the headers make up the majority (if not all) of the bytes on requests. With cookies it is not uncommon for request headers to grow to a few kilobytes in size.

According to the HTTP archives, as of late 2016, the median request header is around 460 bytes. For a common web page with 140 objects on it, that means the total size of the requests is around 63 KB. Hark back to our discussion on TCP congestion window management and it might take three or four round-trips just to send the requests for the objects. The cost of the network latency begins to pile up quickly. Also, since upload bandwidth is often constrained by the network, especially in mobile cases, the windows might never get large enough to begin with, causing even more round-trips.

A lack of header compression can also cause clients to hit bandwidth limits. This is especially true on low-bandwidth or highly congested links. A classic example is the “Stadium Effect.” When tens of thousands of people are in the same place at the same time (such as at a major sporting event), cellular bandwidth is quickly exhausted. Smaller requests with compressed headers would have an easier time in situations like that and put less overall load on the system.

Limited priorities

When a browser opens up multiple sockets (each of which suffers from head of line blocking) to a host and starts requesting objects, its options for indicating the priorities of those requests is limited: it either sends a request or not. Since some objects on a page are much more important than others, this forces even more serialization as the browser holds off on requesting objects to get the higher priority objects firsts. This can lead to having overall longer page downloads since the servers do not have the opportunity to work on the lower priority items as the browser potentially waits for processing on the higher priority items. It can also result in cases where a high-priority object is discovered, but due to how the browser processed the page it gets stuck behind lower priority items already being fetched.

Third-party objects

Though not specifically a problem with HTTP/1, we will round out the list with a growing performance issue. Much of what is requested on a modern web page is completely out of the control of the web server, what we refer to as third-party objects. Third-party object retrieval and processing commonly accounts for half of the time spent loading today’s web pages. Though there are many tricks to minimize the impact of third-party objects on a page’s performance, with that much content out of a web developer’s direct control there is a good chance that some of those objects will have poor performance and delay or block the rendering of the page. Any discussion of web performance would be incomplete without mentioning this problem. (But, spoiler: h2 has no magic bullet with dealing with it either.)

Web Performance Techniques

While working at Yahoo! in the early 2000s, Steve Souders and his team proposed and measured the impact of techniques aimed at making web pages load faster on client web browsers. This research led him to author two seminal books, High Performance Websites² and its follow-up Even Faster Websites,³ which laid the ground work for the science of web performance.

Since then, more studies have confirmed the direct impact of performance on the website owner’s bottom line, be it in terms of conversion rate, user engagement, or brand awareness. In 2010, Google added performance as one of the many parameters that come into play in its search engine to compute a given URL ranking.⁴ As the importance of a web presence keeps growing for most businesses, it has become critical for organizations to understand, measure, and optimize website performance.

As discussed earlier in this chapter, for the majority of web pages the bulk of the browser’s time is not spent serving the initial content (generally the HTML) from the hosting infrastructure, but rather fetching all the assets and rendering the page on the client. This fact is captured by the diagram in Figure 3-5.⁵

Figure 3-5. Timeline frontent and backend

As a result, there has been an increased emphasis among web developers on improving the performance by reducing the client’s network latency and optimizing page render time. Quite literally, time is money.

Best Practices for Web Performance

As previously noted, the web has changed significantly—even in just the past few years. The relatively recent prevalence of mobile devices, the advances in JavaScript frameworks, and the evolution of the use of HTML warrant revisiting the rules laid out in the books referenced earlier, and going over the latest optimization techniques observed in the field.

Optimize DNS lookups

Since a DNS lookup needs to take place before a connection can be made to a host, it is critical that this resolution process be as fast as possible. The following best practices are a good place to start:

• Limit the number of unique domains/hostnames. Of course, this is not always in your control; however, the relative performance impact of the number of unique hostnames will only grow when moving to HTTP/2.

• Ensure low resolution latencies. Understand the topology of your DNS serving infrastructure and perform regular resolution time measurements from all the locations where your end users are (you can achieve this by using synthetic/real user monitoring). If you decide to rely on a third-party provider, select one best suited to your needs, as the quality of the services they offer can differ widely.

• Leverage DNS prefetch⁶ from your initial HTML or response. This will start DNS resolution of specific hostnames on the page while the initial HTML is being downloaded and processed. For example, the following will prefetch a DNS resolition for ajax.googleapis.com:

<link rel="dns-prefetch" href="//ajax.googleapis.com">

These techniques will help ensure the fixed overhead of DNS is minimized.

Optimize TCP connections

As discussed earlier in this chapter, opening new connections can be a time-consuming process. If the connection uses TLS (as they all should), the overhead is even higher. Mitigations for this overhead include:

• Leverage preconnect,⁷ as it will remove connection times from the waterfall critical path by having the connection established before it is needed. For example:

<link rel="preconnect" href="//fonts.example.com" crossorigin>

• Use early termination. Leveraging a Content Delivery Network (CDN), connections can be terminated at the edges of the internet located close to the requesting client, and therefore can greatly minimize the round-trip latencies incurred by establishing a new connection. See “Content Delivery Networks (CDNs)” for more information on CDNs.

• Implement the latest TLS best practices⁸ for optimizing HTTPS.

If a lot of resources are requested from the same hostname, the client browsers will automatically open parallel connections to the server to avoid resource-fetching bottlenecks. You don’t have direct control over the number of parallel connections a client browser will open for a given hostname, although most browsers now support six or more.

Avoid redirects

Redirects usually trigger connections to additional hostnames, which means an extra connection needs to be established. On radio networks (think mobile phones), an additional redirect may add hundreds of ms in latency, which is detrimental to the user experience, and eventually detrimental to the business running the websites. The obvious solution is to remove redirects entirely, as more often than not there is no “good” justification for some of them. If they cannot be simply removed, then you have two options:

• Leverage a CDN to perform the redirect “in the cloud” on behalf of the client

• If it is a same host redirect, use rewrite rules on the web server to avoid the redirect and map the user to the needed resource

Oftentimes, redirects are used to help with the dark art of Search Engine Optimization (SEO) to avoid short-term search result pain or consequent backend information layout changes. In such cases, you have to decide whether the redirect cost is worth the SEO benefits. Sometimes tearing the Band-Aid off in one go is the best long-term solution.

Cache on the client

Nothing is faster than retrieving an asset from the local cache, as no network connection is involved. As the saying goes (or at least will starting now), the fastest request is the one you do not make. In addition, when the content is retrieved locally, no charge is incurred either by the ISP or the CDN provider. The directive that tells the browser how long to cache an object is called the Time to Live, or TTL. Finding the best TTL for a given resource is not a perfect science; however, the following tried-and-tested guidelines are a good starting point:

• So-called truly static content, like images or versioned content, can be cached forever on the client. Keep in mind, though, that even if the TTL is set to expire in a long time, say one month away, the client may have to fetch it from the origin before it expires due to premature eviction or cache wipes. The actual TTL will eventually depend on the device characteristics (specifically the amount of available disk storage for the cache) and the end user’s browsing habits and history.

• For CSS/JS and personalized objects, cache for about twice the median session time. This duration is long enough for most users to get the resources locally while navigating a website, and short enough to almost guarantee fresh content will be pulled from the network during the next navigation session.

• For other types of content, the ideal TTL will vary depending on the staleness threshold you are willing to live with for a given resource, so you’ll have to use your best judgment based on your requirements.

Client caching TTL can be set through the HTTP header “cache control” and the key “max-age” (in seconds), or the “expires” header.

Cache at the edge

Caching at the edge of the network provides a faster user experience and can offload the serving infrastructure from a great deal of traffic as all users can benefit from the shared cache in the cloud.

A resource, to be cacheable, must be:

• Shareable between multiple users, and

• Able to accept some level of staleness

Unlike client caching, items like personal information (user preferences, financial information, etc.) should never be cached at the edge since they cannot be shared. Similarly, assets that are very time sensitive, like stock tickers in a real-time trading application, should not be cached. This being said, everything else is cacheable, even if it’s only for a few seconds or minutes. For assets that don’t change very frequently but must be updated on very short notice, like breaking news, for instance, leverage the purging mechanisms offered by all major CDN vendors. This pattern is called “Hold ’til Told”: cache it forever until told not to.

Conditional caching

When the cache TTL expires, the client will initiate a request to the server. In many instances, though, the response will be identical to the cached copy and it would be a waste to re-download content that is already in cache. HTTP provides the ability to make conditional requests, which is effectively the client asking the server to, “Give me the object if it has changed, otherwise just tell me it is the same.” Using conditional requests can have a significant bandwidth and performance savings when an object may not often change, but making the freshest version of the object available quickly is important. To use conditional caching:

• Include the Last-Modified-Since HTTP header in the request. The server will only return the full content if the latest content has been updated after the date in the header, else it will return a 304 response, with a new timestamp “Date” in the response header.

• Include an entity tag, or ETag, with the request that uniquely identifies the object. The ETag is provided by the server in a header along with the object itself. The server will compare the current ETag with the one received from the request header, and if they match will only return a 304, else the full content.

Most web servers will honor these techniques for images and CSS/JS, but you should check that it is also in place for any other cached content.

Compression and minification

All textual content (HTML, JS, CSS, SVG, XML, JSON, fonts, etc.), can benefit from compression and minification. These two methods can be combined to dramatically reduce the size of the objects. Fewer bytes means fewer round-trips, which means less time spent.

Minification is a process for sucking all of the nonessential elements out of a text object. Generally these objects are written by humans in a manner that makes them easy to read and maintain. The browser does not care about readability, however, and removing that readability can save space. As a trivial example, consider the following HTML:

<html>
<head>
  <!-- Change the title as you see fit -->
  <title>My first web page</title>
</head>
<body>
<!-- Put your message of the day here -->
<p>Hello, World!</p>
</body>
</html>

This is a perfectly acceptable HTML page and will render perfectly (if boringly) in a browser. But there is information in it that the browser does not need, including comments, newlines, and spaces. A minified version could look like:

<html><head><title>My first web page</title></head><body>
<p>Hello, World!</p></body></html>

It is not as pretty nor as maintainable, but it takes half the number of bytes (92 versus 186).

Compression adds another layer of savings on top of minification. Compression takes objects and reduces their size in an algorithmic way that can be reversed without loss. A server will compress objects before they are sent and result in a 90% reduction in bytes on the wire. Common compression schemes include gzip and deflate, with a relative newcomer, Brotli, beginning to enter the scene.

Avoid blocking CSS/JS

CSS instructions will tell the client browser how and where to render content in the viewing area. As a consequence, clients will make sure to download all the CSS before painting the first pixel on the screen. While the browser pre-parser can be smart and fetch all the CSS it needs from the entire HTML early on, it is still a good practice to place all the CSS resource requests early in the HTML, in the head section of the document, and before any JS or images are fetched and processed.

JS will by default be fetched, parsed, and executed at the point it is located in the HTML, and will block the downloading and rendering of any resource past the said JS, until the browser is done with it. In some instances, it is desirable to have the downloading and execution of a given JS block the parsing and execution of the remainder of the HTML; for instance, when it instantiates a so-called tag-manager, or when it is critical that the JS be executed first to avoid references to nonexisting entities or race conditions.

However, most of the time this default blocking behavior incurs unnecessary delays and can even lead to single points of failure. To mitigate the potential negative effects of blocking JS, we recommend different strategies for both first-party content (that you control) and third-party content (that you don’t control):

• Revisit their usage periodically. Over time, it is likely the web page keeps downloading some JS that may no longer be needed, and removing it is the fastest and most effective resolution path!

• If the JS execution order is not critical and it must be run before the onload event triggers, then set the “async”⁹ attribute, as in:

  <script async src=”/js/myfile.js”>.

  This alone can improve your overall user experience tremendously by downloading the JS in parallel to the HTML parsing. Watch out for document.write directives as they would most likely break your pages, so test carefully!

• If the JS execution ordering is important and you can afford to run the scripts after the DOM is loaded, then use the “defer” attribute,¹⁰ as in:

  <script defer src="/js/myjs.js">

• If the JS is not critical to the initial view, then you should only fetch (and process) the JS after the onload event fires.

• You can consider fetching the JS through an iframe if you don’t want to delay the main onload event, as it’ll be processed separately from the main page. However, JS downloaded through an iframe may not have access to the main page elements.

If all this sounds a tad complicated, that’s because it is. There is no one-size-fits-all solution to this problem, and it can be hazardous to recommend a particular strategy without knowing the business imperatives and the full HTML context. The preceding list, though, is a good starting point to ensure that no JS is left blocking the rendering of the page without a valid reason.

Optimize images

The relative and absolute weight of images for the most popular websites keeps increasing over time. The chart¹¹ in Figure 3-6 shows the number of requests and bytes size per page over a five-year period.

Figure 3-6. Transfer size and number of requests from 2011–2016 (source: httparchive.com)

Since most modern websites are dominated by images, optimizing them can yield some of the largest performance benefits. Image optimizations all aim at delivering the fewest bytes to achieve a given visual quality. Many factors negatively influence this goal and ought to be addressed:

• Image “metadata,” like the subject location, timestamps, image dimension, and resolution are often captured with the binary information, and should be removed before serving to the clients (just ensure you don’t remove the copyright and ICC profile data). This quality-lossless process can be done at build time. For PNG images, it is not unusual to see gains of about 10% in size reduction. If you want to learn more about image optimizations, you can read High Performance Images (O’Reilly 2016) by Tim Kadlec, Colin Bendell, Mike McCall, Yoav Weiss, Nick Doyle, and Guy Podjarny.

• Image overloading refers to images that end up being scaled down by the browsers, either because the natural dimensions exceed the placement size in the browser viewport, or because the image resolution exceeds the device display’s capability. This scaling down not only wastes bandwidth, but also consumes significant CPU resources, which are sometimes in short supply for handheld devices. We commonly witness this effect in Responsive Web Design (RWD) sites, which indiscriminately serve the same images regardless of the rendering device. Figure 3-7 captures this over-download issue.

Figure 3-7. Average RWD bytes served per pixel. Source: http://goo.gl/6hOkQp

Techniques for mitigating image overloading involve serving images that are tailored (in terms of size and quality) to the user’s device, network conditions, and the expected visual quality.

Summary

HTTP/1.1 has bred a messy if not exciting world of performance optimizations and best practices. The contortions that the industry has gone through to eek out performance have been extraordinary. One of the goals of HTTP/2 is to make many (though not all) of these techniques obsolete. Regardless, understanding them and the reasons they work will provide a deeper understanding of the web and how it works.

Browser Support

As of publishing time, around 80% of web browsers in use support h2 to some degree.¹ This means a significant portion of people will start reaping the benefits of h2 as soon as it is turned on. Since the protocol negotiation is transparent to non-h2 supporting browsers, anyone who does not speak h2 will simply fall back to h1 and still access your infrastructure. (You did keep h1 support for now, right?)

Table 4-1 lists browsers and the latest version supporting HTTP/2.

Moving to TLS

Since all major browsers will only access h2 over TLS (i.e., an HTTPS request), that means you need to support TLS or you do not get to play. On top of that the TLS bar has been set quite high: you need to support at least TLS 1.2 with a specific set of ephemeral ciphers (see section 9.2 of RFC 7540 for details). Most modern security-conscious websites are already on the “TLS everywhere” bandwagon so it might just be a no-op for you, but if not, then there is an investment in time and resources to be made.

Much has been done over the past five years or so to make moving to and using TLS on your website as painless as possible, but it is still additional work. Items to consider are:

Understand your web server

Every web server has a slightly different way to configure its HTTPS settings.

Obtain a certificate

EV, OV, DV, CN, CSR, X509, SAN—there’s a whole new alphabet soup of acronyms to wade through. Getting a certificate for your site generally involves a number of steps, including the creation of a Certificate Signing Request, verifying your identity and the ownership of the names the certificate is for, and purchasing the certificate from a Certificate Authority (CA). There are many CAs to choose from. Organizations such as Let’s Encrypt² are working to make it simple, fast, and even free to get a certificate.

Protect your private key

Your certificate is only as secure as you make it. To safely run a site over TLS, you need to consider how and where your private keys are stored and who has access to them. Solutions range from using very expensive Hardware Security Modules (HSMs) through finger crossing and good practices. If TLS is new to you, this will be an important aspect of your operational plan.

Prepare for increased server load

There has been a lot of effort to make TLS as inexpensive as possible, but it is a game of three steps forward and two back. Optimizations in symmetric ciphers have helped enormously, but moving to ephemeral key exchange has done the opposite (though it has made everything a lot more secure). Here are some best practices to get you started:

• Keep connections open as long as possible. The most expensive part of TLS is the handshake at connection time. If you keep the connection open for as long as possible, you will reduce the number of handshakes needed.

• Use session tickets. Session tickets allow a client to reconnect to the server, reusing the computationally expensive crypto work done in a previous handshake.

• Use a chipset with built-in crypto support. Intel’s AES-NI³ instructions in its modern processors make very quick work of symmetric cryptography.

Keep up with changes

Web security is a dynamic world. There is a new vulnerability in servers and HTTPS seemingly every couple of months. It is important to keep up with the “latest and greatest” to ensure your work of yesterday is not useless tomorrow.

Regularly check your site

You should use tools such as Qualys Lab’s SSL Test⁴ to check your site’s TLS configuration.

These best practices are good things to internalize for anyone standing up a service dependent on TLS, but TLS is a rich subject that requires a significant investment in time to fully appreciate. Remember:

A little learning is a dangerous thing; Drink deep, or taste not the Pierian spring.

Alexander Pope

Undoing HTTP 1.1 “Optimizations”

Web developers have put a lot of effort into getting the most out of h1. Best practices have emerged such as concatenation, sharding, minification, cookieless domains, and spriting, to name a few. So you may be surprised to learn that some of these patterns become anti-patterns under h2. For example, concatenation (taking many CSS or JavaScript files and melding them into one) can potentially save a browser from making a bunch of requests. This was important with h1 where requests were expensive, but under h2 they are much more optimized. Skipping concatenation might mean very little request overhead and better fine-grained browser caching of the individual files.

Table 4-2 lists some common tricks used to optimize h1 requests, and notes considerations for h2.

Assuming you take the time to fully optimize your site for h2, a problem immediately surfaces: you still have 25% of your traffic coming from h1 clients and you want to maximize their performance as well. Making everyone happy is an onerous task. Careful analysis of your users might tell you which group you should optimize for. Alternatively, you can conditionally serve different content for your h1 and h2 users, or use a CDN or similar tool that can do the magic for you.⁶

Third Parties

We love them and hate them, but third-party content on our sites is a reality. The problem with third-party content is you do not directly control it and are therefore at the mercy of what those third parties do and do not support. If h2 works best when everything is on a single socket, where do third parties come in? Being realistic, they do not, and they can become a major drag on any potential performance gain you might see from HTTP/2. The headache becomes even bigger if the third parties you use do not have a TLS option. Research⁷ into the effect of third-party content on page performance has determined that, in many cases, it is one of the largest factors in a page’s performance.

So what to do about third-party content? Start by finding out the answers to the following questions:

• Does your third party have a TLS option?

• Do they have plans to support HTTP/2?

• Do they see minimizing performance impact as a critical element of what they provide?

If the answer to any of these questions is “no,” then there are two follow-up questions: “Are there other third parties that provide what I need?” and “Do I really need this third-party content, or could I live without?”

Supporting Older Clients

Some people do not like change. Their current browser works for them, and upgrading can be a nuisance. The problem is that these people may be your customers or users and you may not be ready to abandon them. Here is a real example. Microsoft ended support of Windows XP on April 8, 2014. This means that users on XP are falling farther and farther behind in terms of modern browsers and security. Needless to say, Internet Explorer on XP cannot talk h2, but more importantly, depending on how your TLS settings are configured and whether you have a clear-text fallback site, those users might not be able to even access your site over h1! On one hand this is the inevitability of progress, but on the other hand these could be important users and customers for you. This reality is yet one more item to consider before making the move to HTTP/2.

Summary

Though a transition to HTTP/2 is generally seen as a good thing and should be completely transparent to your website, there are certainly considerations that you need to take into account before flipping the switch. Even though many major websites have been running h2 for some time now, that does not mean it is a guaranteed win for your situation. It should be treated the same as any other significant change: test, test, test.

Layers of HTTP/2

HTTP/2 can be generalized into two parts: the framing layer, which is core to h2’s ability to multiplex, and the data or http layer, which contains the portion that is traditionally thought of as HTTP and its associated data. It is tempting to completely separate the two layers and think of them as totally independent things. Careful readers of the specification will note that there is a tension between the framing layer being a completely generic reusable construct, and being something that was designed to transport HTTP. For example, the specification starts out talking generically about endpoints and bidirectionality—something that would be perfect for many messaging applications—and then segues into talking about clients, servers, requests, and responses. When reading about the framing layer it is important to not lose sight of the fact that its purpose is to transport and communicate HTTP and nothing else.

Though the data layer is purposely designed to be backward compatible with HTTP/1.1, there are a number of aspects of h2 that will cause developers familiar with h1 and accustomed to reading the protocol on the wire to perform a double take:

Binary protocol

The h2 framing layer is a binary framed protocol. This makes for easy parsing by machines but causes eye strain when read by humans.

Header compression

As if a binary protocol were not enough, in h2 the headers are heavily compressed. This can have a dramatic effect on redundant bytes on the wire.

Multiplexed

When looking at a connection that is transporting h2 in your favorite debugging tool, requests and responses will be interwoven with each other.

Encrypted

To top it off, for the most part the data on the wire is encrypted, making reading on the fly more challenging.

We will explore each of these topics in the ensuing pages.