COMMON PROBLEMS WITH QUIC

• At this stage of the game, with so many QUIC versions in play on the internet, it's possible that we could have a client that supports one version of QUIC and a server that supports another. If this is the case, QUIC will not connect, and it should default back to TCP for most applications, or at least, at this point in time.
• Now, the developers of QUIC knew that this would be the case as browsers and mobile applications begin to support this new transport protocol. So as versions of QUIC further develop, we can run into cases where clients and servers are not up to speed on the latest versions, and this is often why servers will advertise more than one version for a client to use. If the client can support any of these versions, then the connection will proceed.

• Another area we can run into problems when implementing QUIC is with infrastructure devices along the network path and also security detection systems. Now, at the endpoints, a ton of work has gone into browsers and servers to process UDP port 80 or 443 as QUIC traffic, but the network has struggled to keep pace.
• QUIC is designed from the foundation to be secure from the transport layer up, which makes it difficult to inspect. Remember that up until recently, there were few major services running over secure UDP. So firewalls, for example, may not expect applications other than DNS or VoIP to use UDP and may not be happy with the inability to inspect the encrypted data.
• In sensitive environments, this traffic could be dropped altogether. Now, the same is true for IDS systems. These have been born and bred to deal with TLS and TCP flows, but they might not be fully up to speed yet on QUIC, which could present some alerts. Also, we have VPN concentrators, WAN accelerators, and other middle boxes, which have been tuned to handle TCP for decades, but might not yet know what to do with QUIC, and network address translation boxes might time UDP connections differently than TCP, which could result in a premature rebind.
• And last, on the server side, in the data center, cloud or not, load balancers are going to need to learn how to distribute QUIC to the front end, which is a big shift from how they've been doing things with TCP.

• So these are just a few of the pain points that we could run into when implementing and supporting QUIC, which makes validation prior to a formal rollout even more important.

TOOLS FOR TESTING AND VALIDATING QUIC

• As QUIC has continued to mature, the more tools we've seen for testing and implementing it. Now, this is great, seeing things at the packet level, but this is a very detailed approach to testing and troubleshooting QUIC. After all, we need the packets, we also need to capture the TLS session keys, and we need deep knowledge of where and what to look for at the packet level.
• Bottom line, this can be overly detailed. It can be overkill for what we need when we're just rolling QUIC out or testing a new network path. So let's move beyond packet data and see what we can do with some other tools, so we're going to look at three major families of tools.
• The first are online services that allow us to test a public site for QUIC support. To get a bit more detailed, we can also use tools that are built into our local web browser that can help to observe and troubleshoot QUIC connectivity. And last, we'll talk about some command‑line tools that enable us to manually generate or automate QUIC connections to servers to test availability and successful configuration.
• Let's take a closer look at that first tool. With online tools, we, as users, first connect to a test server, which is then able to send a QUIC connection to a desired site. The response from the site will tell us whether QUIC is supported, what versions are available, and information about the security and transport settings in place. Now, this is a great way to quickly test publicly‑facing servers for QUIC support, just to get an idea of whether people can access these systems from the internet.
• One such tool that we could use is http3check.net. There are several other of these tools, so you could just do a QUIC Google search to find some other ones. This tool allows us to enter a hostname and then verify that it's QUIC capable. Now, the report that this tool will generate will show us what versions are supported on a server, as well as some advanced information, such as the connection time and even 0‑RTT time.

• Another tool that we could use is one that might be built right into our browser, such as the developer tools in Chrome. Now, this feature allows us to test and monitor individual QUIC connections to sites to get an idea of server response time and details around the HTTP/3 header information. Now, one thing I like about this tool is it's built right into the browser, all we have to do is enable it, and here's one example of the output of the Chrome developer tools view. So when this option is enabled and recording, Chrome can tell us about the QUIC version use, who is hosting the site, what the response time is, and much more. Other browsers might have similar toolsets, but for the second time, we're just going to focus on Chrome for now.

• Lastly, we have command‑line tools, so these allow us to generate manual queries over HTTP/3 and QUIC to servers to validate connectivity, one such tool is curl, which is available on most systems today.