Learning HTTP/2 An Introduction to the Next Generation Web This Preview Edition of Learning HTTP/2 is a work in progress The final book is currently scheduled for publication in December, 2016 and will be available at oreilly.com and through other retailers when it’s published Stephen Ludin and Javier Garza Beijing Boston Farnham Sebastopol Tokyo Learning HTTP/2 by Stephen Ludin and Javier Garza Copyright © 2016 Stephen Ludin, Javier Garza All rights reserved Printed in the United States of America Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472 O’Reilly books may be purchased for educational, business, or sales promotional use Online editions are also available for most titles (http://my.safaribooksonline.com) For more information, contact our corpo‐ rate/institutional sales department: 800-998-9938 or corporate@oreilly.com Editor: Virginia Wilson Production Editor: Nicholas Adams Interior Designer: David Futato Cover Designer: Randy Comer Illustrator: Rebecca Demarest First Edition October 2016: Revision History for the First Edition 2016-09-23: First Preview Release See http://oreilly.com/catalog/errata.csp?isbn=9781491943397 for release details The O’Reilly logo is a registered trademark of O’Reilly Media, Inc Learning HTTP/2, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work Use of the information and instructions contained in this work is at your own risk If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights 978-1-491-97460-5 [LSI] Table of Contents Evolution of HTTP HTTP/0.9 and 1.0 HTTP/1.1 Beyond 1.1 SPDY HTTP/2 10 10 11 Existing workarounds to improve Web Performance 13 Introduction Best Practices for Web Performance Optimize DNS lookups Optimize TCP connections Avoid redirects Cache on the Client Cache at the Edge (= on a CDN) Check if content has changed before downloading it Compress and minify text-like content Avoid blocking CSS/JS Optimize images Anti-Patterns Spriting and resource consolidation/inlining Sharding Cookie-less domains Chapter summary 13 14 14 15 16 16 17 17 18 18 19 21 21 22 22 22 The Protocol 25 The Connection Frames 26 28 iii Streams Messages Flow Control Priority Server Push Pushing an Object Choosing What to Push Header Compression (HPACK) On the Wire A simple GET 30 31 34 34 36 36 38 39 41 41 HTTP/2 Implementations 47 Browsers Google Chrome HTTP/2 support (and how to disable it) Handling of HTTP/2 (and how it differs from HTTP/1.1) Connection Coalescing Chrome Developer tools (that are more relevant for HTTP/2) Server Push st = Server-Push visualization Mozilla Firefox HTTP/2 support (and how to disable it) Handling of HTTP/2 (and how it differs from HTTP/1.1) Firefox Developer tools (that are more relevant for HTTP/2) Loging HTTP Sessions https://developer.mozilla.org/en-US/docs/Mozilla/ Debugging/HTTP_logging Firefox HTTP/2 capture Microsoft Edge HTTP/2 support (and how to disable it) Apple Safari HTTP/2 support (and how to disable it) Servers Apache HTTP/2 support in Apache Configuring Apache for HTTP/2 Nginx Web Server HTTP/2 support in Nginx Configuring HTTP/2 support in Nginx Microsoft Internet Information Services (IIS) HTTP/2 support in IIS Proxies iv | Table of Contents 47 47 49 49 50 50 60 61 64 67 69 69 69 70 72 73 74 74 74 74 74 75 75 77 78 78 79 79 80 Nginx Squid Varnish Apache Traffic Server Content Delivery Networks (CDNs) Akamai Level Communications Limelight Networks Cloudflare Fastly 80 81 81 81 82 82 83 84 84 84 Table of Contents | v CHAPTER Evolution of HTTP In the 1930s Vannevar Bush, an electrical engineer from the United States then at MIT’s School of Engineering, had a concern with the volume of information we were producing relative to society’s ability to consume that information In his essay pub‐ lished in the Atlantic Monthly in 1945 entitled, “As We May Think,” he said: Professionally our methods of transmitting and reviewing the results of research are generations old and by now are totally inadequate for their purpose If the aggregate time spent in writing scholarly works and in reading them could be evaluated, the ratio between these amounts of time might well be startling —Vannevar Bush, Atlantic Monthly He envisioned a system where our aggregate knowledge was was stored on microfilm and could be “consulted with exceeding speed and flexibility.” He further stated that this information should have contextual associations with related topics, much in the way the human mind links data together His memex system was never built, but the ideas influences those that followed The term Hypertext that we take or granted today was coined around 1963 and first published in 1965 by Ted Nelson, a software designer and visionary He proposed the idea of hypertext: to mean a body of written or pictorial material interconnected in such a complex way that it could not conveniently be presented or represented on paper It may contain summaries, or maps of its contents and their interrelations; it may contain annotations, additions and footnotes from scholars who have examined it —Ted Nelson T H Nelson, “Complex information processing: a file structure for the complex, the changing and the inde‐ terminate”, ACM ’65 Proceedings of the 1965 20th national conference Nelson wanted to create a “docuverse” where information was interlinked and never deleted and easily available to all He built on Bush’s ideas and in the 1970s created a prototype implementations of his project Xanadu It was unfortunately never comple‐ ted, but provided the shoulders to stand on for those to come HTTP enters the picture in 1989 While at CERN, Tim Berners-Lee proposed a new system for helping keep track of the information created by the accelerators (refer‐ encing the yet to be built Large Hadron Collider) and experiments at the institution He embraces two concepts from Nelson: Hypertext, or “Human-readable information linked together in an unconstrained way,” and Hypermedia a term to “indicate that one is not bound to text.” In the proposal he discussed the creation of a server and browsers on many machines to provide a “universal system.” HTTP/0.9 and 1.0 HTTP/0.9 was a wonderfully simple, if limited, protocol It had a single method (GET), there were no headers, and it was designed to only fetch HTML Over the next few years use of HTTP grew across the world By 1995 there were over 18,000 servers handling HTTP traffic on port 80 across the world The protocol had evolved well past its 0.9 roots and in 1996 RFC 19453 codified HTTP/1.0 Version 1.0 brought a massive amount of change to the little protocol that started it all Whereas the 0.9 spec was about a page long, the 1.0 RFC measured in at 60 pages You could say it had grown from a toy into a tool It brought in ideas that are very familiar to us today: • Headers • Response Codes • Redirects • Errors • Conditional request • Content Encoding (compression) • More request methods and more HTTP/1.0, though a large leap from 0.9 still had a number of known flaws to be addressed Most notably were the inability to keep a connection open between requests, the lack of a mandatory Host header, and bare bones options for caching https://www.w3.org/History/1989/proposal.html “https://tools.ietf.org/html/rfc1945” | Chapter 1: Evolution of HTTP — 1: important; intended to always be logged — 2: errors — 3: warnings — 4: debug messages, notices — 5: everything! • Removing a module from the list For example NSPR_LOG_MODULES=time stamp,nsHttp:5 is less verbose than NSPR_LOG_MODULES=timestamp,nsHttp: 5,nsSocketTransport:5,nsStreamPump:5 You can get the most verbose logging by using NSPR_LOG_MODULES=all:5 See List of modules for NSPR_LOG_MODULES for a more com‐ prehensive list of modules that can be included in the logs The sections below explain some of the parameters available to the variable NSPR_LOG_FILE (see NSPR Log Modules Documentation for more details) timestamp Indicating the timestamp parameter prepends the date, time and timezone to each of the log lines • With timestamp a log line would look like: 2016-07-18 11:14:51.619485 UTC - [Main Thread]: I/nsHttp http request [ • Without timestamp a log line would look like: Main Thread]: I/nsHttp http request [ Indicating timestamp is recommended if you want have a timeline of events and for example identify how long it takes for a specific event to happen after another one nsHttp (HTTP transactions) nsHttp includes HTTP protocol releated information like HTTP requests and responses Mozilla Firefox | 71 Replace NSPR_LOG_MODULES=nsHttp:5 with NSPR_LOG_MOD ULES=nsHttp:3 in the commands above if you want to log only HTTP request and response headers You may see a letter prepending the nsHttp lines which indicates the type of verbosity for that line like: • V/nsHttp corresponds to verbosity number • D/nsHttp corresponds to verbosity number • I/nsHttp corresponds to verbosity number nsSocketTransport (socket-level transactions) You can simply remove the text nsSocketTransport:5 from the variable NSPR_LOG_MODULES to omit socket-level transactions nsHostResolver (DNS query logging) You can simply remove the text nsHostResolver:5 from the variable NSPR_LOG_MOD ULES to omit host resolving (that is, DNS queries) Firefox HTTP/2 capture Follow the steps indicated on the Loging HTTP Sessions section to a capture of HTTP/2 traffic in Firefox The following sections highlight different HTTP/2 elements on the Firefox HTTP session logs http2 Session The Firefox log will show something like this at the beginning of a HTTP/2 session [Socket [Socket [Socket [Socket Thread]: Thread]: Thread]: Thread]: I/nsHttp I/nsHttp I/nsHttp I/nsHttp Http2Session::ALPNCallback sslsocketcontrol=12c756438 Http2Session::ALPNCallback version=303 Http2Session::Http2Session 12e946000 serial=0x1 Http2Session::SendHello 12e946000 Streams The lines below indicate how you can identify in the Firefox logs the creation of a HTTP/2 stream: [Socket Thread]: I/nsHttp Http2Stream::Http2Stream 11f730f70 [Socket Thread]: I/nsHttp Http2Session::AddStream session=12e946000 stream=11f730f70 serial=1 Next 72 | Chapter 4: HTTP/2 Implementations Firefox Dependencies and Priorities As of September 2016, Firefox implements dependencies and weights very different than Chome Firefox empty streams at the beginning of a connection in order to hold resources, and then sets up dependencies and weights between them, and finally puts resource streams as dependencies of each of them (while Chrome seems to use a much simpler approach) The lines below show depencies and priorities for given frames For example the line “I/nsHttp Http2Session 12e946000 generate Priority Frame 0x3 depends on 0x0 weight 200 for leader class” shows frame 0x3 which belongs to session 12e946000 depends on 0x0 and has a weight of 200 [Socket [Socket [Socket [Socket [Socket Thread]: Thread]: Thread]: Thread]: Thread]: I/nsHttp I/nsHttp I/nsHttp I/nsHttp I/nsHttp Http2Session Http2Session Http2Session Http2Session Http2Session 12e946000 12e946000 12e946000 12e946000 12e946000 generate generate generate generate generate Priority Priority Priority Priority Priority Frame Frame Frame Frame Frame 0x3 0x5 0x7 0x9 0xB depends depends depends depends depends on on on on on 0x0 0x0 0x0 0x7 0x3 weight weight weight weight weight Server-Push Similarly to the Chrome HTTP/2 capture, we can identify the server-push events on the Developer Tools > Network Tab as pushed assets not get a timeline, and are identified by a solid grey circle You can also idenfify pushed assets on the Firefox HTTP log Let’s inspect the Firefox HTTP logs recorded on Mac OS using the follow‐ ing commands on the Terminal: [Socket Thread]: I/nsHttp Pushed Stream Lookup session=12e946000 key=https://akah2san.h2book.com/[ [Socket Thread]: I/nsHttp Pushed Stream Lookup session=12e944800 key=https://akah2san.h2book.com/[ [Socket Thread]: I/nsHttp Pushed Stream Lookup session=12eb19800 key=https://akah2san.h2book.com/[ Firefox and Wireshark Wireshark is a free and open source packet analyzer commonly used for network troubleshooting Firefox Key logs can be written by NSS so that external programs can decrypt TLS connections This can be very useful for Wireshark 1.6.0 (and above) to read those log files in order to decrypt packets You can find more details on how to this at https://developer.mozilla.org/en-US/ docs/Mozilla/Projects/NSS/Key_Log_Format (http://goo.gl/whdLB3) Microsoft Edge Microsoft Edge (codename “Spartan”) is a web browser developed by Microsoft that replaces Internet Explorer as the default web browser on Windows 10, Windows 10 Mobile, and Xbox One It uses EdgeHTML, a proprietary layout engine based on Tri‐ Microsoft Edge | 73 dent that is meant to be fully compatible with Webkit (used by Chrome and other browsers) Figure 6.1.3a - Microsoft Edge logo HTTP/2 support (and how to disable it) According to caniuse.com, Microsoft Edge supports HTTP/2 since version 12, as does Internet Explorer 11 but only when running under Windows 10 I did not find a way to disable HTTP/2 support on Microsoft Edge / IE 11 on Win‐ dows 10 yet (need to check with my contacts at Microsoft) Apple Safari Safari is a web browser developed by Apple based on the WebKit engine It is the default browser on Apple devices The Windows version was discontinued in 2012 Figure 6.1.4a - Apple Safari logo HTTP/2 support (and how to disable it) According to caniuse.com, Safari supports HTTP/2 since version (on Mac OS 10.11 -also known as El Capitan- or higher and in iOS or higher) I did not find a way to disable HTTP/2 support on Safari yet (need to check with my contacts at Apple) Servers This section describes how to configure HTTP/2 support in some of the most com‐ mon Web servers Apache The Apache HTTP Server (usually called just Apache) is a free and open-source Web server maintained by an open community of developers under the auspices of the Apache Software Foundation 74 | Chapter 4: HTTP/2 Implementations According to the Netcraft’s Web Survey, Apache has been the most popular Web server since 1997, and as of July 2016, Apache was estimated to serve 46.41% of all active websites, and 43.18% of the top million websites Figure 6.2.1a - Apache Server logo HTTP/2 support in Apache The HTTP/2 protocol is implemented in Apache by its own module, named mod_http2 It implements the complete set of features described by RFC 7540, and supports HTTP/2 over clear-text (named h2c) using HTTP, as well as secure (named h2) using HTTPS Apache allows both h2c, and the upgrading of an initial HTTP/1 request to h2 via the Upgrade: directive As we saw in the Browsers section, the popular browsers only speak HTTP/2 over HTTTPS, so your Apache server will need to be compiled with an SSL library that supports the ALPN extension (like OpenSSL version 1.0.2 or higher) and a strong TLS cipher suite (SSLCipherSuite) which does not contain any ciphers included in the HTTP/2 TLS blacklist Configuring Apache for HTTP/2 This section intends to provide some insight on how to configure Apache for HTTP/2 Please check the Apache HTTP Server configuration guide for more details and to see all the options available Building Apache’s httpd for HTTP/2 mod_http2 uses the library of nghttp2 as its implementation base In order to build mod_http2 you need at least version 1.2.1 of libnghttp2 installed on your system You need to pass enable-http2 to /configure in order to trigger the build of the mod_http2 module You may need to add the parameter ' with-nghttp2=' to the configure command if the libnghttp2 is not located on the default path, indicating its location You can add also the parameter ' enable-nghttp2-staticlibdeps' to the configure command if you prefer a statically linked nghttp2 in this module Servers | 75 The mod_http2 module (mod_http2.so) should now be in the modules directory (usually /usr/lib/httpd/modules/ on most Unix systems) Editing Apache’s configuration for HTTP/2 Once you have a httpd built with mod_http2, you need a few commands on the Apache configuration (usually called httpd.conf) for it becoming active: • First, load the mod_http2 module LoadModule http2_module modules/mod_http2.so • The second directive you need to add to your server configuration is: Protocols h2 http/1.1 This allows h2 (the secure variant over HTTPS), to be the preferred protocol on your server connections You can also activate the non-secure HTTP/2 variant using the line below instead: Protocols h2 *h2c* http/1.1 If you want to enable HTTP/2 only on a given hostname, you can just add the direc‐ tive inside the VirtualHost sections of the hostnames you want For example the sec‐ tion below adds the secure HTTP/2 version to www.example.com: ServerName www.example.com Protocols h2 http/1.1 Enabling HTTP/2 Server-Push in Apache By default Apache’s mod_http2 implements HTTP/2 server-push, which allows the server to push resources based on hints included via declarative markup within the HTML (link rel="preload"), or via HTTP headers The example below shows the HTML tag needed to hint an Apache server with mod_http2 to push /main.css to the client You can indicate several link rel="preload" tags to push more than one object for example: 76 | Chapter 4: HTTP/2 Implementations The example below shows the HTTP Headers needed to hint an Apache server with mod_http2 to push /main.css to the client Link ;rel=preload You can include several hints within a single Link HTTP header by separating them with commas The example will hint the server to push /main.css and /jquery.js to the client Link ;rel=preload, ; rel=preload You can generate the HTTTP Headers within the Apache configuration by adding a corresponding directive The example below will add the headers to /index.html Header add Link ";rel=preload" Header add Link ";rel=preload" Disabling HTTP/2 Server-Push in Apache If you want to use preload links without triggering a HTTP/2 Server-Push, you can use the nopush parameter, as in: Link ;rel=preload;nopush If you want to just turn-off Apache’s mod_http2 Server-Push, you can use the H2Push directive within the Apache configuration file like: H2Push Off Apache online documentation See the Apache HTTP/2 documentation for more details Nginx Web Server Nginx is a free and open source web server, that can also act as a reverse proxy server for TCP, UDP, HTTP, HTTPS, SMTP, POP3, and IMAP protocols; as well as a load balancer, and an HTTP cache According to the Netcraft’s Web Survey, Nginx is the second most popular Web server as of July 2016 with 21.8% of market market share of active sites Servers | 77 Figure 6.2.2a - Nginx logo HTTP/2 support in Nginx HTTP/2 support in Nginx comes through ngx_http_v2_module module, which is not built by default, but can be enabled with the with-http_v2_module configuration parameter Similar to Apache’s configuration, you need to ensure the Nginx configuration meets the security requirements for delivering secure HTTP/2 in terms of running and SSL library that supports the ALPN extension (like OpenSSL version 1.0.2 or higher) and a strong TLS cipher suite (SSLCipherSuite) which does not contain any ciphers included in the HTTP/2 TLS blacklist Configuring HTTP/2 support in Nginx See below an example configuration which enables HTTP/2: server { listen 443 ssl http2; ssl_certificate server.crt; ssl_certificate_key server.key; } Nginx also allows using a subset of directives to tune different HTTP/2 parameters Some of those directives are listed below, please refer to Nginx ngx_http_v2_module’s documentation for more details: • http2_chunk_size: Sets the maximum size of chunks into which the response body is sliced • http2_body_preread_size: Sets the size of the buffer per each request in which the request body may be saved before it is started to be processed • http2_idle_timeout: Sets the timeout of inactivity after which the connection is closed • http2_max_concurrent_streams: Sets the maximum number of concurrent HTTP/2 streams in a connection • http2_max_field_size: Limits the maximum size of an HPACK-compressed request header field • http2_max_header_size: Limits the maximum size of the entire request header list after HPACK decompression 78 | Chapter 4: HTTP/2 Implementations • http2_recv_buffer_size: Sets the size of the per worker input buffer • http2_recv_timeout: Sets the timeout for expecting more data from the client, after which the connection is closed HTTP/2 Server-Push in Nginx As of the time of writing and according to a Blog on Nginx.com, Nginx does NOT support HTTP/2 server-push It is however very likely support for server-push will come before the end of 2016 According to a blog post published May 13, 2016 Cloudflare, a Content Delivery Network which uses Nginx for its Edge servers, made openly available a patch that can be installed on top of Nginx 1.9.7 to provide server-push support Microsoft Internet Information Services (IIS) Microsoft Internet Information Services (IIS) is an extensible web server created by Microsoft for use with Windows NT IIS supports the following protocols: • HTTP • HTTPS • FTP • FTPS • SMTP • NNTP According to the Netcraft’s Web Survey, as of July 2016, IIS is used by about 36 Mil‐ lion Websites However only 4.5% of sites using Microsoft server software are consid‐ ered active, leaving Microsoft in 3rd place by this active sites metric with a 9.8% market share behind Nginx HTTP/2 support in IIS IIS 10 (included in Windows Server 2016 and Windows 10) includes support for secure (over TLS) HTTP/2 without any extra configuration settings; and according to a David’s So IIS blog there are no settings within IIS for HTTP/2 other than adding Servers | 79 the “protocol version” to the W3C logs so you can identify HTTP/2 requests within IIS access logs You can learn more about IIS HTTP/2 support by watching a 30 minute video from MSDN where Rob Trace (Microsoft Program Manager) explains the HTTP/2 support in IIS 10 Enabling HTTP/2 Server-Push in IIS IIS supports HTTP/2 server-push via a PushPromise API call in ASP.NET, or the HttpDeclarePush API from an IIS native module You need to provide the URL and optional request headers for the request you anticipate the client making Please check the IIS server documentation for more details Be aware the call will return a success but nothing if the con‐ necting client does not support HTTP/2 Proxies A proxy server it is a server component which may reside on the user’s local com‐ puter, or at various points between the user’s computer and destination servers on the Internet There are basically types of proxy servers: • Gateway/Tunneling Proxy: A proxy server that passes requests and responses unmodified • Forward Proxy: Internet-facing proxy used to retrieve from a wide range of sour‐ ces (in most cases anywhere on the Internet) • Reverse Proxy: An internal-facing proxy used as a front-end to control and pro‐ tect access to a server on a private network A reverse proxy sometimes also per‐ forms tasks such as load-balancing, authentication, decryption or caching In this section we are going to focus on some of the most common Reverse Proxy servers, and their HTTP/2 support to connecting clients Nginx See Nginx 80 | Chapter 4: HTTP/2 Implementations Squid Squid (also known as squid-cache) is a caching and forwarding web proxy, support‐ ing the following protocols: HTTP, FTP, TLS, SSL, Internet Gopher and HTTPS Figure 6.3.2a - Squid logo As of writing, Squid offered no HTTP/2 support, although HTTP/2 support is being tracked as an upcoming feature of version 4.x Varnish Varnish is an HTTP accelerator designed for content-heavy dynamic web sites / high demand APIs In contrast to other web accelerators, such as Squid, Apache or nginx that support several protocols like FTP; Varnish was designed as an HTTP accelerator As of writing, Varnish offered no HTTP/2 support, although according to a blog post from Varnish Cache Chief Architect Poul-Henning Kam, support for HTTP/2 will come with Varnish version It is possible to implement HTTP/2 support by using a differnt server with HTTP/2 support that sites between the clients and the Varnish origin server Apache Traffic Server The Apache Traffic Server (ATS) is a modular, high-performance reverse proxy and forward proxy server, similar to Nginx and Squid which, developed by the Apache Software Foundation Proxies | 81 Figure 6.3.2b - Apache Traffic Server logo According to the Apache Traffic Server website, HTTP/2 support was included in version of ATS 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 con‐ tent 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 In this section we are going to focus on some of the most popular CDNs, and their HTTP/2 support to connecting clients Akamai Akamai Technologies is a content delivery network and cloud services provider, and one of the world’s largest distributed computing platforms, responsible for serving between 15 and 30 percent of all web traffic, and the only CDN with over $2 Billion in revenue Figure 6.4a - Akamai logo Akamai has been very engaged on network protocols, and especially on HTTP/2 with both Mark Nottingham (chair of the IETF Working Group) and Stephen Ludin (Aka‐ mai’s Chief Architect) been involved on the HTTP/2 standard since its early stages in 2012 Akamai implemented support for HTTP/2 within its network of Web servers even before the standard was approved in February 2015 by showcasing its implementa‐ tion on the visually appealing HTTP/2 vs HTTP/1.1 Performance demo site Akamai officially announced general HTTP/2 availability for customers (on an opt-in basis) as of March 2016 82 | Chapter 4: HTTP/2 Implementations Akamai customers are able to self-configure HTTP/2 using Akamai Web service Configuration Tool called Property Manager HTTP/2 Server-Push is supported, according to a Blog published April 2016 Contrary to most Web Server Server-Push implementations, Akamai’s server-push implementation (as of August 2016) is not hint-based, but offers different ways of pushing content to end users: By manually indicating the resources to push on the Akamai configuration file (Manual Push): although this approach seems cumbersome at first, it actually performs pretty well as it allows for the CDN server to push objects to the clients before it receives the HTML from the origin This results on faster page load times especially on dynamic HTML pages, as it allows the CDN to push bytes to the client when during otherwise network idle time By using a Predective Push Engine (Automated Predictive Push): Where an auto‐ mated workflow analyzes the HTML, identifies push candidates, and instructs the Akamai CDN edge servers to have then pushed to clients in a similar way as in the Manual push described above Level Communications Level Communications is an American multinational telecommunications and Internet service provider company that operates a Tier network It provides core transport, IP, voice, video, and content delivery Figure 6.4b - Level logo The company runs a content delivery network which it acquired from Savvis in 2006 According to CDN Overview’s Level3 Feature Overview, Level does NOT support HTTP/2; which is probably accurate since their main site www.level3.com is deliv‐ ered over HTTP/1.1 Content Delivery Networks (CDNs) | 83 Limelight Networks Limelight Networks owns and manages a global, private CDN Figure 6.4c - Limelight logo After reviewing Limeligiht’s marketing materials, it seems the CDN does NOT sup‐ port HTTP/2 yet; which is probably accurate since their main site www.limelight.com is delivered over HTTP/1.1 Cloudflare CloudFlare, Inc is a U.S company that provides a content delivery network, Internet Security services and distributed domain name server services Figure 6.4d - Cloudflare logo Cloudflare announced HTTP/2 support on December 2015 as an opt-in for its Enter‐ prise & Business customers and enabled by default for customers on the Free or Pro plans Support for HTTP/2 Server-Push was announced on a blog post on April 2016 and similar to Apache’s it is based on hints using the Link: rel=preload directive Fastly Fastly is a U.S company that markets as the future of content delivery 84 | Chapter 4: HTTP/2 Implementations Figure 6.4e - Fastly logo Fastly announced Limited Availability for HTTP/2 on June 2016 Indicating Fastly’s HTTP/2 implementation will support all HTTP/2 features including Server-Push (although, it is not clear HTTP/2 server-push is supported yet, and neither it is used across their site www.fastly.com) Content Delivery Networks (CDNs) | 85 ... built on Written in stone, it did not evolve or change The web, however, and the way we used it continued to change in way likely unimagined by its originators The interactivity and utility of your... send all of its request at once This may sound a bit like a preview of Multiplexing which will come in HTTP/2 There were a couple of problems with pipe‐ lining that prevented its popularity Servers... businesses, it has become criti‐ cal for organizations to understand, measure and optimize website performance One of the most saillant take away from Souders’s initial findings is that for the majority