PaperlayerView exact revision on arXiv

Source-linked AI summary

A First Look at QUIC in the Wild

Jan Rüth, Ingmar Poese, Christoph Dietzel, Oliver Hohlfeld

arXiv:1801.05168v2cs.NI

TL;DR

The paper addresses limited evidence about QUIC deployment and traffic beyond prior work focused on protocol security and performance. It scans IPv4 and domain infrastructure and analyzes traffic from three vantage points. QUIC-capable IPs more than tripled, and QUIC accounted for 2.6%–9.1% of monitored traffic.

  • Problem

    Evidence about QUIC deployment and traffic was limited, while existing academic work focused on protocol security and performance.

    Source: §1 · pp. 1–2

  • Method

    The authors regularly scan the IPv4 address space and about 46% of the domain namespace, and analyze traffic traces from three vantage points.

    Source: §1 · p. 2

  • Results

    QUIC-capable IPs reached 617.59 K after more than tripling; among 161K capable domains, 15K presented valid certificates, and QUIC accounted for 2.6%–9.1% of monitored traffic.

    Source: §1 · p. 2, §6 · p. 11

  • Takeaways & Limitations

    The observed QUIC deployment and traffic share vary across infrastructure and vantage points, with Google contributing much of the observed traffic.

    Source: §1 · p. 2, §4 · p. 11

    Frequent QUIC version changes, including radical changes without backward compatibility, leave long-term compatibility as an open concern.

    Source: §3.1 · p. 5

Abstract

from arXiv · show

For the first time since the establishment of TCP and UDP, the Internet transport layer is subject to a major change by the introduction of QUIC. Initiated by Google in 2012, QUIC provides a reliable, connection-oriented low-latency and fully encrypted transport. In this paper, we provide the first broad assessment of QUIC usage in the wild. We monitor the entire IPv4 address space since August 2016 and about 46% of the DNS namespace to detected QUIC-capable infrastructures. Our scans show that the number of QUIC-capable IPs has more than tripled since then to over 617.59 K. We find around 161K domains hosted on QUIC-enabled infrastructure, but only 15K of them present valid certificates over QUIC. Second, we analyze one year of traffic traces provided by MAWI, one day of a major European tier-1 ISP and from a large IXP to understand the dominance of QUIC in the Internet traffic mix. We find QUIC to account for 2.6% to 9.1% of the current Internet traffic, depending on the vantage point. This share is dominated by Google pushing up to 42.1% of its traffic via QUIC.

1 Introduction

TCP is difficult to update as Internet demands shift toward low latency and transport encryption, while existing TCP/TLS approaches face deployment challenges from middleboxes and legacy systems. The paper assesses QUIC deployment and traffic at scale, finding broad growth in QUIC-capable infrastructure and measurable traffic shares across three vantage points.

1 Introduction

  • TCP’s difficulty of updating and the added latency of TLS motivate transport-layer approaches that address latency and encryption, but middleboxes and legacy systems challenge deployment.The paper describes interactive applications as one source of shifted latency demands.Source: §1 · p. 1
  • QUIC combines a reliable, in-order connection-oriented byte stream with multiplexed streams, latency optimization, transport-layer encryption, and user-space deployment over UDP.The passage notes that the consequences and motives of per-application customization remain unknown.Source: §1 · pp. 1–2
  • QUIC accounted for 2.6%–9.1% of monitored traffic across three vantage points, with Google contributing up to 98.1% of QUIC traffic at the ISP.Akamai contributed 0.1% at the ISP and 59.9% at the IXP despite its large number of QUIC-capable IPs.Source: §1 · p. 2
  • The study scans the entire IPv4 space, analyzes traffic outside Google from three vantage points, and publishes tools and active-measurement data.The tools enumerate QUIC hosts and capture and decode protocol parameters.Source: §1 · p. 2

2 An Introduction to QUIC’s Handshake

The paper introduces the QUIC connection-establishment phase used to enumerate hosts and retrieve certificates. It explains the handshake steps, including version negotiation and how cached information changes the connection’s round-trip requirements.

2 An Introduction to QUIC’s Handshake

  • The connection-establishment phase is the basis for the paper’s host enumeration and certificate-grabbing measurements, which focus on the early deployment draft.The authors defer broader discussion of QUIC features and design choices to.Source: §2 · p. 2
  • Without prior connections, the handshake requires at least three round-trips, while cached information can permit encrypted application data in 0-RTT.The figure depicts a long handshake including version negotiation and caching of values.Source: §2 · p. 2, Figure 1 · p. 3
  • The handshake supplies server configuration and certificates, then allows the client to send a final Client Hello and potentially encrypted data before the server’s acknowledgment.A server configuration includes supported ciphers, key-exchange algorithms, public values, and certificates; the client can repeat exchanges until it has the required information.Source: §2 · p. 3

3 Availability: QUIC Server Infrastructures

The study measures QUIC server availability across IPv4 hosts and sampled domains, using QUIC handshakes and certificates to identify capable infrastructure. QUIC-capable IPs grew substantially, while domain-level support and valid certificates remained limited.

3.1 Enumerating QUIC IPv4 Hosts

  • The host scan elicited supported-version lists by sending a valid handshake message with a likely unsupported version and identifying version-negotiation or public-reset responses.The scan extended ZMap to probe the entire IPv4 address space.Source: §3.1 · pp. 3–4
  • 617.59 K QUIC-capable IPs were found in October 2017, more than tripling the 186.77 K measured in August 2016.The scan identified hosts in 3.04 K Autonomous Systems.Source: §3.1 · p. 4, Figure 2 · p. 4
  • Google and Akamai accounted for 53.53% and 40.71% of QUIC-capable IPs, respectively, in October 2017.The study attributes hosts using AS information, per-IP certificates, and reverse DNS.Source: §3.1 · p. 4
  • QUIC version support changed rapidly: version combinations had short lifespans, although Q035 remained widely supported and Q036 support was later dropped.Some versions introduce radical changes without backward compatibility, raising questions about long-term stability.Source: §3.1 · p. 5

3.2 Enumerating QUIC Domain Names

  • The domain scan resolved sampled zone-file and Alexa-list domains, then tested QUIC handshakes and collected connection parameters.The IP-based certificate scan used a dummy hostname, so it returned default-site certificates and missed 216.64 K hosts requiring SNI.Source: §3.2 · pp. 5–6
  • Only 0.06%–0.1% of domains, depending on the zone, were hosted on QUIC-enabled hosts, and only 1.6%–2.44% of these had a valid X509 certificate.The domain measurements covered .com, .net, .org, and the Alexa Top 1M list.Source: §3.2 · p. 6, Table 1 · p. 6
  • Of 161 K probed domains, 33 K returned more than 1 kB over QUIC, and their content was similar to their HTTP counterparts.Only 11 K domains provided an HTTPS alt_srv header, and only 5 K advertised the QUIC version Chrome required at measurement time; the analysis covered landing pages, not additional assets.Source: §3.2 · p. 7

4 Usage: QUIC Traffic Share

Across the measured vantage points, QUIC’s traffic share ranged from 2.6% at a large IXP to 9.1% in the ISP’s mobile network. At the European ISP, Google accounted for nearly all observed QUIC traffic, while provider shares differed at the IXP.

Measurement scope

  • The traces cover nine months of 2017 on the MAWI transit link and one day at a European ISP and IXP; protocol classification uses ports 80 and 443.The ISP traces include DSL, cellular, and transit backbone traffic.Source: §4 · pp. 7–9

MAWI Backbone Trace

  • QUIC’s MAWI traffic share rose from 0.0% in January 2017 to 6.7% in September, while HTTP and HTTPS accounted for around 28.0% and 44.9%.The first observed QUIC traffic was in February, at 3.9%.Source: §4 · p. 8, Figure 4 · p. 8

European Tier-1 ISP

  • At the European ISP, QUIC averaged 7.8% of traffic; Google supplied 98.1% of observed QUIC traffic, and 39.1% of Google’s traffic used QUIC, peaking at 42.1%.The ISP figure compares relative QUIC share with total traffic against HTTP(S); Table 2 distinguishes overall, operator, and protocol shares.Source: Table 2 · p. 8, §4 · p. 9, Figure 5 · p. 9

Mobile ISP

  • 9.1% of mobile-network traffic was QUIC on average, the highest share among the traces; 34.0% of mobile Google traffic used QUIC.Akamai served only a negligible share of its traffic via QUIC in the mobile network.Source: §4 · p. 10, Figure 6 · p. 10

European IXP

  • 2.6% of traffic at the large European IXP was QUIC on average; Akamai contributed 59.9% of that QUIC traffic and Google 33.1%.At the ISP, Google contributed 98.1% of QUIC traffic, illustrating that provider shares depend on vantage point.Source: §4 · pp. 9–10, Figure 7 · p. 10

Discussion

  • Differences between the ISP and IXP provider shares are likely caused by different traffic-engineering strategies, making observed QUIC shares vantage-point dependent.Both providers peer at both vantage points; the authors identify understanding their traffic-engineering incentives as future research.Source: §4 · p. 11

5 Related Work

Prior work examined QUIC security and performance, including comparisons with HTTP/1 and HTTP/2. This paper complements those studies with a broad assessment of QUIC deployment and traffic shares outside Google’s network.

QUIC Security

  • Prior security work analyzed QUIC’s key exchange and complete protocol, and described an attack vector that computes server configuration offline to impersonate a server.The cited works are,, and, respectively.Source: §5 · p. 11

QUIC Performance

  • Prior performance evaluations reported that QUIC can outperform HTTP/1 and HTTP/2 over TCP/TLS; Google reported lower search latency and less YouTube rebuffering.Google reported search latency reductions of 3.6–8% and YouTube rebuffering reductions of 15–18%.Source: §5 · p. 11

Contribution

  • This paper complements prior security and performance studies with the first broad assessment of QUIC-enabled infrastructure and traffic shares outside Google’s network.The assessment examines traffic from three vantage points.Source: §5 · p. 11

6 Discussion and Conclusion

QUIC-capable infrastructure grew rapidly, but its size does not directly reflect traffic share: Google dominates ISP QUIC traffic while Akamai’s share varies widely by vantage point. The authors also link QUIC’s user-space implementation and short-lived versions to an expected dynamic future transport landscape.

6 Discussion and Conclusion

  • QUIC-capable IPs tripled to 617.59 K by October 2017, with Google and Akamai accounting for 53.53% and 40.71%, respectively.The paper reports that growth was mainly driven by these two operators.Source: §6 · p. 11
  • Of 161K QUIC-capable domains among approximately 150M probed, 33K served content similar to HTTP1/2 counterparts and 15K presented valid certificates.Many non-Google-hosted domains would not be contacted by Chrome because alternative-service headers were absent or version support was insufficient.Source: §6 · p. 11
  • QUIC infrastructure size did not reflect traffic share: Google accounted for 98.1% of ISP QUIC traffic, while Akamai ranged from 0.1% at the ISP to 59.9% at the IXP.Despite operating a similarly large number of QUIC-capable IPs, Akamai contributed very different traffic shares across vantage points.Source: §6 · p. 11
  • QUIC’s user-space implementation permits rapid updates, reflected in short-lived versions during development; the authors expect a highly dynamic future transport landscape.They call for future work to study and observe that landscape.Source: §6 · pp. 11–12
Loading 1801.05168v2…