HTTP/2 is a major update to the HTTP 1.x protocol and I decided to spare some time to have a general idea what it is all about:
Here are my findings:
- It’s based on SPDY (a protocol developed by Google, currently deprecated)
- It uses same methods, status codes etc. so it is backwards-compatible and the main focus is on performance
- The problem it is addressing is HTTP requiring a TCP connection per request.
- Key differences:
- It is binary rather than text.
- It can use one connection for multiple requests
- The protocol doesn’t have built-in encryption but currently Firefox, Internet Explorer, Safari, and Chrome agree that HTTPS is required.
- There will be a negotiation process between the client and server to select which version to use
- WireShark has support for it but Fiddler doesn’t.
As the speed is the main focus it’s especially important for CDNs to support it. In September 2016, AWS announced that they now support HTTP/2. For existing distributions it needs to enabled explicitly by updating the settings.
On the client side looks like it’s been widely adopted and supported. CanIUse.com also confirms that it’s only allowed over HTTPS on all browsers that support it.
What Does It Look Like on the Wire
As it’s binary I was curious, as a developer, to see what the actual bits looked like. Normally it’s easy to inspect HTTP requests/responses because it’s just text.
Apparently the easiest way to do it is WireShark. First, I had to enable session logging by creating a user variable in Windows:
and pointing the WireShark to use that log (Edit -> Preferences -> Protocols -> SSL)
This is a very neat trick and it can be used to analyse all encrypted traffic so it serves a broader purpose. After restarting the browser and WireShark I was able to see the captured session keys and by starting a new capture with WireShark I could see the decrypted HTTP/2 traffic.
It’s hard to make sense of everything in the packets but I guess it’s a good start to be able to inspect the wire format of the new protocol.