James Kehr here with the Windows Networking Escalation Engineering team. Today’s topic is the newly published QUIC protocol. This is a quick discussion, all puns intended, about why QUIC is important to the modern internet.
Back in the old days, about the mid-1990’s, when the Internet was new and the Wild Wild Web was a better fit for WWW than the World Wide Web, Internet connections were really slow. Youngsters can’t appreciate just how amazingly slow the Internet was back then.
A simple web page could take upwards of 1-2 minutes to load. Good video streaming, forget about it! High resolution video was originally 640×480, what we now call 480p or SD video, but most early video was 320×240. Even at the lower resolution you’d start the video, then immediately pause it so the video could buffer. Go refill your beverage, talk with friends, read a book, and about 5-10 minutes later you could start the video. And, if you were lucky, it wouldn’t pause to buffer before the video was done.
This is normally the part when us old timers do the traditional joke of “And we liked it! We loved it!” but that would be a lie. We hated it. It was horrible. We were Internet addicts and we wanted to surf the net and not have to wait.
Students of computer history will note that around this time a huge surge in computer advancements began. Processor and network speeds improved dramatically. Displays got larger with higher resolutions. New Internet connection technologies sprung up everywhere. Then the smartphone happened, and a second wave of innovation hit. To put this in perspective, the current flagship smartphones are about ten times (10x) more powerful than the fastest super computer of 1995.
The driving force behind most of this innovation was, you guessed it, a fast and stable Internet experience. People today want to open a site and have the page loaded by the time their thumb clears the smartphone screen or the cursor clears the browser window. Our video needs to stream immediately in 4K with no buffering and no pixelation.
Despite the massive leaps in technologies that have enabled the modern Internet experience, we have been using the same major Internet protocol since the beginning, our tried-and-true friend, TCP.
Let me start by saying that TCP, or Transmission Control Protocol, isn’t go anywhere any time soon. It is, and will be, the dominant network protocol in the world for years to come. Which begs the question, why replace it?
TCP was first developed in 1974 for the precursor to the Internet, ARPAnet. A little math will reveal that TCP will have its 50th birthday soon. ARPAnet was mainly used by military and educational institutions across closed circuits until ARPAnet became the commercial Internet in the early 1990’s. The TCP/IP suite of protocols used by ARPAnet were carried over to the Internet. TCP, as the resilient transport protocol, became the de facto standard for most Internet activities. Without TCP the Internet would not have worked quite right.
This is normally where I say something like TCP is bad and needs to be replaced, but there isn’t anything necessarily bad about TCP because it’s a great protocol. The problem is that we can’t change TCP to make it better and meet the needs of modern Internet services that need to be crazy fast. The TCP protocol is simply too embedded to make any significant changes to it without the risk of breaking millions of devices.
A lot of ideas have been thrown around to improve the Internet experience over the years but none of them stuck until QUIC, the Quick UDP Internet Connection protocol, was developed at Google using a unique concept. Rather than developing a completely new protocol that would require a massive upgrade to the Internet backbone the QUIC protocol extends an existing protocol, UDP. I say extend because QUIC is a transport layer protocol, not an application protocol, even though QUIC is transmitted inside the UDP segment. Think of it like this:
UDP + QUIC = the transport layer
QUIC uses UDP for ports and connectionless transport, then adds the resiliency of TCP, the security of TLS 1.3, sprinkles in a dash of commands and version control from protocols like SMB, and then mixes in a set of new protocol concepts and efficiencies to create something entirely unique in the protocol world.
Big tech companies are excited about QUIC because it adds several changes that will help make Internet services better, especially edge services where every millisecond matters. By extension, this makes the Internet experience better for everyone. Here are some of the improvements in QUIC:
QUIC 1.0 requires TLS 1.3 based encryption for all data. This makes data over QUIC inherently secure regardless of service.
Lower Connection Latency
QUIC doesn’t change the laws of physics, but it doesn’t have to wait for two handshakes (TCP then TLS) to complete a secure network connection. Connection setup takes fewer packets to complete than TCP + TLS and can be resilient after close. This means you start getting data faster the first time you connect to a service, and potentially faster the second time.
QUIC can reuse a session in two ways: streams and session tickets. A single QUIC session can have multiple simultaneous data streams. A server can also grant clients a session ticket that can be used to reconnect to a server without going through a full handshake. This reduces the number of client-server connects and allows fast, secure reconnections.
This is one of the coolest features, in my opinion, as it allows a QUIC connection to survive an IP change. Let’s say you have a laptop with WiFi and LAN, and switch from a wired LAN connection to WiFi. With TCP the connections must be closed, and new connections opened using the WiFi IP address. With QUIC, the client can provide evidence to the server to prove who they are and continue with the existing connection on the new IP as if nothing changed. Making the mobile user experience more seamless.
In addition to encryption, QUIC is built to prevent or lessen the impact of things like Denial of Service (DoS), replay, reflection, spoofing, and other types of attacks. QUIC can’t eliminate all attacks, but it does try to make it harder to successfully attack.
QUIC can change and be adapted to meet new Internet needs because it has version control. QUIC 1.0 was published in May 2021 via RFC 9000, plus RFCs 8999, 9001, and 9002. Future versions of QUIC are free to change the protocol as needed. Computers can support multiple simultaneous versions of QUIC. This allows new version to fix and improve the QUIC protocol while supporting older implementations during a transition period. Over time the old versions can be dropped to keep QUIC secure and up to date for decades to come.
People and companies can extend QUIC to meet their own needs. This is handled via QUIC extension frames, which can be public and potentially be added to a future version of QUIC, or private and used only for internal services. There are few rules that must be followed, but otherwise people are free to extend QUIC via custom frames as they see fit.
Not everything is sunshine and flowers in QUIC land. QUIC 1.0 is brand spanking new, less than 4 months old at the time of writing. It’s going to take time for most devices to support QUIC. Modern browsers already support QUIC. The newest versions of Windows, Window 10 21Hx, Windows 11, and Windows Server 2022, have native QUIC support. Some older versions of Windows should see MsQuic support in early 2022. Apple has native QUIC support starting with Big Sur. Linux and FreeBSD currently need a QUIC driver installed or implemented in the user application, but future versions may have native support.
Older OS builds are the problem here and may not have any QUIC capabilities outside the browser. And if there’s one thing that IT has taught me, many people are generally slow to upgrade.
Then there’s the learning curve when developing for QUIC. The QUIC protocol does things a bit differently than TCP and plain UDP. Learning the best way to leverage QUIC streams to your advantage will take some time and effort.
Finally, there’s the traffic shaping problem. Some networks and ISPs will prefer TCP traffic over UDP, and rightly so. TCP is currently the de facto transport protocol on the Internet. This can, however, cause problems with QUIC performance in the short term when certain network congestion conditions are reached. A heavily congested network may drop UDP traffic to pass TCP traffic. This will change as backbone networks become more aware of QUIC. In the short term, there might be performance issues during peak hours.
Does this give you license to ignore QUIC? It shouldn’t. Microsoft, Apple, Google, Amazon, Facebook, Cloudflare, and other big tech companies are already using QUIC because of its advantages over TCP. The tech world is ready for a QUIC switch, so you should be thinking about it, too.
No article would be complete without a small plug for your own product. Microsoft’s implementation of QUIC is called MsQuic. It is an open source, cross platform project available to the world. Windows and Linux are fully supported as of version 1.5.0, with MacOS currently in the alpha stage. There is support in MsQuic for the UDP offloading features announced for Windows Server 2022, which will be available in Windows 11, as well. The UDP features do require a compatible network adapter. MsQuic performance is pretty impressive, too.
I hope that helps you understand some of the pros and cons of QUIC, and why people are so excited about it. Keep an eye on the Networking and Storage at Microsoft Tech Communities for more content about QUIC and SMB over QUIC in the future.
I worry about troubleshooting, a simple packet capture is out of the question.
@Teus Renes Yes and no. This wasn’t meant to be a troubleshooting article so I didn’t touch on that question, but it’s a good one to ask.
Your concern has been voiced by just about everyone who troubleshoots network connections. There are projects underway to allow QUIC decryption on the client and server. Such as this one by Wireshark, which can decrypt QUIC on Chrome 89+ when an SSLKEYLOGFILE is setup on the OS and key logging is enabled in Chrome. This should carry over to other Chromium-based browsers.
Firefox may support it, the SSLKEYLOGFILE file format is a Mozilla creation. I haven’t seen documentation one way or the other involving QUIC, however.
MsQuic has SSLKEYLOGFILE support, as of v1.1, but, as I understand it, MsQuic requires the driver or application to enable and use it. Support for decryption is disabled by default.
- Added (off by default) SSLKEYLOGFILE support.
MsQuic logging is an okay substitute when decryption is not an option.
The “no” involves data on the wire, which cannot be decrypted. You must make a concerted effort on OS and application to enable QUIC TLS decryption.
© Microsoft. This article was originally published by Microsoft's Networking Blog. You can find the original article here.