I was recently working our our code that processes HTTP/2 traffic and ran into a problem. I believed I was interpreting the HTTP/2 traffic correctly, but the client I was sending it to told me to go away. It literally told me to do that. The HTTP/2 specification has a packet type of GOAWAY!
The normal way to resolve this type of issue is to inspect the traffic using Wireshark. I can take a capture, see how it’s interpreting each byte and compare with how my code is interpreting it.
However, HTTP/2 is pretty much always tunneled over TLS, which makes this type of examination in Wireshark a bit of a pain. I then discovered nghttpx. This is a reverse proxy server that receives HTTP/2 traffic from a broswer and sends it on to another server which may or may not support the standard.
This is great if you have a web server that doesn’t support HTTP/2, but you want to avail of its benefits. However, that’s not what I was using it for. Nghttpx allows me to make raw HTTP/2 requests without having to use TLS. This means that I can examine the traffic directly using Wireshark. And, lo and behold, I was incorrectly reporting the size of an HTTP/2 frame that I’d modified. Reason enough for the server to tell me to go away!
Setup
This was straight-forward on my Debian environment. The instructions for other Linux distributions should be similar.
apt update
apt install nghttp2-proxyI then needed to modify /etc/nghttpx/nghttpx.conf
frontend=0.0.0.0,3000;no-tls
backend=my_web_server_ip,80I then restarted the service with systemctl restart nghttpx.service
This configuration means that I can send HTTP/2 traffic to this proxy on port 3000. For example using cURL.
curl --http2 -v http://MY_PROXY_SERVER:3000Nghttpx sends my request on to MY_WEB_SERVER and I can use Wireshark to examine what’s going on without needing to set up decryption.
Comparing HTTP/1 and HTTP/2 Packets
While we have access to Wireshark data, it would be a shame not to look at how the two protocols compare….
The screenshot on the left is that for the HTTP/1.1 conversation and the screenshot on the right is for the HTTP/2 conversation.
We can see from this that using HTTP/2 results in a conversation that is 107 bytes shorter and uses less bandwidth. The reason for this is due to HTTP header compression. The HTTP/2 conversation uses a compressed binary format for its headers which can result in dramatic space reduction.
It should be noted that bandwidth saving is one of several improvements that HTTP/2 has over HTTP/1.1. Other improvements such as multiplexing and server push functionality don’t affect bandwidth, but results in web pages being more responsive.
Can We Save Even More Bandwidth?
You will note from the first screenshot above that the actual HTML payload looks exactly the same on both versions of HTTP. In most cases, this is much bigger than the size of the headers, so the bandwidth savings in many cases are extremely small and could be considered negligible.
Replify Accelerator can optimize HTTP/2 traffic using several techniques. Our dedicated protocol handler can inspect HTTP/2 traffic and identify the headers and payload. We know that HTTP/2 header compression is very efficient, and we don’t try and improve on this. However we also know that the payload is plain text and that it can be compressed. This results in further bandwidth savings.
In this example, it brings the size of the conversation down to 932 bytes which is a 41% further saving. However for larger payloads with repeated data, our caching technology will also be used and the savings would be even more dramatic.
If you want to find out more about Replify Accelerator and how it can help you optimize your web traffic, please contact us at sales@replify.com