On 27 May 2021 the technical standards of the QUIC transport layer network protocol were published. In due course QUIC could replace many of the uses of the old TCP protocol, particularly on the Web.
But in order to understand the role played by QUIC on the Internet, we must first take another quick look at what a transport protocol is for. If you’ve taken IT network courses and had difficulty assimilating the “OSI” layer model, don’t worry. It’s just a model, and it’s a practical way of splitting a course up into chapters for example, but it isn’t necessary in real networks. What you have to remember is simply that in order to be able to read this article on the Web, you’ve had to use several services on the way, which we generally think of as being in successive layers, the ones at the top being the nearest to the user. So for example the Application layer is the browser you’re using at the moment, the Physical layer consists of the wires and cables you can see. Between these two, the Internet uses two important layers, the Network layer, which has the task of directing little units of information, packets, and the Transport layer, which reconstitutes data that can be used by humans from these packets. The Internet network layer is the Internet Protocol (IP). The packets that it manages, which come from the cutting up of the data sent, may not arrive (a physical network can never guarantee that everything will go according to plan) or may arrive in a disorderly fashion. So we cannot make direct use of what the Network layer provides. We need to add what we call a Transport layer, to verify that all the packets arrive, reclaim any missing ones and put them back in the right order. The Internet allows the coexistence of several transport protocols, since this concerns only the two machines that are communicating. But traditionally it is the TCP (Transmission Control Protocol) that has dominated. It is used by the vast majority of applications, the main exceptions being the DNS (Domain Name System) and certain audio and video applications. It is for this reason that the set of protocols that make the Internet work is often referred to as “TCP/IP”.
TCP is a masterpiece of engineering which, for the past forty years, has circulated colossal quantities of data on the Internet and works on all machines, from the cheapest smartphone to the largest servers. But the way the Internet is evolving has revealed the limitations of the TCP, at least for certain uses. Hence the development in the past few years of the QUIC protocol (a name, not an acronym). It has now been standardised, in four documents, RFC (Request for Comments) 8999, 9000, 9001 and 9002. Since QUIC is a transport protocol and not an application, the ordinary user will not see any obvious difference, but behind the screen the changes may have significant consequences.
What does QUIC do that’s different from TCP? There are numerous differences between the two protocols, too many for me to mention them all here. Let us concentrate on the main ones – first of all the encryption. In view of the extent of the surveillance carried out of the Internet by numerous actors, encryption is an indispensable security tool. At present when we use TCP, encryption is generally provided by the TLS (Transport Layer Security) protocol. The two machines that are communicating must first initiate a TCP session and only then a TLS session. This increases latency, the response time, and this latency is often the dominant factor in the user’s perception of slowness (whereas ads rather highlight network capacity, without ever mentioning latency). Unlike TCP, QUIC merges transport and encryption. QUIC is never unencrypted, everything is systematically encrypted, and the encrypted session is initiated at the same time as the transport session, reducing latency. Also, to hinder surveillance, QUIC even encodes a part of its own operation, which TCP left in the clear.
QUIC also increases parallelisation of requests, which is an advantage especially for the Web. Indeed a single web page can automatically trigger the loading of numerous resources, such as style sheets or images. TCP meant you had to download documents one by one, thus increasing latency , or meant the opening of several TCP sessions which could then no longer share the complex calculations needed for proper operation of the Transport layer. QUIC allows several resources to be loaded within the same session without them slowing one another down.
Lastly (but remember that QUIC has many other functions, not all of which I can present here), QUIC allows you to change IP address in the middle of a session, for example if a smartphone switches from 4G to WiFi or vice-versa, the QUIC sessions under way will not be interrupted.
QUIC is a transport protocol, not an application. For typical uses such as the Web, application protocols must be added to it. In the case of the Web, this will be the new version of HTTP (HyperText Transfer Protocol), HTTP/3, which will be the first version to run on QUIC. Its standardisation is currently in the process of being finalised. Here again if you are simply a user, you will not have to change anything, the external functioning will be the same. The HTTP/3 client (your browser) understands HTTP/3 and can revert automatically to an older version of HTTP if the remote server does not use HTTP/3 or if an over-zealous firewall blocks QUIC.
The development of QUIC started several years ago and today several services, such as Google, are already accessible with QUIC. The Chrome and Firefox browsers already have QUIC, albeit not necessarily in the version installed on your machine; you may have to wait a little. The effective deployment of QUIC will be carried out in the coming years, but of course it is not expected to completely replace TCP, which will continue to serve the Internet well, as it has since 1981 when its standard first appeared.
So what about Afnic? Remember that QUIC is designed above all for the Web and optimised for it. Services such as EPP (Extensible Provisioning Protocol, presented in my article on the registration of domain names) which do not require parallel requests (on the contrary, they have to respect the order of requests) or reduced latency (since EPP sessions are typically very long) have no particular need for QUIC. The DNS could use the parallel requests capabilities of QUIC, and a DNS running on QUIC is in the process of being standardised (Afnic is taking part in this in the framework of its involvement in open standardisation). That said, DoQ (DNS over QUIC) does not seem very near. The first Afnic protocol to benefit from QUIC is perhaps more likely to be RDAP (Registration Data Access Protocol, the successor to Whois), which runs on HTTP and could benefit from parallelisation and reduced latency. But nothing has been decided yet, the software application libraries needed for QUIC in many cases not yet being available in stable versions of the typical operating systems.
In summary, we are at the dawn of a new era, which will perhaps see a change in the dominant transport protocol of the Internet. And you don’t see that every day!