QUIC: What is behind the experimental Google Protocol?

Thanks to even faster DSL access, Internet site load times have reduced considerably. As a result, fast page-loading is now taken for granted, meaning that slow-loading websites have little chance of surviving in the market. To make matters worse, the subject of encryption is becoming increasingly important: the HTTPS-Standard is a trusted ally when it comes to protecting user privacy, but a TLS handshake, certificate, and key exchange will result in additional delays in the loading process. Google’s QUIC protocol will solve this problem.

QUIC is an experimental protocol, created by search engine giant Google and introduced to the public in 2013. The name stands for ‘Quick UDP Internet Connections’, which is due to the fact that it allows the fast and easy sending of simple packets over the connection-less User Datagram Protocol (UDP). The reason for developing QUIC was a desire to provide an alternative to the established security solution TCP, HTTP/2 and TLS/SSL by developing the same protection but with a reduced connection and transport delay, and allowing multiplexing connections. Google has designed QUIC like this so that the protocol itself controls the connection. During the first handshake between sender and receiver, they exchange the certificates and keys needed to encrypt the sent datagrams. Later communications eliminate this exchange, which minimises latency. The encryption protocol is the current, speed-optimised TLS version 1.3 (standardised in March 2017), which is preferred over the in-house crypto solution. When it comes to multiplexing, the QUIC protocol follows the Google-developed SPDY protocol, which provided the template for HTTP/2: a single client-server connection which can be used to transmit several different data streams, reducing load time significantly.

Some important features and advantages of QUIC have already been mentioned, but here they will be discussed in greater detail, and with reference to further improvements. TCP, which plays a major role as a pioneer in the concept of the emerging transport protocol, serves as a good protocol comparison. However, it is clearly inferior to the Google protocol in some respects, as the following guide will illustrate: 

The main aspect of performance that gives QUIC an advantage over TCP is that the connection setup is much faster. Even without encryption via SSL/TLS, a connection using the traditional transport protocol with the ‘three-way-handshake’ takes more steps than the UDP-based Google solution. QUIC will start a connection with a single packet (or two packets if it is the first connection), and will even transmit all necessary TLS or HTTPS parameters. In most cases, a client can send data directly to a server without relying on a response, while TCP must first obtain and process the server’s acknowledgement.

TCP uses the TCP ports and IP addresses of connected systems to identify a connection. Because of this, it is not possible for a client to communicate with the server over multiple ports in a single connection. The QUIC protocol solves the situation in a different way: it uses 64-bit connection detection and various ‘streams’ to transport data within a connection. Therefore, a QUIC connection is not necessarily bound to a specific port (in this instance a UDP port), an IP address or a specific endpoint. As a consequence, port and IP changes are both viable options, as is the previously described multiplex connection.

Each data segment of a QUIC connection receives its own sequence number, regardless of whether it is an original or a forwarded segment. By default, TCP does not do this, which is why a host cannot determine the status of a sequence – only in using a timestamp extension can the classic transport protocol allow that kind of distinction. Continuously tagging the packets is advantageous because it allows a more accurate round trip time (RTT) estimate. 

Lost packets do not present a big problem when transporting data over QUIC. Thanks to a simple XOR-based error correction system, it is not necessary to resubmit the corresponding data. These can be constructed at any time using FEC (Forward Error Correction) packages – backups of the original packages for a data group. However, error correction does not work if several packages from a data group are missing.

TCP always tries to send data as fast as possible, which is an advantage in terms of having a fast data connection, but is also associated with a certain loss rate. If a packet is lost, the retransmission (TCP Fast Retransmit) is initiated quickly. For this purpose, however, TCP temporarily reduces the size of the boutique window, which often results in the data being transmitted intermittently. The QUIC protocol counteracts these load peaks with ‘packet pacing’. This procedure ensures that the transmission rate is automatically limited. So, even with low bandwidth connections, there is no overload. However, this is not a new technique: some Linux kernels also use the method for the TCP protocol.

Safety has been a key aspect in the planning and design of QUIC right from the very beginning. Developers have also prioritised finding a solution to one of TCP’s biggest issues: the header on a sent packet is in plain text and can be read without prior authentication. Man-in-the-middle-attacks are not uncommon as a result. However, QUIC packages are always authenticated and largely encrypted (including payload). The parts of the header that are not in encrypted form are protected from injection and tampering by authentication on the receiver’s end. 

Another major advantage of QUIC over TCP is that the Google protocol is detached from the system. While TCP needs support from the respective platforms or devices to be able to communicate, QUIC support is only required at application level. It is up to the individual software companies to integrate the software – they are not dependent on hardware manufacturers. To date, it is mainly Google applications like Google servers or Google Chrome that have QUIC implemented. However, programs like the browser Opera, Caddy server software, and LiteSpeed Technologies’ load balancing and web server products already have third-party applications which enable connections through the new transport protocol.

The fact that QUIC is likely to become more popular is thanks to IETF’s commitment. With adjustments to common standards since the group’s inception in 2016, the protocol has evolved from a Google-centric to a common network protocol. However, the optimisation process is far from over: the QUIC team continues to address existing issues which still require the right solution.

One of the most important issues still facing the QUIC protocol is security. While authentication and encryption provide a more secure method of transport for data, they are also responsible for one of QUIC’s major drawbacks: Since the packet headers contain less plain text information than those with TCP connections, tasks like troubleshooting, traffic regulation, or network management become more difficult with QUIC connections. Because of this, network operators and firewall manufacturers among others find it difficult to ensure the quality of their product.

Another problem with the QUIC protocol is that automatic congestion control on high-bandwidth data connections may result in poorer transmission rates in some cases.

If you want to deactivate the protocol, just click ‘Disabled’ and then click ‘Start Now’. Chrome will then close, but the next time you start your browser, the new settings will be activated. If you want to reactivate the protocol, proceed in the same way, but select either ‘Default’, or ‘Enabled’.