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 www.example.org
Download a copy of www.example.org, which we will serve locally using the quic_server binary:
mkdir /tmp/quic-data cd /tmp/quic-data wget -p --save-headers https://www.example.org
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: https://www.example.org/
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 ./generate-certs.sh cd -
In addition to the server's certificate and public key, this script will also
generate a CA certificate (
which you will need to add to your OS's root certificate store in order for it
to be trusted during certificate validation. For doing this on Linux, please see
This will allow quic_client to verify the certificate correctly. However, note
that Chrome/Chromium (the browser) does not allow custom CAs for QUIC, so you'll
also need to pass in --ignore-certificate-errors-spki-list with the
certificate's spki to allow Chrome/Chromium to accept your custom certificate as
Run the QUIC server and client
Run the quic_server:
./out/Debug/quic_server \ --quic_response_cache_dir=/tmp/quic-data/www.example.org \ --certificate_file=net/tools/quic/certs/out/leaf_cert.pem \ --key_file=net/tools/quic/certs/out/leaf_cert.pkcs8
And you should be able to successfully request the file over QUIC using quic_client:
./out/Debug/quic_client --host=127.0.0.1 --port=6121 https://www.example.org/
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 \ --origin-to-force-quic-on=www.example.org:443 \ --host-resolver-rules='MAP www.example.org:443 127.0.0.1:6121' \ https://www.example.org
Note that the server's certificate must be trusted by a default CA for
Chrome/Chromium to accept it for QUIC. If you are using a self-signed
certificate or a certificate that is signed by a custom CA, you need to use the
--ignore-certificate-errors-spki-list command line flag to trust an individual
certificate based on its SPKI. It is not possible to trust a custom CA using this
flag. If you wish to deploy a MITM proxy that intercepts traffic, you need to
block QUIC entirely and intercept TLS instead.
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.