Playing with QUIC

Build the QUIC client and server

A sample server and client implementation are provided in Chromium. To use these you should first have checked out the Chromium source, and then build the binaries:

ninja -C out/Debug quic_server quic_client

Prep test data from

Download a copy of, which we will serve locally using the quic_server binary:

mkdir /tmp/quic-data
cd /tmp/quic-data
wget -p --save-headers

Manually edit index.html and adjust the headers:

    • Remove (if it exists): "Transfer-Encoding: chunked"
    • Remove (if it exists): "Alternate-Protocol: ..."
    • Add: X-Original-Url:

Generate certificates

In order to run the server, you will need a valid certificate, and a private key in pkcs8 format.  If you don't have one, there are scripts you can use to generate them:

cd net/tools/quic/certs
cd -

In addition to the server's certificate and public key, this script will also generate a CA certificate (
net/tools/quic/certs/out/2048-sha256-root.pem) which you will need to add to your OS's root certificate store in order for it to be trusted during certificate validate. For doing this on Linux, please see these instructions.

Run the QUIC server and client

Run the quic_server:

./out/Debug/quic_server \
  --quic_response_cache_dir=/tmp/quic-data/ \
  --certificate_file=net/tools/quic/certs/out/leaf_cert.pem \

And you should be able to successfully request the file over QUIC using quic_client:

./out/Debug/quic_client --host= --port=6121

Note that if you let the server's port default to 6121, you must specify the client port because it defaults to 80.
Moreover, if your local machine has multiple loopback addresses (as it would if using both IPv4 and IPv6), you have to pick a specific address.
It remains to be determined whether the latter shortcoming is a bug.

If the server you are connecting to does not have a trusted certificate, use the --disable_certificate_verification flag on the client to disable certificate verification. If the server's certificate is trusted but chains to a user installed CA (e.g. a CA generated by the script mentioned above), use the --allow_unknown_root_cert flag on the client to allow connections where the cert chains to a user installed CA.

note: both the client and server are meant mainly for integration testing: neither is performant at scale!

To test the same download using chrome, 

chrome \
  --user-data-dir=/tmp/chrome-profile \
  --no-proxy-server \
  --enable-quic \ \
  --host-resolver-rules='MAP' \

Remember that the server's certificate must be trusted for Chrome to connect to it. If you followed the steps in "Generate certificates" above and added the generated CA cert to your OS's root store, you don't need to take any other action. If you have not done that, you can use the --ignore-certificate-errors-spki-list command line flag to trust an individual certificate based on its spki.


If you run into troubles, try running the server or client with --v=1.  It will increase the logging verbosity and the additional logs will often help expose the underlying problem.