First there was HTTP, then HTTP/2 and now HTTP/2 over the QUIC protocol. Lets have a look at the available HTTP Clients and Servers that support HTTP/2 and the experimental QUIC protocol.
Introduction
The Hypertext Transfer Protocol (HTTP) was invented in 1991. Up to 2015 then there was only little to no evolution. In 2015 the HTTP/2 protocol was defined as a standard. HTTP/2 is much more efficient that its ancestors.
It features multiplexing, stream prioritization, binary transmission and much more. Its a huge step forward.
Nevertheless, there is a need for something more efficient. HTTP/2 is using TCP (Transmission Control Protocol) which was created in the early days of the Internet to have a reliable connection over unreliable networks. Today’s networks are much more reliable which allows the usage of the unreliable but very efficient UDP (User Datagram Protocol) to transmit data. As a consequence, QUIC was born. It is using UDP instead of TCP.
QUIC includes the crypto layer, so there is no need of a separate TLS layer. The goal is to use TLS 1.3 which is not ready as of writing this post.
Both, QUIC and TLS 1.3 are currently being defined as standards, the current state of the TLS Working group is publish here, the work of the QUIC working group is vailable here.
A good overview about QUIC can be found here.
Client Software
As of writing this post, all major Browsers are supporting HTTP/2 over TCP. When it comes to QUIC, there is little left. At the moment only Chrome and Opera are capable to access web sites with QUIC.
It is expected that this will change as soon as the standard is finalized.
Web sites
I’m not aware of any prominent Website using QUIC beside of google. HTTP/2 is used by a lot of prominent sites such as facebook, google and many others.
Server Software
The situation for HTTP/2 looks good, most webservers such as Apache HTTPD, NGINX etc. come with support for HTTP/2. Well, Apache does not work with the prefork MPM, that means you can not use mod_php with HTTP/2. You can make use of FastCGI but this means that Apache will be the slowest webserver available on the market. Better use NGINX.
If it comes to QUIC support, there is an experimental NGINX module available. Unfortunately it seems to be abandoned.
An option could be the commercial LiteSpeed Server.
From my point of view, the only usable Webserver for both, HTTP/2 and QUIC is Caddy. Its a relatively new open source project implementing a lot of new and experimental technologies. A nice feature is automatic HTTPS with Letsencrypt.
Caddy Webserver
Lets have a closer look to Caddy on Fedora 27. Its quite straight forward to install and configure.
Installation
[root@f27 ~]# dnf install caddy certbot
Configuration
cat > /etc/caddy/caddy.conf << EOF :80 { gzip root /usr/share/caddy } EOF
Get a Letsencrypt Certficate
[root@f27 ~]# certbot certonly Saving debug log to /var/log/letsencrypt/letsencrypt.log How would you like to authenticate with the ACME CA? ------------------------------------------------------------------------------- 1: Spin up a temporary webserver (standalone) 2: Place files in webroot directory (webroot) ------------------------------------------------------------------------------- Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2 Plugins selected: Authenticator webroot, Installer None Please enter in your domain name(s) (comma and/or space separated) (Enter 'c' to cancel): f27.ldelouw.ch Obtaining a new certificate Performing the following challenges: http-01 challenge for f27.ldelouw.ch Input the webroot for f27.ldelouw.ch: (Enter 'c' to cancel): /usr/share/caddy/ Waiting for verification... Cleaning up challenges IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/f27.ldelouw.ch/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/f27.ldelouw.ch/privkey.pem Your cert will expire on 2018-05-31. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew"
Configure TLS
cat >> /etc/caddy/caddy.conf << EOF :443 { gzip root /usr/share/caddy tls /etc/letsencrypt/live/f27.ldelouw.ch/fullchain.pem /etc/letsencrypt/live/f27.ldelouw.ch/privkey.pem } EOF
Give the caddy user access to the cert and key
[root@f27 ~]# setfacl -m u:caddy:r-X /etc/letsencrypt/live
Enable QUIC
[root@f27 ~]# cp /usr/lib/systemd/system/caddy.service /etc/systemd/system/ [root@f27 ~]# sed -i 's#ExecStart=/usr/bin/caddy -conf /etc/caddy/caddy.conf -log stdout -root /tmp -agree#ExecStart=/usr/bin/caddy -conf /etc/caddy/caddy.conf -log stdout -root /tmp -agree -quic#g' /etc/systemd/system/caddy.service [root@f27 ~]# systemctl daemon-reload [root@f27 ~]# systemctl restart caddy
Checking the Result
Enabling QUIC in your brower
Point Chrome to chrome://flags/ and search for QUIC. Enable it and relaunch the browser.
Open Chrome and a second tab with chrome://net-internals/#quicType the URL, i.e. https://f27.ldelouw.ch. Switch the to chrome tab and see the Result.
What’s the point of installing certbot? Caddy handles the certificate negotiation itself (turned on by default).
I was somehow unable to get it work automatically
There is a mistake in the article, ngtcp2 isn’t an nginx module, it’s a library. There is apparently an “ngx_quic” module, but it’s not maintained or possibly closed source (internal Cloudflare project?).
Hi,
You are absolutely right, I mixed up something. Changed it.
Thanks,
Luc