The QUIC protocol is an effort by Google to address some shortcomings of the current Web protocols. The basic HTTP protocol is unsecured, and so HTTPS exists to add a secure layer to the web. HTTPS allows only one request at a time, so browsers make multiple connections to allow fetches to run in parallel. Using multiple connections doesn’t work well with network address translation, so HTTP(S)/2 was designed to multiplex requests into one session. But after all this, the connection establishment time was way up with security exchanges, and the multiplexed Web traffic suffers a “head of queue” problem in that one misplaced packet for one Web resource will block all other Web resources from completing until that packet has been retransmitted and received.
QUIC solves these problems with a very fast handshake mechanism for servers that the browser has already visited in the past, with a user-level multiplexing methodology that allows out-of-order packets for different resources to be processed, and with room to experiment on other features of network traffic such as congestion control and client devices changing IP networks.
QUIC has been in Chrome for some years now, but for most of that time Google has used a compiled-in white list of servers allowed to offer QUIC service. However, Chrome versions 52 and 53 will allow you to run your own QUIC service if you like.
A pre-canned server exists in the form of Caddy, which is easy to run, and which will even work with Let’s Encrypt to automatically provision a valid x509 certificate for your web server. The future is now!
But if you’d prefer to just see QUIC in action, here’s a few simple steps you can take.
First, make yourself a junk certificate.
$ openssl genrsa -out socat.key 1024
... (low quality key is made) ...
$ openssl req -new -key socat.key -x509 -days 3650 -out socat.crt
... (low quality certificate is made) ...
$ cat socat.{key,crl} > socat.pem
Next, create yourself an HTTP response in a file:
$ cat > response.txt HTTP/1.1 200 OK alt-svc:quic=":443"; ma=2592000; v="36,35,34" content-length:23 content-type:text/html; charset=utf-8 connection:close Quic, look over there! $
Then, run an “http server”:
$ socat -vv OPENSSL-LISTEN:443,crlf,reuseaddr,cert=socat.pem,verify=0,fork \
SYSTEM:"cat response.txt"
This will listen on port 443 of all interfaces on your machine, respond using the junk certificate you created, and simply echo the contents of the file no matter what is sent to it.
Next, in a separate terminal, run a “quic server”:
$ socat udp-listen:443 stdout
This will listen on UDP port 443, and display what it receives to the console, without responding.
Finally, fire up Chrome 52+, and browse to https://127.0.0.1/. This must be over HTTPS, and it must be on the standard port 443, else Chrome will not use QUIC (try running a tcp-listen “server”, or a different port!). Skip past the certificate warning, and see your “response” in the browser. If you look in the terminal with your UDP server, you will see five attempts by Chrome to initiate a QUIC session, the last of which includes a reset message like “No recent network activity.”
You can look inside Chrome’s workings by viewing the network internals. There’s one tab showing the alternative service mappings and their status at chrome://net-internals/#alt-svc, and one for the current QUIC sessions, though you’ll have to reload a Google (or Caddy) service to see anything there, as QUIC sessions expire after 30 seconds of inactivity.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.