Over the last few years, QUIC has become the default protocol for networked communication of Google services. As stated here, QUIC is now used by more than half of all connections from the Chrome web browser to Google's servers. It is also officially supported by Microsoft Edge, Firefox, and Opera.
Google developed it with cybersecurity in mind and to replace several outdated standards with more advanced and up-to-date technology. In other words, QUIC might represent the future of the Internet, and this is why understanding it is so important.
So, let's dive into Google's QUIC protocol and introduce everything you need to know about it.
QUIC's History
QUIC initially stood for "Quick UDP Internet Connections", even though the term is no longer used as an acronym. Now, "QUIC" is used to describe a general-purpose transport layer network protocol designed by Google.
In 2012, it was originally implemented and deployed.
In 2013, it was publicly announced as experimentation broadened at an IETF meeting.
In June 2015, an Internet Draft addressing its specification was submitted to the IETF for standardization.
In 2016, a QUIC working group was established.
In October 2018, the HTTP mapping over QUIC started to be called "HTTP/3", making QUIC bound to become a worldwide standard.
In May 2021, the IETF finally standardized it in RFC 9000.
What Is QUIC?
Google's QUIC is a low-latency Internet transportation protocol over UDP, a protocol that is often used by gaming, streaming media, and VoIP services.
[…]
UDP is significantly more lightweight than TCP, but in return, it features far fewer error correction services than TCP.
[…]
With QUIC, Google aims to combine some of the best features of UDP and TCP with modern security tools. — Google Wants To Speed Up The Web With Its QUIC Protocol
QUIC vs TCP
Unlike what happens with TCP, the QUIC protocol allows communications only in encrypted form. Since unencrypted communication forms in QUIC are forbidden by design, privacy and security are inherently part of QUIC data transfers. This is definitely a plus when it comes to cybersecurity but may also represent a useless overhead when encryption is not strictly required.
But the real breakthrough is represented by the time QUIC takes to establish a secure connection when compared to TCP + TLS. In other terms, QUIC's main goal is to greatly reduce the overhead during connection setup.
This is possible thanks to how QUIC was designed. In fact, QUIC makes exchanging configuration keys and supported protocols part of the initial handshake process faster. Specifically, when a sender opens a connection, the response packet also includes the data needed for future packets required to use encryption. This step eliminates the need to set up the TCP connection and then negotiate the security protocol through other packets. This leads to higher connection speeds and a significant decrease in response, even down to 0ms during inter-host reconnection, which is called "Zero RTT Connection Establishment".
As you can see, the typical secure TCP connection takes two or three round-trips before the sender can actually start receiving data. This may take up to 300ms. While by using QUIC the sender can immediately start talking to a receiver it has already talked to before.
When compared to UDP, QUIC emerges as the winner because it comes with a couple of TCP features like congestion control and automatic re-transmission that UDP does not have. This makes it inherently more reliable than pure UDP. In detail, although QUIC uses UDP as its base, it involves loss recovery. This is because QUIC behaves like TCP and checks each stream separately re-transmits data when it gets lost.
Also, if an error occurs in one flow, QUIC can continue to serve other flows independently. This feature can be very useful for improving performance on error-prone links, since considerable additional data may be received before TCP notices a missing or lost packet. In QUIC, this data is free to be processed while the flow is being repaired.
QUIC also improves performance during network switching events, such as when a mobile device user moves from a Wi-Fi network to a mobile network. When the same thing happens over TCP, a long process where each existing connection is broken one at a time and then re-established on demand is executed. To solve this issue and its consequences when in terms of performance, QUIC includes a connection ID to the receiver regardless of the source. This allows the connection to be re-established simply by re-sending a single packet, which always contains this ID and that will be considered valid by the receiver even if the sender's IP address has changed.
So, will this be enough for QUIC to replace TCP?
Conclusion
Here we looked at what Google's QUIC protocol is, how it works, and why it may represent the future of the Internet protocols. QUIC was designed by Google to replace many obsolete standards and might be a real game-changer in the years to come. This is why understanding it is crucial, and delving into it was what this article was about.
Thanks for reading! I hope that you found this article helpful.
The post "Will Google's QUIC Protocol Replace TCP?" appeared first on Writech.
Top comments (0)