QUIC: What is behind the ex­per­i­men­tal Google Protocol?

Thanks to even faster DSL access, Internet site load times have reduced con­sid­er­ably. 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 en­cryp­tion is becoming in­creas­ing­ly important: the HTTPS-Standard is a trusted ally when it comes to pro­tect­ing user privacy, but a TLS handshake, cer­tifi­cate, and key exchange will result in ad­di­tion­al delays in the loading process. Google’s QUIC protocol will solve this problem.

QUIC is an ex­per­i­men­tal protocol, created by search engine giant Google and in­tro­duced to the public in 2013. The name stands for ‘Quick UDP Internet Con­nec­tions’, which is due to the fact that it allows the fast and easy sending of simple packets over the con­nec­tion-less User Datagram Protocol (UDP). The reason for de­vel­op­ing QUIC was a desire to provide an al­ter­na­tive to the es­tab­lished security solution TCP, HTTP/2 and TLS/SSL by de­vel­op­ing the same pro­tec­tion but with a reduced con­nec­tion and transport delay, and allowing mul­ti­plex­ing con­nec­tions. Google has designed QUIC like this so that the protocol itself controls the con­nec­tion. During the first handshake between sender and receiver, they exchange the cer­tifi­cates and keys needed to encrypt the sent datagrams. Later com­mu­ni­ca­tions eliminate this exchange, which minimizes latency. The en­cryp­tion protocol is the current, speed-optimized TLS version 1.3 (stan­dard­ized in March 2017), which is preferred over the in-house crypto solution. When it comes to mul­ti­plex­ing, the QUIC protocol follows the Google-developed SPDY protocol, which provided the template for HTTP/2: a single client-server con­nec­tion which can be used to transmit several different data streams, reducing load time sig­nif­i­cant­ly.

Some important features and ad­van­tages of QUIC have already been mentioned, but here they will be discussed in greater detail, and with reference to further im­prove­ments. TCP, which plays a major role as a pioneer in the concept of the emerging transport protocol, serves as a good protocol com­par­i­son. However, it is clearly inferior to the Google protocol in some respects, as the following guide will il­lus­trate: 

The main aspect of per­for­mance that gives QUIC an advantage over TCP is that the con­nec­tion setup is much faster. Even without en­cryp­tion via SSL/TLS, a con­nec­tion using the tra­di­tion­al transport protocol with the ‘three-way-handshake’ takes more steps than the UDP-based Google solution. QUIC will start a con­nec­tion with a single packet (or two packets if it is the first con­nec­tion), and will even transmit all necessary TLS or HTTPS pa­ra­me­ters. 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 ac­knowl­edge­ment.

TCP uses the TCP ports and IP addresses of connected systems to identify a con­nec­tion. Because of this, it is not possible for a client to com­mu­ni­cate with the server over multiple ports in a single con­nec­tion. The QUIC protocol solves the situation in a different way: it uses 64-bit con­nec­tion detection and various ‘streams’ to transport data within a con­nec­tion. Therefore, a QUIC con­nec­tion is not nec­es­sar­i­ly bound to a specific port (in this instance a UDP port), an IP address or a specific endpoint. As a con­se­quence, port and IP changes are both viable options, as is the pre­vi­ous­ly described multiplex con­nec­tion.

Each data segment of a QUIC con­nec­tion receives its own sequence number, re­gard­less 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 dis­tinc­tion. Con­tin­u­ous­ly tagging the packets is ad­van­ta­geous because it allows a more accurate round trip time (RTT) estimate. 

Lost packets do not present a big problem when trans­port­ing data over QUIC. Thanks to a simple XOR-based error cor­rec­tion system, it is not necessary to resubmit the cor­re­spond­ing data. These can be con­struct­ed at any time using FEC (Forward Error Cor­rec­tion) packages – backups of the original packages for a data group. However, error cor­rec­tion 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 con­nec­tion, but is also as­so­ci­at­ed with a certain loss rate. If a packet is lost, the re­trans­mis­sion (TCP Fast Re­trans­mit) is initiated quickly. For this purpose, however, TCP tem­porar­i­ly reduces the size of the boutique window, which often results in the data being trans­mit­ted in­ter­mit­tent­ly. The QUIC protocol coun­ter­acts these load peaks with ‘packet pacing’. This procedure ensures that the trans­mis­sion rate is au­to­mat­i­cal­ly limited. So, even with low bandwidth con­nec­tions, 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. De­vel­op­ers have also pri­or­i­tized 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 au­then­ti­ca­tion. Man-in-the-middle-attacks are not uncommon as a result. However, QUIC packages are always au­then­ti­cat­ed and largely encrypted (including payload). The parts of the header that are not in encrypted form are protected from injection and tampering by au­then­ti­ca­tion 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 re­spec­tive platforms or devices to be able to com­mu­ni­cate, QUIC support is only required at ap­pli­ca­tion level. It is up to the in­di­vid­ual software companies to integrate the software – they are not dependent on hardware man­u­fac­tur­ers. To date, it is mainly Google ap­pli­ca­tions like Google servers or Google Chrome that have QUIC im­ple­ment­ed. However, programs like the browser Opera, Caddy server software, and LiteSpeed Tech­nolo­gies’ load balancing and web server products already have third-party ap­pli­ca­tions which enable con­nec­tions through the new transport protocol.

The fact that QUIC is likely to become more popular is thanks to IETF’s com­mit­ment. With ad­just­ments 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 op­ti­miza­tion 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 au­then­ti­ca­tion and en­cryp­tion provide a more secure method of transport for data, they are also re­spon­si­ble for one of QUIC’s major drawbacks: Since the packet headers contain less plain text in­for­ma­tion than those with TCP con­nec­tions, tasks like trou­bleshoot­ing, traffic reg­u­la­tion, or network man­age­ment become more difficult with QUIC con­nec­tions. Because of this, network operators and firewall man­u­fac­tur­ers among others find it difficult to ensure the quality of their product.

Another problem with the QUIC protocol is that automatic con­ges­tion control on high-bandwidth data con­nec­tions may result in poorer trans­mis­sion rates in some cases.

If you want to de­ac­ti­vate 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 re­ac­ti­vate the protocol, proceed in the same way, but select either ‘Default’, or ‘Enabled’.