<aside> 📘 TL; DR;
QUIC 优化思路：
虽然此文是介绍 QUIC 优化的，但是从侧面反映出，原生的 QUIC 性能是远远逊于 TCP + TLS 的。而这也正是 Head-of-Line Blocking in QUIC and HTTP/3: The Details 一文的观点，QUIC 不是为了快，而是为了给未来提供更好更开放的协议基础。
</aside>
We’ve shared a lot about how much we love QUIC (and why we’re building our own implementation called quicly). It promises latency reduction, improved throughput, resilience to client mobility, and increased privacy and security. Excitingly, the QUIC working group at the IETF is now on the cusp of getting the first version of QUIC wrapped up and ready for internet-wide deployment. While many of the people and teams building and planning to use it are eager to see wide deployment, one concern keeps coming up: what is the computational cost of QUIC’s additional features and protections? QUIC is being touted as a replacement to TCP; how can it do that if it requires significantly more computational power?
We ran the tests to try and find some answers, and here’s the high level answer: Yes, QUIC can be as computationally efficient as TCP!
Before the bottles of champagne come out, we’ll admit what will soon become obvious: we have a simple setting and benchmark, and that we need to do more testing with more realistic and representative hardware and traffic scenarios. Importantly, we did not have any hardware offload enabled for TCP or QUIC. Our goal was to use a simple scenario with synthetic traffic to eliminate some of the more obvious computational bottlenecks and gain insights into how we might reduce QUIC’s costs.
That said, we were surprised to find that QUIC did as well as TCP in even our simple scenario.
You could think of the exercise in this post as equivalent to making our car race well against a Ferrari on a race track. A race track is a highly artificial environment and the experience of driving our car on it is not representative of what you will experience daily (unless you are a race car driver). Working through the problem of racing well on that track however helps us to uncover bottlenecks. And the important and transferable things here are the measures we would take to remove the bottlenecks. That’s what this post is about.
QUIC (Quick UDP Internet Connections) and TCP (Transmission Control Protocol) are both network transport protocols, but they differ in several key aspects. Here are some of the main differences between QUIC and TCP:
Transport Layer: TCP operates at the transport layer of the networking stack, while QUIC is built on top of the User Datagram Protocol (UDP). UDP is a lightweight, connectionless protocol that provides minimal error checking and does not guarantee reliable data delivery or ordered packet arrival.
Connection Establishment: TCP requires a three-way handshake process to establish a connection between a client and a server before data transfer can occur. QUIC, on the other hand, establishes connections more quickly by employing a zero-round-trip-time (0-RTT) handshake. This allows QUIC to start transmitting data immediately upon connection establishment, reducing latency.
Multiplexing and Streams: TCP uses a single ordered stream of bytes for data transmission, which requires the use of techniques like message framing to differentiate between individual data chunks. QUIC, however, supports multiplexing and allows multiple streams of data to be transmitted concurrently within a single connection. This enables more efficient data transfer and better utilization of network resources.
Congestion Control: TCP utilizes a congestion control mechanism based on the assumption that packet loss indicates network congestion. It slows down transmission rates when packet loss is detected. QUIC includes its own congestion control mechanism, which is designed to be more efficient in handling modern network conditions, such as high-latency or lossy connections. QUIC's congestion control is also more resistant to interference from middleboxes (network devices that may modify or filter network traffic).
Security: While TCP provides the basis for secure communication with the use of additional protocols like Transport Layer Security (TLS), QUIC incorporates security features directly into its design. QUIC includes encryption and authentication as inherent components, providing secure communication by default.
NAT Traversal: Network Address Translation (NAT) is a technique used to map private IP addresses to public IP addresses, allowing multiple devices to share a single public IP address. QUIC is designed to better traverse NAT devices, which can simplify network configurations and enable more reliable connections.
Essentially, QUIC offers advantages in terms of reduced latency, improved multiplexing and concurrent streams, efficient congestion control, inherent security, and better compatibility with NAT devices compared to TCP. These characteristics make QUIC a promising protocol for modern web applications and services that aim to provide faster and more reliable network communication.
TCP has been the workhorse of the web for a long time, and a lot of effort has gone into optimizing its implementations over the years to make it more computationally efficient. QUIC however, is still a nascent protocol; it has yet to be widely deployed and tuned for computational efficiency. How would such a new protocol compare against the venerable TCP? Importantly, can QUIC be as efficient as TCP in the near future?