QUIC in the wild

Update: This post has been edited to correct errors of fact about developer tools and APIs with respect to QUIC. Also, the original post implied that Google might be using QUIC in an anti-competitive manner. We regret the errors, and we apologize for the implication.

Back-story: Brave users reported ads getting past our ad-blocking shields in previous Chromium versions, beginning with reports of ads displaying on YouTube.com on October 11, 2016. uBlock Origin users had reported similar bugs. We discovered during testing that disabling QUIC seemed to stop these ads. As a result, we pushed an update to disable QUIC in Brave on January 25, 2017. This update appears to have temporarily abated the incoming bug reports about ads getting past our shields.

We would like to end on a positive note about QUIC. It realizes significant speedups, due to round trip reductions and other advantages, over the HTTPS/TCP/IP alternative. As the post details, we suggest others in ad tech become familiar with it to benefit from the same advantages Google is seeing. 05/10/17 – 3:45pm PDT

When we inspected web page traffic via chrome://net-internals, we discovered that QUIC requests were and still are being used for a majority of Google’s ad domains

What is QUIC?

Originally announced in 2013, QUIC (Quick UDP Internet Connections) is an experimental network protocol, which runs on top of the UDP protocol and is usually requested through port 443 with an Alternative Service HTTP request header flag (example:alt-svc:quic="googleads.g.doubleclick.net:443"). A QUIC working group has been established to standardize the protocol; QUIC is currently still considered experimental.

From a high level, QUIC requests pack several round trips into a single, one-way request, including the security (TLS) handshake. Google’s diagram from their 2015 blog post on the topic helps illustrate the round trip savings:

QUIC is enabled by default in Google’s Chrome browser and underlying Chromium open source browser code. As of March 2017, Chrome accounts for 58.9% of users browsing the web.

Brave blocks QUIC requests. QUIC is an opt-in feature in Opera, and is currently not available in other Firefox, Edge, and Safari. HTTPS requests containing the alt-svc: quic=":443" response header fall back to traditional TCP connections in other browsers, or when QUIC fails in Chrome.

QUIC use has not flown completely under the radar. Google’s April 2015 blog post on QUIC mentioned that roughly 50% of Google traffic was being requested from Chrome/Chromium with QUIC. Missing from the announcement and other QUIC documentation is any mention of QUIC usage in Google’s Doubleclick ad requests, or in Google Analytics tracking requests.

How can I review QUIC sessions and requests?

QUIC runs on top of the UDP protocol. QUIC requests are often made through the same port (443) that is used for TCP requests. Aside from some corporate firewalls that block UDP requests by their protocol number, making QUIC requests to port 443 helps requests get through firewalls configured to allow TCP requests to that port, independent of the protocol number in the IP header. This is a clever hack that dramatically reduces adoption friction, by avoiding the need for firewall reconfiguration in most cases.

Chrome shows QUIC requests in Chrome Developer Tools. If you want to distinguish between QUIC and HTTP in the Network interface, right click to select and reveal the Protocol column.

QUIC requests are visible in the chrome:// internal browser URLs, and of course in WireShark and other lower-level packet sniffing tools.

Tips for observing QUIC traffic

The easiest way to capture and observe QUIC traffic in detail is within the chrome://net-internals interface. Some chrome://net-internalsshortcuts are included below for reference.

To view the QUIC settings and session connections within the dedicated QUIC panel, enter the following address in the URL bar in Chrome: chrome://net-internals#quic

Within the Network section of the Chrome Developer Tools, users can right click to reveal the Protocol column, which will show http/2+quic/36 as the request protocol. This column is not displayed with default settings in Developer Tools.

QUIC and Google ad requests

When we inspected web page traffic via chrome://net-internals, we discovered that QUIC requests were and still are being used for a majority of Google’s ad domains, including domains involved with bidding such as the one below:

Example of TCP a HTTP GET Request URL with the alt-svc: quic=”443” HTTP response header

What does this mean for the ad ecosystem?

It would be helpful for Doubleclick to clarify how they’re using QUIC for ads and tracking. With DoubleClick’s dominance in the ad market, publishers and advertisers need to have a clear understanding and documentation regarding which protocols are being used for ad and tracking requests.

We want to emphasize that we’re fans of QUIC as a protocol, and we hope it is widely adopted. But from our contacts in ad tech, it appears that QUIC is not understood or used yet. While Doubleclick is not obligated to share its QUIC usage details, we hope that it will do so to increase QUIC adoption across the ad-tech ecosystem.