QUIC - Faster Content Delivery on Layer 4
Are you tired of slow and unreliable internet connections when browsing the web or streaming your favorite content? Have you ever wondered how your browser and servers communicate with each other to deliver data? If so, you may be interested in learning about QUIC, a new protocol that promises faster content delivery on Layer 4.
History of QUIC
After HTTP/2, the next come up is QUIC, a new transport network protocol. At the beginning this protocol was designed by Jim Roskind at Google. It was publicly released in 2013 after the implementation and experimentation in 2012. Originally being an acronym for Quick UDP Internet Connections, the Internet Engineering Task Force (IETF) has stated it's the name of the protocol and not an acronym. It has since been adopted by other major tech companies and is now an official internet standard
Google has been working for quite some time to speed up network protocols in order to optimize network response times. Now that HTTP/2 has been fulfilling its task of speeding up how HTTP uses TCP and has become the basis for fast TLS connections, QUIC goes one step further by aiming to completely replace TCP.
Before becoming an Internet standard, the mapping of HTTP over QUIC was renamed to HTTP/3 in November 2018 by IETF members after a request by Mark Nottingham, the Chair of the IETF HTTP and QUIC Working Groups. This will be the third major version of the HTTP protocol that allows data to be exchanged on the World Wide Web and will succeed HTTP/2. It will take full advantage of the significant performance benefits that QUIC offers.
Fast UDP with QUIC
QUIC is designed to address the limitations of the traditional Transmission Control Protocol (TCP), which has been used for decades to transport data over the internet. TCP and TLS usually require one or more round trip times (RTT) during their connection establishment. An RTT is the total time it takes for a request to go from the starting point to the destination and then back to the starting point. Google is hopeful that QUIC can reduce connection costs towards zero RTTs.
TCP ensures that all packets arrive in order, but does so in a somewhat cumbersome manner, which slows down data transmission on the Internet. By contrast, QUIC is based on UDP, which is used for streaming data (hence the initial name Quick UDP Internet Connections). Unique sequence numbers ensure that no data packet get lost. The other most important component used is the TLS encryption protocol, which has mostly appeared in conjunction with TCP until now. While no corners are cut with regard to security, doing away with handshakes and multiplex transmissions enables faster transmission, even compared to other UDP-based protocols, reportedly.
From Google's QUIC FAQ:
Why can't you just evolve and improve TCP under SPDY? That is our goal. TCP support is built into the kernel of operating systems. Considering how slowly users around the world upgrade their OS, it is unlikely to see significant adoption of client side TCP changes in less than 5-15 years. QUIC allows us to test and experiment with new ideas, and to get results sooner. We are hopeful that QUIC features will migrate into TCP and TLS if they prove effective.
QUIC has been supported by Chrome since version 29. According to Google, about half of all requests from Chrome to Google web servers are served over QUIC. It can be enabled in Chrome by going to chrome://flags/#enable-quic in the browser address bar.
It can be enabled in Opera by going to opera://flags/#enable-quic in the browser address bar.
Advantages of QUIC
Reduced latency
One of the key advantages of QUIC is its ability to reduce latency, or the time it takes for data to travel between client and server. This is achieved through several mechanisms, including the use of UDP and a reduced handshake process. With UDP, there is no need for a three-way handshake, which can take several round-trip times to complete. Instead, QUIC uses a one-round-trip handshake that can reduce initial latency by up to 100ms.
Zero round-trip connection
Another mechanism used by QUIC to reduce latency is zero round-trip connection establishment. With this feature, QUIC allows servers to establish a connection with a client without requiring any round trips at all. This can further reduce latency and improve performance, particularly for real-time applications such as online gaming or video conferencing.
Higher reliability
In addition to latency reduction, QUIC also offers improved reliability compared to TCP. This is achieved through several features, including forward error correction (FEC) and connection migration. FEC allows QUIC to proactively recover lost packets by including redundant data in each packet. If a packet is lost in transit, the redundant data can be used to reconstruct the original packet without requiring retransmission. This reduces the impact of lost packets on overall performance and can help maintain a fast data transfer rate.
Connection migration
Connection migration is another feature of QUIC that improves reliability. With connection migration, QUIC allows a client to switch to a new network path if the original path becomes congested or unavailable. This can help ensure that data continues to be delivered even in the face of network disruptions or failures, improving overall reliability and performance.
Multiplexing
Another key advantage of QUIC is its use of multiplexing. With TCP, each connection requires a separate socket, which can limit the number of concurrent connections that a server can handle. With QUIC, multiple streams of data can be sent over a single connection, allowing for more efficient use of network resources. This can improve scalability and performance, particularly for applications that require many concurrent connections.
Authentication and encryption
From the very beginning, security was a top priority in the planning and design of QUIC. In contrast to TCP, where packet headers are transmitted in plain text and can be read without authentication, QUIC packets are always authenticated and typically encrypted, including the payload. This is a major improvement that helps prevent man-in-the-middle attacks and packet manipulation, including sequence number manipulation. Furthermore, any parts of the header that are not encrypted are still protected from injection and manipulation thanks to receiver-side authentication.
Independence from specific hardware
Because QUIC is implemented entirely in software, it is not dependent on specific hardware features or capabilities. This means that it can be used on a wide range of devices and platforms, including mobile devices, laptops, and servers, without requiring any specific hardware support. This is in contrast to some other protocols, such as TCP, which rely on specific hardware features, such as TCP offload engines (TOEs), for optimal performance. As a result, QUIC offers greater flexibility and compatibility with different devices and platforms, making it a more versatile option for content delivery and other applications.
Packet pacing
Another advantage of QUIC is its ability to provide effective overload control through a mechanism known as packet pacing. This feature is particularly important for managing network congestion and ensuring reliable content delivery.
Packet pacing works by regulating the rate at which packets are sent, which helps to prevent congestion and avoid overloading the network. In QUIC, packet pacing is achieved through a combination of congestion control algorithms and pacing mechanisms that work together to adjust the rate of packet transmission based on network conditions.
This approach is more effective than traditional TCP-based congestion control mechanisms, which tend to be reactive and can result in significant delays and packet loss during periods of congestion. With QUIC's packet pacing, however, packets are transmitted at a steady, controlled rate, helping to prevent congestion and improve overall network performance. This is particularly important for real-time applications, such as video streaming or online gaming, where delay and packet loss can severely impact the user experience.
Disadvantages of QUIC
Increased vulnerability to attacks
One of the potential drawbacks of QUIC is its increased vulnerability to distributed denial-of-service (DDoS) attacks.
DDoS attacks are a type of cyber attack in which multiple compromised devices, often a botnet, flood a target server with traffic in order to overwhelm it and make it unavailable. Because QUIC is a connectionless protocol that does not require a three-way handshake, it is more susceptible to reflection and amplification attacks, which are commonly used in DDoS attacks. Reflection attacks occur when an attacker sends a large number of requests to a server, spoofing the source IP address to make it appear as if the requests are coming from the victim's IP address. The server responds to these requests, sending large amounts of data to the victim's IP address and overwhelming their network capacity. Amplification attacks work in a similar way, but instead of spoofing the source IP address, the attacker sends requests to servers that respond with larger amounts of data than were requested, amplifying the amount of traffic sent to the victim.
QUIC's use of UDP, which allows for faster and more efficient data transfer, also makes it easier for attackers to launch DDoS attacks. Because UDP does not include the same level of error checking and retransmission mechanisms as TCP, it is possible for an attacker to send large amounts of data to a server without requiring a response, resulting in an amplification attack.
Compatibility issues
It's worth noting that QUIC may not be suitable for all applications. For example, some applications that require precise control over network behavior, such as online trading platforms, may prefer the reliability and predictability of TCP. Additionally, because QUIC is still relatively new, there may be some compatibility issues with older devices or networks that do not support the protocol.
Lower transmission rate
Although QUIC is designed to be faster and more efficient than TCP, it may have a lower transmission rate in certain situations. This is because QUIC adds additional overhead to packet transmission due to its encryption and authentication mechanisms, which can result in larger packet sizes and longer processing times. This can potentially slow down transmission rates, particularly for smaller packet sizes.
Difficult troubleshooting
Additionally, troubleshooting network issues with QUIC can be more challenging compared to TCP. This is because the encryption and authentication features of QUIC make it more difficult to diagnose and resolve issues related to packet loss or network congestion. In particular, diagnosing issues related to packet loss or congestion may require more advanced network monitoring tools and expertise, as well as a deeper understanding of QUIC's internal workings.
The need to stay up to date
Another potential disadvantage is that because QUIC is still a developing protocol, it may be subject to changes and updates that could impact its performance and stability. This means that organizations using QUIC may need to keep up-to-date with the latest developments and updates to ensure optimal performance and reliability.
QUIC and HTTP/3
One important aspect to note about QUIC is its association with HTTP/3, the latest version of the HTTP protocol. In fact, HTTP/3 is built entirely on top of QUIC, meaning that it relies on QUIC's underlying transport mechanism to transfer data between clients and servers. This integration of HTTP/3 and QUIC is a significant development, as it allows for even faster and more efficient data transfer compared to previous versions of the protocol, such as HTTP/2.
The use of QUIC with HTTP/3 also provides improved security and reliability, as all data is encrypted by default and QUIC's mechanisms for error correction and connection migration help ensure that data is delivered efficiently and reliably.
Google has found that 75% of all requests are served faster over QUIC and that TCP based websites and content that is streamed will greatly benefit from it. Especially video services like YouTube, where users report 30% fewer rebuffers when watching videos over QUIC. With such big changes it will take time for QUIC to become the most commonly used transfer protocol. At the time of writing this only 8.8% of websites use QUIC.
Summary
The QUIC protocol has been a large work in progress and has made serious advancements in the last few years. This has led to the beginning of the next HTTP protocol, HTTP/3. As the number of people that have access to the Internet is continually growing adopting HTTP/3 will help bring performance improvements.
We don't have an exact date yet on when our network will support HTTP/3, but we have already started to engineer possible integration scenarios and will keep you updated as we make progress.