QUIC, short for Quick UDP Internet Connections, also known as HTTP-over-QUIC is about to be renamed HTTP/3 to “clearly identify it as another binding of HTTP semantics to the wire protocol.” Since, most websites are not even using HTTP/2 features, let us try to understand why IETF is releasing yet another HTTP protocol specification.
HTTP is the foundation of main method of communication for the World Wide Web. The first documented version of HTTP was 0.9. HTTP Working Group wanted to expand the protocol with extended operations, extended negotiation, richer meta-information, tied with a security protocol which became more efficient by adding additional methods and header fields. In 1996, RFC1945 officially introduced HTTP version 1.0. The following year, the next generation of HTTP protocol was released dubbed HTTP/1.1. It came with support for HTTP pipelining, keep-alive connections, better caching, chunked transfer encoding, improved compression and much more.
Sometime in 2011, after HTTP/1.1 was already released, and before the release of HTTP/2 specifications, IETF ratified the release of WebSocket protocol. WebSockets allow developers to implement persistent connection open to the server. Further, WebSockets enable the server to push data over established connections whenever it is needed, rather than wait for a polling request from the client.
HTTP/2 was officially released as a standard in May of 2015, is a derivation of the Google’s experimental SPDY protocol. The goal behind SPDY development was to reduce page load times. HTTP/2 is fully backwards compatible with HTTP 1.x, meaning that no changes are required to existing applications, yet new applications could take advantage of the new HTTP/2 features. HTTP/1.1 is a half-duplex stateless request-response protocol, meaning that for every request the clients have to initiate a connection to the server, introduce themselves, authenticate if needed, and request the resource.
The main difference between HTTP/2 and the previous HTTP/1.1 is the addition of the full-duplex two-directional communications. All communications in HTTP/2 are carried over a single TCP connection, which could carry any number of bi-directional streams. Each steam can carry one or more messages containing an HTTP request or response.
HTTP/2 made WebSockets obsolete for most purposes, by offering full-duplex connections support as a part of the HTTP protocol, and adding multiplexing. Further, WebSockets protocol semantics make it extremely difficult to develop secure applications. The latest CVE-2018-1002105 vulnerability being just one example of WebSockets presenting a major security concern. In fact, Websockets and upgrades are notorious for vulnerabilities since they enable a direct TCP connection between clients and servers that can be hijacked through several mechanisms. The above, in conjunction with the fact that WebSocket monitoring is difficult, in general, make WebSockets a poor architectural choice. Software architects are encouraged to look for alternatives, and avoid employing WebSockets whenever possible – pretty much always.
While HTTP/2 adds full duplex communications with multiplexing, improving the server-push support, it still comes short of addressing one the core issues with HTTP protocol – head of line blocking. In fact, HTTP 2.0 is even more vulnerable to this phenomenon, because HTTP/2 transmits all the data over the same TCP connection. When HTTP/2 loses just one packet, the whole communication line with the server is blocked, whereas with HTTP 1.1 only one of multiple parallel TCP connections is blocked.
Further, as richer web experience made network loads heavier in terms of both average page and average flow sizes, TCP protocol itself stayed the same. In the meantime, we need to support more advanced scenarios, including: high-availability, link aggregation, multihoming and mesh networking.
HTTP/3 is a new transport built on top of UDP, which reduces latency compared to that of previous HTTP versions built on TCP.
HTTP/3 connections start with a client, typically a web browser, making a request using HTTPS over TCP/TLS. The server terminating the TCP connection will include an alternative services header “Alt-svc” containing an indication that QUIC is supported by the server along with the QUIC versions that the server supports and a max-age “ma” – the QUIC equivalent of a TTL for the Alt-svc. The client will cache the Alt-svc header for the specified “ma”. In Chrome, you can review the cached Alternate Service Mappings via chrome://net-internals/#alt-svc. If an Alternate Service Mappings record exists on the client for the target origin, the client will attempt to use QUIC to establish a connection to the server on subsequent requests. Successful QUIC connection can be identified by the presence of “http/2” and “quic/<version>” in the protocol field.
Promised HTTP/3 benefits include:
Dramatically reduced connection establishment time
Better security through mandatory encryption
Improved congestion control
Multiplexing without head of line blocking
Forward error correction
Reduced bandwidth consumption
When use HTTP/3?
Google has been using QUIC for quite some time, and majority of all requests from Chrome to Google servers are served over QUIC. Chromium’s network stack opens both a QUIC and traditional TCP connection at the same time, which allows it to fallback with zero latency.
Once HTTP/3 is widely supported, probably in a couple of years at most, we expect it to be deployed everywhere. Since HTTP/3 is more capable of dealing with packet-loss, it will shine in networks with higher packet-loss, such as mobile. The benefits HTTP/3 brings are going to be especially apparent when it comes to rich-media and real-time communications. Many leading websites including Google, Youtube and Netflix and, as well as top internet services including Akamai and Cloudflare are already running QUIC.
While HTTP/3 is potentially more secure than older HTTP versions since it enforces encryption. However, because HTTP/3 is a new transport protocol, rebuilt from the network stack and up, firewalls are currently unable to perform application-level analysis of HTTP/3 traffic, such as web filtering or deep packet inspection. The real world implications of QUIC traffic on corporate networks range from not being able to restrict access to YouTube or enforce Google Safe Search, to malware or ransomware being downloaded through Gmail or any other QUIC enabled website. Therefore, we expect many enterprises to block and/or continue blocking HTTP/3 traffic on their networks, until the time when HTTP inspection tools had a chance to catch-up with technology.