But there are some non-browser tools that come in handy when working with HTTP/2. This blog post starts with a useful browser add-on, and then delves into command-line tools, load testing, conformance verification, development libraries and packet decoding for HTTP/2.

If you know of something that I've missed please write a comment.

For Google Chrome there's a handy HTTP/2 and SPDY Indicator extension that adds a colored lightning bolt to the browser bar showing the protocol being used when a web page is viewed.

The blue lightning bolt shown here indicates that the CloudFlare home page was served using HTTP/2:

A green lightning bolt indicates the site was served using SPDY and gives the SPDY version number. In this case SPDY/3.1:

A grey lightning bolt indicates that neither HTTP/2 no SPDY were used. Here the web page was served using HTTP/1.1.

There's a similar extension for Firefox.

There's also a handy online tool to check any individual web site.

CloudFlare also has a Google Chrome extension called Claire that gives information about how a web page was loaded. For example here's the information that Claire shows for a site using CloudFlare that uses IPv6, Railgun, and HTTP/2.

There's a handy command-line tool called is-http which is installed using npm as follows:

npm install -g is-http2-cli

Once installed you can check the HTTP/2 status of a web on the command-line:

$ is-http2 www.cloudflare.com
✓ HTTP/2 supported by www.cloudflare.com
Supported protocols: h2 spdy/3.1 http/1.1

$ is-http2 www.amazon.com
× HTTP/2 not supported by www.amazon.com
Supported protocols: http/1.1

The is-http tool is also useful because it gives you a list of the protocols advertised by the server. As you can see www.cloudflare.com supports HTTP/2, HTTP/1.1 and SPDY/3.1.

In version 7.43.0 the venerable curl tool got HTTP/2 support when it's linked with the nghttp library. To build curl from sources you'll need OpenSSL, zlib, nghttp2 and libev. I used the following sequence of commands.

$ curl -LO http://dist.schmorp.de/libev/libev-4.20.tar.gz
$ tar zvxf libev-4.20.tar.gz
$ cd libev-4.20
$ ./configure
$ make
$ sudo make install

$ curl -LO https://www.openssl.org/source/openssl-1.0.2d.tar.gz
$ tar zxvf openssl-1.0.2d.tar.gz
$ cd openssl-1.0.2d
$ ./config shared zlib-dynamic
$ make && make test
$ sudo make install

$ curl -LO http://zlib.net/zlib-1.2.8.tar.gz
$ tar zxvf zlib-1.2.8.tar.gz
$ cd zlib-1.2.8
$ ./configure
$ make && make test
$ sudo make install

$ curl -LO https://github.com/tatsuhiro-t/nghttp2/releases/download/v1.5.0/nghttp2-1.5.0.tar.gz
$ tar zxvf nghttp2-1.5.0.tar.gz
$ cd nghttp2-1.5.0
$ OPENSSL_CFLAGS="-I/usr/local/ssl/include" OPENSSL_LIBS="-L/usr/local/ssl/lib -lssl -lcrypto -ldl" ./configure
$ make
$ sudo make install

$ curl -LO http://curl.haxx.se/download/curl-7.46.0.tar.gz
$ tar zxvf curl-7.46.0.tar.gz
$ cd curl-7.46.0
$ ./configure
$ make && make test
$ sudo make install
$ sudo ldconfig

Once installed curl has a new --http2 option that causes it to use HTTP/2 (if it can). The -v verbose option will show information about the use of HTTP/2:

$ curl -vso /dev/null --http2 https://www.cloudflare.com/
[...]
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* TCP_NODELAY set
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0xc3dba0)
[...]

If you built curl using my instructions above you will have built and installed some tools that come with the nghttp2 library. One of those is a command-line client called nghttp. It can be used like curl to download from the web using HTTP/2 but it also has a handy verbose option that shows that actual HTTP/2 frames sent and received.

By running it with -nv you get HTTP/2 and throw away the actual downloaded page. Here's its output when downloading www.cloudflare.com using HTTP/2. On a terminal with color support it uses coloring to highlight different parts of the log.

Another curl-like command-line tool for HTTP/2 is h2c. It also enables dumping of HTTP/2 frames and has a nice feature that it runs in the background and keeps connections to servers alive and has a useful 'wiretap' feature for intercepting an HTTP/2 for debugging.

If you have Go 1.5.1 installed then you can download it as follows:

$ export GO15VENDOREXPERIMENT=1
$ go get github.com/fstab/h2c

You start h2c running by doing h2c start & which sets it running in the background. You can then communicate with a web server like this:

 $ h2c connect www.cloudflare.com
 $ h2c get /
 $ h2c disconnect

And it will perform the HTTP request. To see detailed output at the HTTP/2 you start h2c with the --dump parameter:

 $ h2c start --dump

You will then get detailed output dumped by that process, in color, of the HTTP/2 frames being used.

Details of the wiretap feature are in [this blog post](http://unrestful.io/2015/08/28/wiretap.html).

If you just want to find out what protocols a web site supports OpenSSL's s_client can be used. If you specify an empty -nextprotoneg option OpenSSL sends an empty TLS option asking for negotiation of the next protocol and the server responds with a complete list of protocols it supports.

$ openssl s_client -connect www.cloudflare.com:443 -nextprotoneg ''
CONNECTED(00000003)
Protocols advertised by server: h2, spdy/3.1, http/1.1

There you can see that www.cloudflare.com support HTTP/2 (the h2), SPDY/3.1 and HTTP/1.1.

If you want to do low level HTTP/2 debugging there's an interactive client call h2i. Once again it requires that you have Go installed. To get it, run

$ go get github.com/golang/net/http2/h2i

You can then use h2i to connect to a site that uses HTTP/2 and send it individual HTTP/2 frames. For example, here's the start of session connecting to www.cloudflare.com and requesting the home page using the headers command which allows you to type in a standard HTTP/1.1 request.

$ h2i www.cloudflare.com
Connecting to www.cloudflare.com:443 ...
Connected to 198.41.214.163:443
Negotiated protocol "h2"
[FrameHeader SETTINGS len=18]
 [MAX_CONCURRENT_STREAMS = 128]
 [INITIAL_WINDOW_SIZE = 2147483647]
 [MAX_FRAME_SIZE = 16777215]
[FrameHeader WINDOW_UPDATE len=4]
  Window-Increment = 2147418112

h2i> headers
 (as HTTP/1.1)> GET / HTTP/1.1
 (as HTTP/1.1)> Host: www.cloudflare.com
 (as HTTP/1.1)>
  Opening Stream-ID 1:
  :authority = www.cloudflare.com
  :method = GET
  :path = /
  :scheme = https
 [FrameHeader HEADERS flags=END_HEADERS stream=1 len=819]
   :status = "200"
   server = "cloudflare-nginx"
   date = "Fri, 04 Dec 2015 10:36:15 GMT"
   content-type = "text/html"
   last-modified = "Thu, 03 Dec 2015 22:27:41 G MT" 
   strict-transport-security = "max-age=31536000"
   x-content-type-options = "nosniff"
   x-frame-options = "SAMEORIGIN"
   cf-cache-status = "HIT"
   expires = "Fri, 04 Dec 2015 14:36:15 GMT"
   cache-control = "public, max-age=14400"
 [FrameHeader DATA stream=1 len=7261]
   "<!DOCTYPE html>\n<html>\n<head>\n<!

The nghttp2 library also includes a load testing tool called h2load which can be used a little like ab. There's a useful HOWTO on using the tool.

I ran it against the CloudFlare test server like this:

If you are testing an HTTP/2 implementation there's a useful tool called h2spec which runs through a conformance test against a real HTTP/2 server. To use it first install Go 1.5.1 and then do

$ go get github.com/summerwind/h2spec/cmd/h2spec

I only recommend it for testing locally running HTTP/2 servers. If you built nghttp2 above while building curl you will also have the nghttpd HTTP/2 server available. You can run h2spec against it like this:

$ nghttpd --no-tls -D -d /tmp 8888
$ h2spec -p 8888

h2spec will run a battery of tests against the server and output conformance information with a reference to the relevant part of RFC7540.

If you need to test a number of web sites to see which support HTTP/2 there's a tool called h2scan. Feed it a list of web sites and it will check to see if they support HTTPS, SPDY/3.1 and HTTP/2.

$ cat examples
www.cloudflare.com
www.amazon.com
www.yahoo.com
$ h2scan --fields < examples
name,resolves,port443Open,tlsWorks,httpsWorks,cloudflare,spdyAnnounced,http2Announced,spdyWorks,http2Works,npn
www.cloudflare.com,t,t,t,t,t,t,t,t,t,h2 spdy/3.1 http/1.1
www.amazon.com,t,t,t,t,f,f,f,-,-,http/1.1
www.yahoo.com,t,t,t,t,f,t,f,t,-,spdy/3.1 spdy/3 http/1.1 http/1.0

If you are working in C and need to add HTTP/2 support to a program there's the nghttp2 library that is full implementation of HTTP/2 with a simple interface. Their HTTP/2 client tutorial explains how to use the library to add HTTP/2 client capabilities. nghttp2 can also be used for servers.

Go programmers will find full HTTP/2 support will arrive with Go 1.6. If you can't wait until then there's an extension package for HTTP/2 golang.org/x/net/http2 . Details here.

There's a pure Ruby implementation of HTTP/2 available from Ilya Grigorik.

Haskell programmers can use the http2 hackage.

The popular Wireshark packet analyzer added decoding on HTTP/2 in version 1.12.0 and fully decodes HTTP/2 frames. Unfortunately most HTTP/2 is sent over TLS which means that, by default, Wireshark will not be able to decrypt the packets to be able to get to the HTTP/2 for decoding.

Fortunately, there is a workaround if you are using Google Chrome for testing. It is possible to get Chrome to save the symmetric cryptographic key used for TLS connections to a file and Wireshark is able to read that file to decode TLS connections.

This is done by setting the SSLKEYLOGFILE environment variable before running Chrome. I'm running on Mac OS X and use Google Chrome Canary for testing so I run:

% export SSLKEYLOGFILE=`pwd`/sslkey.log
% /Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary

Google Chrome will then write session keys to that file. In Wireshark I configure it to read the file by going to Preferences, expanding the Protocols list.

Then I find SSL and set the Pre-Main-Secret log filename to point to the same file.

Then Wireshark can decode the TLS connections made by that browser. Here's the beginning of a connection between Google Chrome Canary and the experimental server https://http2.cloudflare.com/.

Finally, if you are looking at the performance of your own web site it can be handy to understand which parts of the page were downloaded using HTTP/2 and which were not. You can do that pretty easily using the Developer view in Google Chrome. Here's a shot of the CloudFlare blog loaded in Chrome. There's an additional Protocol fields available on the pop-up menu.

Once added you can sort by protocol to see which parts were HTTP/2 (the h2) and which were other protocols.

1. Short introduction to HTTP/2 from CloudFlare.

2. http2 explained from the creator of curl.

3. The home page of the HTTP/2 working group with lots of information plus a list of useful tools.

Back in June 2012 CloudFlare started a beta rollout of Google's then new SPDY protocol and we took a detailed look at how SPDY makes web sites faster.

Since then we've watched carefully as SPDY has evolved through different versions and have been keeping an eye on a new Google-driven protocol called QUIC. In August 2012 we rolled out SPDY for all our customers by making it a simple (one click) configuration option.

As SPDY has progressed we've become more and more confident in the protocol and made it automatic for all our Pro, Business and Enterprise customers. No click needed. (Since SPDY runs over SSL/TLS to use it a web site must have an SSL certificate).

Last week we rolled out the most recent version of SPDY, 3.1, for all customers. SPDY/3.1 is supported by Google Chrome and Mozilla Firefox. As older versions of SPDY (particularly SPDY/2) are being deprecated it's vital for us to keep up to date.

To see whether a site is served over SPDY it's possible to use the CloudFlare Claire extension for Google Chrome. Here it's showing that the popular Hacker News site is served over SPDY.

To discover the exact version used you can dive into Chrome's chrome://net-internals where the version is shown for each connection. Here connections to Google, CloudFlare and Hacker News are all using the latest version.

A key advantage of SPDY is its ability to multiplex many HTTP request streams onto a single TCP connection. In the past, various hacks (such as domain sharding) have been used to get around the fact that only sequential, synchronous requests were possible with HTTP over TCP. SPDY changed all that.

SPDY/3 introduced flow control so that SPDY clients (and servers) could control the amount of data they receive on a SPDY connection. SPDY/3.1 extended flow control to individual SPDY streams (each SPDY connection handles multiple simultaneous streams of data). Flow control is important because different clients (think of the differences in available memory in laptops, desktops and mobile phones) will have varying limitations on how much data they can receive at any one time.

Part of the service CloudFlare provides is being on top of the latest advances in Internet and web technologies. We've stayed on top of SPDY and will continue to roll out updates as the protocol evolves (and we'll support HTTP/2 just as soon as it is practical).

The most recent web protocol we've started experimenting with is QUIC. QUIC is radically different from HTTP or SPDY because it uses UDP as its underlying transport. Currently, we have an internal QUIC server running serving a static version of the CloudFlare home page. As our experiments with QUIC progress we'll make an alpha site available for people who, like us, are interested in experimenting with bleeding edge technologies.

If you're interested in playing with QUIC today you'll need to build the test QUIC server and client that are part of the Chromium project, get Google Chrome Canary and enable QUIC in chrome://flags. You'll probably also want the latest Wireshark (the development release) which is capable of decoding QUIC frames.

And once QUIC makes the move from experimental to beta we'll be sure to make it available for our customers.

This blog post is about using headers we include in responses delivered from Railgun in order to see how it is working. We've been running Railgun on CloudFlare.com for the last few months so I'll use it as an example.

When a request is handled by Railgun, CloudFlare inserts a header with diagnostic information to track how the protocol is doing. If you want to see these headers, you'll need to use a browser that supports examining header information. Google's Chrome Browser or Apple's Safari Browser allow you to access Developer Tools (in Google, select the View > Developer > Developer Tools menu; in Safari, select the Develop > Show Web Inspector menu). In Firefox, you can install Firebug to see response headers. Microsoft's Internet Explorer makes it a bit trickier to see the response headers, but you can use a tool like Fiddler in order to expose them.

At CloudFlare, we've also made a Chrome extension for our own debugging purposes that we call Claire. When installed, it adds a small "cloud" icon to the right corner of the URL bar. If you're visiting a site that uses CloudFlare, lights up orange. Small icons under the cloud indicate whether you're using SPDY, Railgun, or IPv6 for your connection. Clicking on the icon exposes more data including information about the Railgun connection.

While Claire makes seeing the Railgun information easy, I'm going to walk through the rest of this post assuming you don't have it installed. Instead, I'll use Chrome's Developer Tools for the examples.

If you open the Developer Tools panel and click on the Network tab you'll see an interface like the one in the picture below:

Clicking on the first item in the list, which represents the dynamic HTML content that makes up the page, and then clicking on the Headers tab will show you the headers your browser sent to CloudFlare's servers as well as, if you scroll down, the response headers that your browser received back. Below is a sample of the response headers when accessing www.cloudflare.com:

There are two headers that CloudFlare is inserting in the response:

cf-railgun: e95b1c46e0 0.02 0.037872 0030 9878
cf-ray: 478149ad1570291

The second of these headers is what we call a RayID. This is a unique serial number attached to every request through the CloudFlare network, start to finish, which helps us diagnose if there's a problem at some step in our chain. If you ever have an error on your site when accessing CloudFlare, providing the RayID to our support team can help us track down the cause very quickly. The header I'm going to focus on for this post is the cf-railgun header, which I'll break down below.

The CF-Railgun header has up to five codes separated by a space. In order, these codes and their corresponding values from the example above are:

• Railgun Request ID: e95b1c46e0

• Compression Ratio: 0.02

• Origin Processing Time: 0.037872

• Railgun Flags: 0030

• Version Number: 9878

Breaking these down, the Railgun Request ID corresponds to an internal process number that allows us to track what connection handled a request in order to diagnose potential problems. Generally, you shouldn't need this value unless you're reporting a problem with your Railgun installation.

The Compression Ratio is more interesting in gauging how Railgun is down. It represents the size of the response after Railgun's delta compression expressed as a percentage. In the example above, the HTML returned for www.cloudflare.com is 0.02% of the size of the original that would be returned assuming no origin compression. Another way of thinking about this is the amount of data saved, which can be calculated by subtracting the Compression Ratio value from 100. In this case, 99.98% of the data that would have been required to generate www.cloudflare.comdoesn't need to be transmitted because of the Railgun compression.

The Origin Processing Time represents the time, in seconds, that Railgun waits for the origin web server to generate the page. In this case, the origin server takes 0.03782 seconds from when the Railgun listener sends the request to the origin to when it responds. If this number is large, it means your web server or database may be hitting a bottleneck that is slowing down its time to render the full page.

The Railgun Flags represent how a request was processed. The simplified way of looking at the Railgun Flags is to see the 4-digit sequence as zzXz. Ignore the z's and focus on the number or letter in the X position. If it is 3,7, B or F then it means Railgun Compression is working correctly.

If there is an error of some sort, the Compression Ratio is likely to be listed as "normal" or "direct." This means that Railgun's compression was bypassed for one reason or another. The Railgun Flags help diagnose why. The Railgun Flags are a bitset and, in order to fully interpret them, you need to use the rg-diag utility which is included with the Railgun packages. Run the utility from the command line with the -decode option. For example, to decode the Railgun Code 0038, for example, you'd run:

rg-diag -decode=0038

Which returns in:RailgunFlag Existing origin connection reusedRailgun Flag rg-sender sent dictionaryRailgun Flag rg-listener found dictionary

This information can be useful in diagnosing potential problems with Railgun. The good news is that the Railgun protocol is designed to be resilient. If a connection fails for some reason, in most cases it will immediately roll over to a normal HTTP or HTTPS connection without the visitor seeing an error.

Finally, returning to the cf-railgun header, the final variable is the Version Number which indicates the version of the Railgun Listener software that is running on the origin server's network. The numbers aren't necessarily sequential, so having a lower number than another Railgun Listener doesn't necessarily mean your Listener is out of date.

The Claire Chrome Plugin simplifies the header, leaving out the Railgun Flags and Version Number. Instead, it returns the Railgun Request ID (useful to provide to our support team if there's an issue), the amount of data saved for the particular request (derived from 100 - the Compression Ratio), and the Origin Processing Time (in seconds). Generally, this is all you should need to see whether Railgun is functioning as intended on your site.

Stay tuned. We'll post more information on tips for getting the most out of Railgun, as well as some of the design and engineering considerations that went into designing the protocol, over the coming days.