QUIC Protocol
QUIC (pronounced "quick") is a general-purpose transport layer network protocol initially designed by Jim Roskind at Google, implemented, and deployed in 2012, announced publicly in 2013 as experimentation broadened, and described at an IETF meeting.[8] QUIC is used by more than half of all connections from the Chrome web browser to Google's servers.[9]Microsoft Edge,[10]Firefox,[11] and Safari[12] support it, even if not enabled by default.
Although its name was initially proposed as the acronym for "Quick UDP Internet Connections", IETF's use of the word QUIC is not an acronym; it is simply the name of the protocol. QUIC improves performance of connection-oriented web applications that are currently using TCP. It does this by establishing a number of multiplexed connections between two endpoints using User Datagram Protocol (UDP), and is designed to obsolete TCP at the network layer for many applications, thus earning the protocol the occasional nickname "TCP/2".
QUIC works hand-in-hand with HTTP/2's multiplexed connections, allowing multiple streams of data to reach all the endpoints independently, and hence independent of packet losses involving other streams. In contrast, HTTP/2 hosted on Transmission Control Protocol (TCP) can suffer head-of-line-blocking delays of all multiplexed streams if any of the TCP packets are delayed or lost.
QUIC's secondary goals include reduced connection and transport latency, and bandwidth estimation in each direction to avoid congestion. It also moves congestion control algorithms into the user space at both endpoints, rather than the kernel space, which it is claimed will allow these algorithms to improve more rapidly. Additionally, the protocol can be extended with forward error correction (FEC) to further improve performance when errors are expected, and this is seen as the next step in the protocol's evolution.
In June 2015, an Internet Draft of a specification for QUIC was submitted to the IETF for standardisation. A QUIC working group was established in 2016. In October 2018, the IETF's HTTP and QUIC Working Groups jointly decided to call the HTTP mapping over QUIC "HTTP/3" in advance of making it a worldwide standard.[17] In May 2021, the IETF standardised QUIC in RFC 9000, supported by RFC 8999, RFC 9001 and RFC 9002.
How is it different ?
What is QUIC protocol used for?
QUIC is a low-latency transportation protocol often used for apps and services that require speedy online service. This kind of protocol is a necessity for gamers, streamers, or anyone who relies on VoIP in their day-to-day life. Here are the changes QUIC brings to an online session:
- Reduced connection times. To establish TLS encryption, the client and the server need to perform a TLS handshake and exchange encryption keys. It’s a “lengthy” process in IT terms, as there are 4 round-trip requests involved. When the data is transferred over TCP, even more steps are added to this process, slowing down the connection even more. QUIC replaces all of this with a single handshake.
- Better performance when data packets are lost. HTTP/2 on TCP can suffer from head-of-line blocking, a phenomenon where a line of data packets can be held up by the first packet. If one data packet is lost, the recipient must wait for it to be retrieved, which has a huge impact on connection performance. The QUIC protocol solves this problem by allowing streams of data to reach their destination independently. They no longer need to wait for the missing data packet to be repaired.
- Stable connections when networks are changed. If you are connected to a web server via TCP and your network suddenly changes (from Wi-Fi to 4G, for example), each connection times out and needs to be reestablished. QUIC allows for a smoother transition by giving each connection to a web server a unique identifier. These can be reestablished by simply sending a packet rather than establishing a new connection, even if your IP changes.
- Easier to improve and develop. TCP is implemented in operating system kernels, which means changing it is close to impossible. QUIC can be implemented on the application level, making it a more flexible protocol.
latency-reliant data transfers – something that QUIC can help with. Less packet loss means a more efficient app.
How quick is QUIC?
Is QUIC really worth choosing over the standard TCP/IP connection we’ve relied on for so long? In a world where speed dictates success, QUIC is soon to have a much larger presence online. With Google announcing that, on average, QUIC searches are one second faster than TCP searches, the age of QUIC may come quicker than we think.
QUIC relies on multiplexing — this is what gives it an edge over TCP. Where TCP uses a single end-to-end connection point, QUIC establishes multiple connections between 2 endpoints. If one of the streams of information is interrupted, either by shoddy connection or other outside interference, the multiple connection points will allow the streams of information to continue. If a website uses TCP and the connection is disrupted, the data in the packet midway between endpoints will now hold up the rest of the information This head-of-line blocking has been an issue for decades, and QUIC solves it.
If you want to get into the nitty-gritty of which protocol performs more efficiently — TCP or QUIC — have a look at a test run here. The results show that, in the right situation and under the right circumstances, QUIC performs marginally better. However, we need to remember that TCP has been in use and has worked for decades. QUIC has been used for not even half the amount of time that TCP has been prevalent. Knowing Google’s resources and the fact that QUIC can be implemented on an application level instead of an operating system level like TCP, QUIC may just start to outstrip its competition very soon.
Is QUIC as flawless as it seems?
There are few downsides to the QUIC protocol. It improves web communications and reduces latency, but it’s still in its experimental stages. It’s not widely adopted by other websites or web servers, nor is it supported by cybersecurity tools such as firewalls. Because of this, experimental QUIC protocol can currently open a security loophole.
Firewalls pass HTTP and HTTPS traffic through a web protection module, which performs malware scanning. But what happens if the connection is made via QUIC? Well, the browser and supporting web servers do recognize it as a QUIC connection, but the device you are browsing on may not. It treats it like simple UDP traffic, which doesn’t get sent to your firewall’s web protection module.