The ever faster access to the Internet with DSL has generally reduced the loading time of Internet pages . As a result, it is now assumed that pages need to open quickly when visited, so slow-loading web projects have little chance of survival. The situation is further complicated by the increasing importance that encryption is acquiring: the HTTPS standard has proven to be a strong ally to protect the privacy of users, but it has as a consequence the additional delay of the upload process through the handshake protocol TLS and the exchange of certificates and keys, a situation that must be solved by the QUIC protocol initiated by Google..
QUIC is an experimental transport protocol by Google published in 2013. The name is derived from? Quick UDP Internet Connections ?, which is because it enables the sending of simple data packets through the UDP (User Datagram Protocol) or user datagram protocol, which does not need a connection . The backdrop for the work at QUIC was the desire to develop an alternative to established security solutions based on TCP, HTTP / 2 and TLS / SSL that offer the same protection, but also a reduced delay in connection and in transport, and enables multiplexed connections.
For this reason, Google has designed QUIC so that the same protocol regulates the control of the connection. In the first connection agreement (handshake) between sender and receiver, they exchange the certificates and keys necessary for the encryption of the datagrams sent. This exchange is not applied in subsequent communications, which reduces latency. The encryption protocol is the current TLS 1.3 version with optimized speed (standardized version in March 2017), which obtained preference over its own cryptographic solution. In terms of multiplexing , QUIC is oriented to the SPDY protocol developed by Google, which served as a model for HTTP / 2: data streams are sent through a single client-server connection, thus reducing load time..
Since 2016, there has been an official IETF working group in charge of optimizing the QUIC protocol. Around 50 developers from Google, Mozilla, Microsoft and other companies, led by Lars Eggert and Mark Nottingham, are involved in the development and expansion of the specification. On Google servers the protocol already used for several years (2013) ago. In addition, QUIC has also been implemented in Chrome , the home browser, so that some of the Internet traffic (eg YouTube) is currently handled through the advanced transport protocol.
Some important features and benefits of QUIC have already been highlighted , but here are a number of other enhancements . To do this, we will take as a reference the TCP protocol, which plays an important role as a precursor to the concept of the new transport protocol but is somewhat below the Google protocol, as the following advantages of QUIC make clear..
The main reason for the superior performance of QUIC over TCP is its speed in establishing a connection. Even without SSL / TLS encryption, the connection through the classic transport protocol takes more steps with the three-way handshake than Google's UDP- based solution . QUIC initiates a connection with a single packet (or two packets if this is the first time the connection is established) and transmits all the necessary TLS or HTTPS parameters to them. In most cases, a client can send data directly to a server without the server having to send a response, while TCP must obtain and process the acknowledgment from the server.
TCP uses the TCP ports and IP addresses of connected systems to identify connections. Thus, it is not possible for a client to communicate with the server through multiple ports in a single connection. The QUIC protocol solves the situation differently by resorting to a 64-bit connection identification and different? Streams? to transport the data in a connection. QUIC connections are not bound to a specific port (in this case UDP port), an IP address, or a specific endpoint. The modification of ports and IP addresses is, as a consequence, just as possible as the aforementioned multiplexed connections .
Each data segment of a QUIC connection gets its own sequence number regardless of whether it is an original segment or a forwarded segment . TCP does not make this distinction, so a host cannot determine the state of a stream either. Only the use of a time stamp extension (timestamp) allows the classic transport protocol such a distinction. Continuous packet marking is therefore an advantage as it enables a more accurate estimation of the packet travel time (RTT).
Lost packets are a big problem when transporting data with QUIC. Thanks to an error correction system based on XOR, a new transmission of the data is not necessary, since these can be reconstructed at any time with the help of FEC (Forward Error Correction) packages, backup copies of the original packages for a group of data. Error correction does not work, however, when multiple packets are missing from a data group.
TCP always tries to send data as fast as possible, which contributes to the speed of connections but is also associated with a certain rate of loss. If a packet is lost, a new transfer is started (TCP fast retransmit). To do this, TCP temporarily reduces the viewing window, which has the consequence that the data is transmitted in pulses. The QUIC protocol counteracts such load peaks with the help of so-called packet pacing. This procedure ensures that the transfer rate is automatically limited , so that overloads are avoided on connections with low bandwidth. However, this technique is not new, as some Linux kernels use this method for the TCP protocol.
Security has been an essential aspect from the beginning in the planning and conception of QUIC and, in the process, the developers have dealt with one of the biggest problems of TCP: the header of the sent packets is written in plain text and can be read without the need for authentication. Man-in-the-middle attacks and packet manipulations (such as sequence numbers) are not extraordinary. QUIC packets are always authenticated and in general they are usually encrypted (even the payload). Also, authentication by the recipient makes parts of the header that are not presented in encrypted form protected from injection and tampering.
Another great advantage of QUIC over TCP is that the Google protocol does not depend on the system . While devices and platforms must support the TCP protocol to enable communication, QUIC support is only required at the application layers. For this reason, in principle it is the software companies that integrate the protocol without depending on the hardware manufacturers. To date, it is mostly Google applications such as Google servers, Chromium or Chrome, which have implementations for QUIC, but with the Opera browser, Caddy server software and load balancing products and web servers from LiteSpeed Technologies also exist third-party applications that allow connections through the new transport protocol.
The potential for QUIC to be used more and more in the future is largely due to the commitment of the IETF. Thanks to the adjustments in the general standards made since the creation of the working group in 2016, the protocol has gone from being strongly adapted to Google to becoming a general network protocol that is gaining in relevance. However, the optimization process is not yet complete : the QUIC team continues to address existing problems for which the right solutions need to be found.
Specifically, the issue of security , one of the most important in the development of the protocol, raises great debates. While authentication and encryption undoubtedly take care of a secure data transport, these two factors are also responsible for a decisive disadvantage of QUIC: because packet headers contain less information in clear text than in connections TCP, tasks such as troubleshooting , traffic regulation or network management in QUIC connections are noticeably complicated . Both network operators and manufacturers of firewalls and other intermediate boxes (middleboxes) find it difficult to guarantee the quality of their services.
Another problem with the QUIC protocol is that the automatic control of overloads on connections with a wide bandwidth can in some cases cause a worse transfer rate.
Although the development of the QUIC protocol has advanced considerably in recent years, to date it has been used as an experiment in the Google Chrome and Opera browsers. In the first one it is usually activated by default, but in the second it is deactivated, so Opera users must activate it manually to benefit from a possible performance increase . Below we inform you about how QUIC is activated or deactivated in both web clients.
To modify the QUIC protocol settings in Chrome, it is necessary to go to the configuration menu. To do this, enter the following command in the address line :
chrome://flags
In this menu you look for the option? Experimental QUIC protocol ? with the help of the search function using the key combination [CTRL] + [F]. If you have not yet made any changes to the basic settings , you should select the option? Default? (default) for the protocol. In the case of QUIC, this standard Chrome setting allows the protocol to be activated.
To disable the protocol, select the entry? Disabled ? (deactivated) and click on the button? RESTART NOW ?. Chrome will stop working and the next time the browser is started the new settings will be active. If you want to re-enable the protocol, proceed in the same way and select ? Default? (default) or ? Enabled? (activated).
Chrome offers the ability to view active QUIC sessions. To do this add the command chrome: // net-internals / # quic in the address list.
Opera, which is based on Chromium, integrates from version 16, published in August 2013, an experimental version of the QUIC protocol. The difference with Google Chrome is that the protocol is generally disabled in Opera and to use the new data transport technology in that browser it has to be enabled. The appropriate option for this, similar to the Google browser, is found in the experimental features settings menu . In Opera it is called? Experiments? and they are accessed through the following command:
opera://flags
In the list of the different test characteristics you will find the options menu for the protocol under the entry? Experimental QUIC protocol ?. To activate the protocol, change the status to ? Enabled? (activated) and then click on the button? Restart now ?. If you want to undo the configuration later, you can do it in the same place but selecting? Disabled? (disabled).
In Opera you can also view the active data connections that work through QUIC, for which you have to insert the opera: // net-internals / # quic command in the browser bar after activating the protocol.
As the driving force behind QUIC, Google has already integrated the protocol into its 2013 server, which is why different Google services are among the most popular web applications that allow the transport of data through possibly the most innovative protocol. At the top of all the search engine is naturally placed, which occupies a central place in the company, but QUIC can also provide other web services such as the Google Maps map service, the Google+ social network, the Google Mail email service, the Office Google Docs solution or YouTube video portal as long as the user uses the appropriate client.
Chrome users can use the HTTP / 2 and SPDY indicator extension to find out what other web pages support QUIC. The extension adds, in addition to the address bar, a small lightning bolt symbol that turns green if the page visited supports the transport protocol. By hovering the mouse over this symbol, a tooltip reveals the version number .