Performance Comparison of HTTP/3 and HTTP/2: Proxy vs.

Non-Proxy Environments
Fan Liu, John Dehart, Jyoti Parwatikar, Behrooz Farkiani, Patrick Crowley
Washington University in St. Louis
St. Louis, USA
[email protected],[email protected],[email protected],[email protected],[email protected]

ABSTRACT QUIC introduces several innovative features that distinguish it

This paper systematically evaluates the performance of QUIC/HTTP3 from other previous protocols. It enables faster connection establish-
(H3) and TCP/HTTP2 (H2) protocols in proxy-enhanced environ- ment and supports multiplexed connections without head-of-line
arXiv:2409.16267v2 [cs.NI] 12 Oct 2024

ments. H3 leverages features such as UDP-based flow-controlled (HoL) blocking, a substantial limitation in TCP. Furthermore, QUIC
streams, integrated TLS, multiplexed connections, and connection uniquely supports connection migration, which allows ongoing ses-
migration, offering the potential for improved web communication. sions to continue even when the client’s network endpoint changes
Despite extensive research, the impact of proxy integration and (e.g., when switching from Wi-Fi to cellular networks) [39]. HTTP/3
connection migration remains underexplored. This study addresses builds on QUIC by incorporating these advancements to streamline
this gap by evaluating H3 and H2 across various scenarios, par- data transmission processes, enhancing web page load times and re-
ticularly in noisy networks and proxy setups. Our findings show sponsiveness through smarter packet processing and prioritization
that H3 excels under high loss and high latency conditions, signifi- of requests [26].
cantly benefiting from its connection migration and multiplexing Major companies such as Google [1], Akamai [25], Meta [41], Mi-
features, with improvements of up to 88.36% under high-loss and crosoft [23], and Cloudflare [36] have adopted QUIC commercially,
high-latency conditions, and 81.5% under extreme loss conditions, indicating its wide adoption and significant impact on the global
respectively. H3’s connection migration remains robust, maintain- web infrastructure. As of April 1, 2024, 71.4% of desktop browsers
ing stable performance even in proxy-enhanced environments, en- and 70.8% of mobile browsers support HTTP/3 among the top 1000
suring seamless network transitions. The proxy has a more neutral websites [20], underscoring its growing relevance.
impact on H3, while it significantly enhances H2 performance, par- Despite prior research exploring the performance of QUIC [24,
ticularly when paired with BBR, resulting in a 90% improvement in 35, 40, 42, 49, 52, 57, 60, 64, 67, 72, 74, 77, 79], a critical gap remains
the single-stream file download experiment under severe network in understanding how these protocols perform in the presence
impairments. Any improvements observed in H3 under a proxy are of proxies. Proxies are ubiquitous in modern web architectures,
minor and do not fundamentally alter H3’s performance as they serving essential roles in content delivery, load balancing, and
do for H2. Importantly, while H2 with the right congestion con- security. However, the interaction between these next-generation
trol algorithm (CCA) can achieve performance comparable to H3, protocols and proxies is still underexplored, particularly in terms
H3’s performance is more robust, as it is less impacted by network of their impact on connection migration, performance in noisy
conditions, proxy settings, and CCA variations. networks, and overall user experience.
This work aims to address these gaps by providing a comprehen-
sive performance comparison of TCP/HTTP2 (H2) and QUIC/HTTP3
CCS CONCEPTS (H3) in both proxy and non-proxy environments, focusing on how
• Networks → Transport protocols; Network performance these protocols behave under real-world impairments such as packet
analysis; Network measurement. loss and network delay. Specifically, we measure key performance
metrics, including total request time and visual metrics like Speed
KEYWORDS Index [19], to characterize the performance of these protocols across
QUIC, HTTP, Multiplexing, Connection Migration, Proxy, Web various use cases such as single-stream, multi-stream, connection
Performance migration, and web page loading. These measurements are crit-
ical to understanding how H2 and H3 impact web performance
and user-perceived experience, particularly in complex network
environments involving proxies.
1 INTRODUCTION
This paper offers several novel contributions to the understand-
The rapid evolution of network technologies, driven by the increas- ing of H2 and H3 performance in diverse network environments,
ing demands of internet-based services, has led to significant ad- with a particular emphasis on proxy usage and connection migra-
vancements in communication protocols and network architecture. tion:
Among these advancements, the development of QUIC [39] and Comprehensive Performance Evaluation with Proxy Inte-
HTTP/3 [26] significantly improve the speed, reliability, and secu- gration: Unlike prior work, which predominantly focuses on direct
rity of web communications. QUIC, initially developed by Google connections, this paper provides the first thorough comparative
and later standardized by the IETF[2], serves as the foundation analysis of H2 and H3 performance in both proxy-enhanced and
for HTTP/3 and has the potential to reshape the Internet and its
applications and services.
non-proxy environments. Our results show that while proxies sig- gains depend heavily on effective prioritization strategies. Other
nificantly enhance H2’s performance, especially when paired with research has extended QUIC to multipath QUIC (MPQUIC) [28, 38],
the right congestion control algorithm (e.g., BBR), their impact on and new packet schedulers for MPQUIC [32, 61, 73] and upper-
H3 is more neutral due to QUIC’s inherent features. This compari- layer solutions [81] have followed. MultipathTester [29] compares
son sheds light on the practical implications for protocol selection the performance of MPTCP with MPQUIC on iOS. Several studies
in real-world proxy-based networks. have focused on QUIC congestion control [34, 37, 53], while others
First-of-its-Kind Analysis of Connection Migration under examine security and privacy [46, 50, 55, 56, 69]. Experimental
Proxy Conditions: To the best of our knowledge, this paper is the protocols inspired by QUIC, like TCPLS [62], DCQUIC [71], and
first to evaluate QUIC’s connection migration capabilities under MCQUIC [54], further show its potential.
proxy conditions, including scenarios involving IP address changes Connection Migration in QUIC Despite the importance of con-
and network impairments. Our results demonstrate H3’s ability to nection migration in QUIC for mobile and transitioning networks,
maintain low request time and ensure seamless user experience detailed analyses focused on this feature in diverse networking con-
during network transitions, highlighting its suitability for mobile texts are scarce. Google has demonstrated the benefits of connection
and dynamic networking environments. migration in a demo video [16], but empirical studies remain lim-
Experimentation with Congestion Control Algorithms ited. Tan et al. [70] discuss how QUIC uses connection migration
(CCAs) for H2 and H3: Through experiments with multiple CCAs to uniquely identify connections, proposing a Proactive Connec-
(e.g., BBR, Cubic, NewReno), this study provides insights into how tion Migration (PCM) mechanism to optimize network selection in
different CCAs affect H2 and H3 performance. We highlight condi- heterogeneous environments.
tions where BBR notably improves H2’s performance, while demon- QUIC with Proxy Exploring QUIC in proxy architectures is rela-
strating that H3’s internal congestion control mechanisms ensure tively sparse, but some studies have started to bridge this gap. Kosek
consistent performance across various network conditions, making et al. [47] introduced Secure Middlebox-Assisted QUIC (SMAQ),
it a reliable choice for broader use cases. enabling middleboxes in QUIC connections while preserving se-
All our study data and scripts are available on GitHub. curity, and demonstrated performance improvements in satellite
networks. Another study by Kosek et al. [44] evaluated QUIC and
HTTP/3 with and without performance-enhancing proxies (PEPs)
2 RELATED WORK in satellite networks, showing significant performance gains, espe-
Performance of QUIC Extensive research has explored QUIC’s cially in high-latency conditions. Kühlewind et al. [48] assessed the
enhancements over traditional protocols, emphasizing its ability to QUIC-based MASQUE proxying protocol for tunneling UDP and IP
significantly improve web browsing experiences. Early investiga- traffic, revealing benefits like local recovery in lossy links despite
tions by Carlucci et al. [27] demonstrated QUIC’s superior perfor- introducing overhead. However, these studies focus on different
mance over TCP and SPDY [75], particularly in terms of connection aspects of QUIC and proxies. Our work uniquely compares H2 and
setup time and robustness to packet loss. Cunha et al. [30] fur- H3 in proxy-enhanced environments, with a particular emphasis on
ther highlighted the conditions in which QUIC excels and when QUIC’s connection migration feature, evaluating the performance
it underperforms. QUIC’s evolution has led to efforts investigat- impacts of proxy and connection migration under various network
ing interoperability across implementations [40, 52, 66]. Long-term conditions.
studies by Kakhki et al. [42] and Piraux et al. [60] traced QUIC’s Research Gap and Study Focus This paper aims to fill these
progression over time. Additionally, Rüth et al. [63] examined QUIC gaps by systematically examining QUIC and HTTP/3’s perfor-
deployment and usage in its early stages, while QScanner [82] ana- mance across single-stream, multi-stream, connection migration,
lyzed early QUIC deployments. and web page loading scenarios. By focusing on the fine-grained
Research has also explored QUIC’s impact on various applica- performance aspects of QUIC and HTTP/3, especially the under-
tions. For video streaming, studies by Palmer et al. [59], Paiva et researched area of connection migration within complex architec-
al. [32], Zheng et al. [81], Shreedhar et al. [67], and Xu et al. [78] tures, this study provides nuanced insights that could guide future
have highlighted QUIC’s benefits. In web browsing, research by optimizations and implementations of these protocols in networks
Das et al. [31], Rüth et al. [64], Wolsing et al. [77], and Shreedhar containing proxies. This research not only fills a knowledge gap
et al. [67] have shown how QUIC can enhance user experiences. but provides experimental design and software for future studies
Studies on mixed workloads by Shreedhar et al. [67] and Wolsing to explore the scalability and robustness of QUIC and HTTP/3 in
et al. [77] extend these findings. Additionally, research has evalu- dynamic and varied network settings.
ated QUIC’s performance on different platforms, including mobile
environments [35] and satellite communications [33, 45]. Siag et
al. [68] also developed a predictive model for QUIC’s performance. 3 EXPERIMENTAL SETUP
Kempf et al. [43] presents an extension to the QUIC Interop Runner We use a hardware network test bed that is remotely accessible for
for testing the interoperability of QUIC implementations. networking researchers and educators [76]. The client and proxy
Features of QUIC Research on HTTP/2 and HTTP/3, such as machines run Ubuntu 20.04.6 LTS on Intel(R) Xeon(R) E5520 CPUs
the studies by Marx et al. [51] and Sander et al. [65], has provided with 16GB RAM, while the server runs Ubuntu 22.04.4 LTS on an
in-depth analysis of how resource multiplexing and prioritization Intel(R) Core(TM) i3-3240 CPU with 16GB RAM. These machines
affect web performance. These studies highlight that while H3’s are interconnected through a router via a 1 Gbps Ethernet network.
use of QUIC reduces HoL blocking compared to H2, real-world The ’tc netem’ utility [21] is used for bandwidth control, packet
2
 Table 1: Experiment Setup

Scenarios Clients Server Network Conditions Workloads Metrics

Proxygen (H3)
Small Files:
Curl (H2, H3)
Bandwidth: 10 Mbps 0KB, 10KB, 100KB
Single-Stream Request Chrome (H2, H3) Nginx Loss: 0, 2, 4 (%) Medium Files: Total Request Time
Wget (H2)
Delay: 0, 25, 50 (ms) 500KB, 1MB, 5MB
Quiche (H3)
Large Files: 10MB
aioquic (H3)
Bandwidth: 10 Mbps
Multi-Stream Request Curl (H2, H3) Nginx Loss: 0, 2, 4, 8, 12 (%) 20 Files: 1MB each Total Request Time
Delay: 0 ms
Curl (H2) Bandwidth: 10 Mbps
Connection Migration Wget (H2) Nginx Loss: 0, 2, 4 (%) One 5MB file Total Request Time
Quiche (H3) Delay: 0, 25, 50 (ms)
Bandwidth: 10 Mbps
Web Page Loading Chrome (H2, H3) Nginx Loss: 0, 2, 4(%) 18 popular local host Speed Index
Delay: 0, 25, 50 (ms) websites

loss, and delay manipulation. In all experiments, the bandwidth is request, connection migration, and web page loading. We employ
set to 10 Mbps, with specific loss and delay parameters detailed in Cubic as the CCA on the client side, and New Reno on the server
each experiment’s setup (see Table 1). We use a fixed bandwidth side for both QUIC and TCP. Cubic is the default CCA for most H3
to maintain controlled conditions, allowing us to isolate the effects clients and the default CCA on Linux. For QUIC, the New Reno
of proxy environments on the performance of H2 and H3. These is the only CCA that Nginx supports. Both H2 and H3 use TLS
bandwidth limitations, combined with varied loss and delay param- 1.3. Our experimental setup is detailed in Table 1, with the logical
eters on both uplink and downlink, represent realistic edge-case topology illustrated in Figure 1.
network conditions that induce unique protocol behaviors for root
cause analysis. The study by Zhang et al. [80] has already explored
performance under varying bandwidth, while both our work and
studies like [79] use fixed bandwidth with varied loss and delay
to focus specifically on how network impairments affect proto-
col performance, without introducing the additional complexity of
Figure 1: Baseline Experiment Logical Topology
fluctuating bandwidth.
We use Nginx [11] as the server and Envoy Proxy [7] as the
reverse proxy, both widely adopted in practice. Six clients are em- The workloads for single-stream, multi-stream, and connection
ployed: Proxygen [14], Curl [6], Chrome [4], Wget [22], Quiche [17], migration are random plaintext generated by the Faker library [8].
and aioquic [3], ensuring a representative sample. The selection of For web page loading, we followed the methodology of Marx et
clients, server configurations, and versions is detailed in Appendix al. [51] and Sander et al. [65], selecting 18 popular websites with
A.1 Table 2, informed by the QUIC workgroup’s implementation varying numbers of resources and sizes shown in Figure 2. The
list [18]. Our criteria included support for HTTP/3, adherence to websites were downloaded using Wget [22] and hosted locally
QUIC version 1, open-source availability, and popularity based on without external links on the Nginx server to eliminate network
GitHub stars. Moreover, we ensured diversity by including imple- variability.
mentations in different programming languages, aiming to reflect In the connection migration experiment, We extended Cloud-
a broad spectrum of real-world applications. flare’s Rust-based quiche client to support connection migration.
In each experiment, we conducted 10 runs. We use Total Request Specifically, we took inspiration from the design of Andriod’s Con-
Time as the metric in single-stream, multi-stream, and connection nection Manager [5] to detect changed interfaces/IP addresses, and
migration experiments, measuring from the client’s first request initiate the connection migration process as described in [39]. For
packet to the server until the client closes the connection. For web H2, we employed wget with and without range Requests [9], along
page loading, we use the Speed Index [19], a metric that measures with curl tests without range requests. Range requests in H2 facili-
how quickly content appears on the user’s screen. tate fetching a range of data. This allows us to explore H2’s ability
to pause and resume downloading in the change in connection
scenario. The experiment simulates IP address change after down-
3.1 Baseline Experiment Setup loading over 2MB of a 5MB test file to mimic real-world network
This experiment setup establishes the baseline for evaluating the transitions, evaluating how each protocol maintains connection
performance of H2 and H3 in single-stream request, multi-stream stability and download continuity during these transitions.
3
 Figure 2: Website Sizes and Resource Counts (a) 0% Loss, 0ms Delay

3.2 Proxy Experiment Setup

This experiment setup assesses the impact of introducing an Envoy
reverse proxy between the server and client, with loss and delay
applied between the proxy and the client. The reverse proxy breaks
the connection between the client and the server and establishes
a new connection with the server. We use BBR as the CCA for
both QUIC and TCP since it is the default CCA for QUIC on Envoy.
We disabled the proxy cache and retry features. The connection
bandwidth is uniformly set at 10 Mbps across all links. We chose
Envoy for its robust, production-grade capabilities and widespread
adoption by major companies like Google, Microsoft, and Amazon.
The network logical topology positions the Envoy between the
(b) 0% Loss, 50ms Delay
client and server, as detailed in the accompanying Figure 3.

Figure 3: Proxy Experiment Logical Topology

4 EXPERIMENTAL EVALUATION
In this section, we present the results of our experiments and our
analysis of the results.

4.1 Single-Stream Experiment Evaluation

Figure 4 presents the results of our single-stream experiments across (c) 4% Loss, 50ms Delay
various network conditions, highlighting the performance differ-
ences between H2 and H3. Figure 4: Single-Stream Results. The times represent the
Ideal Network Conditions Under ideal network conditions mean values over 10 runs.
(10 Mbps bandwidth, 0% packet loss, 0 ms delay), both H2 and H3
exhibited similar performance, taking approximately 9 seconds to
download a 10 MB file (see Figure 4a). The introduction of a proxy without the use of a proxy (Figure 4b). However, The introduction
resulted in a minor increase in download time for both protocols, of a proxy caused slight variations in performance for H3 clients,
adding roughly 0-1 seconds. This proxy overhead was slightly more such as curl and quiche, but overall, H3 maintained consistent per-
pronounced for H3 than for H2, likely due to Envoy Proxy’s experi- formance with minimal impact from the proxy. In contrast, H2’s
mental support for H3, compared to its mature, optimized support performance remained stable across different clients, suggesting
for H2. that H2 implementations are more mature and exhibit fewer dis-
Moderate Network Impairments In scenarios involving mod- crepancies between implementations. In scenarios with loss only
erate impairments (10 Mbps bandwidth, 0% packet loss, and 50 ms (10 Mbps bandwidth, 2-4% packet loss, 0 ms delay), both H2 and H3
delay), both H2 and H3 demonstrated comparable performance exhibited comparable performance.
4
 Severe Network Impairments Under severe network condi-
tions (10 Mbps bandwidth, 4% packet loss, and 50 ms delay), the
performance differences between H2 and H3 became more pro-
nounced (Figure 4c). H3 clients were able to complete the 10 MB
file download in about 15 seconds, whereas H2 clients took approx-
imately 106 seconds without a proxy. The introduction of a proxy
using the BBR CCA significantly improved H2’s performance, re-
ducing download times to around 10 seconds, representing a 90%
improvement. Notably, other CCAs like Cubic and New Reno did
not show this enhancement for H2, underlining the importance of
CCA selection in impaired networks. However, it’s crucial to note
that H2’s performance remains highly dependent on the chosen
CCA, unlike H3, which is less impacted by such variations. H3’s Figure 5: Multi-Stream Results. Each point represents the
performance remained consistent regardless of the CCA used, in- highest Total Request Time among 20 test files for each run.
dicating that QUIC’s internal congestion control mechanisms are A total of 10 runs were conducted for each loss level.
robust under such conditions.
Connection Establishment The QUIC connection starts with
a handshake that merges the TCP 3-way handshake and the TLS 4.2 Multi-Stream Experiment Evaluation
1.3 handshake into a single three-packet exchange. This process The resulting graph in Figure 5 shows the performance of H2 and
eliminates a full Round-Trip Time (RTT) in the QUIC startup phase. H3 under various loss levels with 20 streams. The data indicates that
While both protocols show similar connection establishment times when the packet loss is below 8%, H2 and H3 exhibit comparable
under ideal network conditions, H3’s advantages become evident performance. However, when the packet loss reaches or exceeds
under impaired conditions (Figure 4c). The quicker connection 8%, H3 significantly outperforms H2, with the performance gap
establishment does not significantly impact performance in optimal widening as the loss percentage increases. This demonstrates H3’s
conditions, but it becomes crucial in severely impaired networks. superior resilience to high packet loss conditions. Specifically, at
For instance, under conditions of 4% packet loss and 50ms delay, 12% packet loss without a proxy, H2 required an average of 113.42
H3 clients, on average, complete a 0KB file download 14.5% faster seconds to complete the download, whereas H3 completed the same
than their H2 counterparts. task in just 20.98 seconds, representing an 81.5% improvement.
Summary of Findings These experiments demonstrate that net- When downloading 20 1MB files concurrently, H3 consistently
work conditions significantly influence the performance of both H2, maintains stable download times, whereas H2’s download times
with and without a proxy. H3’s superior performance in high-loss vary significantly, particularly at a 12% loss level. This variabil-
and high-latency environments is attributed to QUIC’s advanced ity suggests that H2 struggles with higher loss levels, while H3’s
congestion control and loss recovery mechanisms, which ensure performance remains consistent.
accurate RTT measurements, efficient packet loss handling, and H3’s inherent mechanisms, such as QUIC’s ability to manage
adaptive probe timeouts. In contrast, H2’s performance varies more multiple streams within a single connection, contribute to its ro-
significantly with network conditions and is heavily influenced by bustness. Each stream in QUIC independently manages its flow
the chosen CCA. control and retransmission of lost data, making H3 less sensitive to
Impact of CCAs In proxy scenarios, the use of BBR can main- increases in the number of streams. This approach effectively solves
tain high throughput and low latency by dynamically adjusting the the HoL blocking problem in TCP. Overall, H3 is a more reliable
congestion window based on real-time bandwidth and RTT estima- choice compared to H2 in high-loss and multiplexing environments.
tions. This proactive congestion management is more effective than Analysis: The key advantage of H3 in multi-stream scenarios
loss-based algorithms like Cubic, which only reduce the conges- is rooted in its use of QUIC, which eliminates the HoL blocking
tion window upon detecting packet loss. While BBR improves H2’s problem commonly seen in TCP-based H2. In H2, packet loss in
performance significantly in proxy-enhanced environments, this one stream can cause delays in other streams due to TCP’s sequen-
improvement is highly dependent on the correct CCA choice. In tial packet delivery requirement. This issue is exacerbated as the
contrast, H3’s performance remains robust across different network number of streams increases or under high packet loss conditions,
conditions and CCAs, highlighting its superior consistency without leading to significant variability in download times. In contrast,
relying on external configurations like BBR. QUIC’s stream independence allows each stream to handle its own
Proxy Influence and Implementation Maturity The slight packet loss and recovery, ensuring that packet loss in one stream
overhead observed with proxies on H3 likely stems from the exper- does not impact others. This design enables H3 to maintain stable
imental support for H3 in Envoy Proxy, while H2 benefits from a performance across multiple streams, even as packet loss increases.
more mature and optimized implementation. As H3 support within Additionally, QUIC’s more sophisticated congestion control mech-
proxies matures, this overhead may decrease, potentially yielding anisms, which include accurate RTT measurements and dynamic
further performance improvements. For now, H3’s performance loss recovery, further enhance H3’s resilience. These mechanisms
remains robust across a variety of conditions, with the proxy intro- allow H3 to adapt quickly to changing network conditions, reducing
ducing a more neutral impact compared to H2, which sees positive the impact of packet loss and preventing the kind of performance
effects in proxy environments, especially when using BBR. degradation observed with H2.
5
 Stable IP IP Change Stable IP With Proxy IP Change With Proxy

(a) 0% Loss, 0ms Delay (b) 0% Loss, 50ms Delay (c) 4% Loss, 50ms Delay

Figure 6: Connection Migration Results. Mean Times of 10 Runs with Standard Deviation Error Bars.

Proxy Impact: The proxy has a neutral impact on H3, meaning between Wi-Fi and cellular networks. QUIC’s connection migra-
it does not fundamentally alter H3’s performance. While H3 may tion allows an ongoing session to continue without interruption,
see a minor impact under specific network conditions, these en- preserving the state of the connection even when the client’s IP
hancements are minimal compared to H2, which sees a significant address changes. This capability extends to proxy-enhanced en-
performance boost, particularly when using BBR. This makes H3 vironments, where H3 continues to maintain stable performance
more predictable and stable in complex network environments, despite the additional complexity introduced by the proxy. In con-
even with or without the use of a proxy. trast, TCP-based H2 requires a new connection to be established
following an IP change, leading to higher latency and increased
4.3 Connection Migration Experiment total request time. This issue is especially noticeable in clients that
Evaluation do not support the TCP range requests feature.
The results indicate that H3’s connection migration not only
Figure 6 displays the results of the connection migration exper-
maintains the session but also minimizes total request time, which
iments, comparing the performance of H3 and H2 clients under
is essential for real-time applications where reducing delays is
various network conditions. These results highlight the advantages
critical. This efficiency is a direct result of QUIC’s design, which
of QUIC’s connection migration feature. The H3 client (quiche_h3)
includes mechanisms to quickly re-establish connection parameters
consistently exhibited lower total request time across all scenar-
and resume data transmission following an IP change. The fact that
ios involving IP address changes. Notably, under conditions of 4%
H3 rarely experiences failed migrations, even under high-loss and
packet loss and 50ms delay, the H2 client (wget_h2_resume) took an
high-delay conditions, further underscores its robustness.
average of 56.7 seconds to complete the download following an IP
Impact of TCP Range Requests The use of TCP range requests
address change without a proxy, whereas the H3 client (quiche_h3)
in H2 mitigates some disadvantages associated with the absence
required only 6.6 seconds. This represents an 88.36% improvement
of inherent connection migration. By enabling the resumption of
in performance.
downloads from the point of interruption, range requests provide
Across all tested network conditions, H2 clients lacking the
a workaround to maintain connection continuity. However, this
TCP range requests capability (e.g., wget_h2_no_resume and curl
approach is more suited to static content downloads, where data
_h2_no_resume) showed significantly higher total request time
can be easily segmented, rather than real-time data streams that
and were more adversely affected by IP changes and poor network
require continuous and immediate transmission.
conditions. However, when the TCP range requests feature was em-
Role of Proxies and Congestion Control The significant
ployed (wget_h2_resume), H2’s performance became comparable
performance improvement of H2 when using a proxy can be largely
to H3 in scenarios involving either packet loss or delay alone. While
attributed to the implementation of the BBR CCA. BBR enhances
the TCP range requests feature can be advantageous for specific use
throughput by dynamically adjusting to available bandwidth and
cases like file downloads, H3 is generally more suited for a broader
reducing latency, which aids H2 in recovering more efficiently
range of applications, including real-time environments and the
from connection interruptions. This illustrates the potential role
noisy network conditions often encountered in mobile scenarios.
of proxies in enhancing the performance of TCP-based protocols,
Under conditions characterized by high packet loss and high
albeit with added complexity. Conversely, H3’s inherent features
delay, there were occasional instances where only 1 or 2 QUIC con-
reduce its reliance on proxies for performance optimization, making
nection migrations failed. The results also indicate that H2, when
it a more suitable choice for environments where simplicity and
used with a proxy, significantly outperforms direct H2, primarily
robustness are paramount.
due to the proxy’s use of the BBR CCA, as discussed in Section 4.1.
By leveraging QUIC’s native capabilities, H3 maintains a con-
Analysis The primary advantage of H3’s connection migration
sistent performance advantage in dynamic and unreliable network
feature is rooted in QUIC’s ability to seamlessly manage changes in
network paths, such as those that occur when a device transitions
6
conditions, making it a more reliable and effective option for sce- pages, which often consist of numerous small objects that need
narios that require robust connection migration. to be loaded simultaneously. The improved Speed Index for H3
in impaired conditions demonstrates that QUIC’s design is more
suited to real-world web traffic patterns, which frequently involve
4.4 Web Page Loading Experiment Evaluation high concurrency.
In this experiment, we evaluated the performance of H2 and H3 Proxy Impact and Congestion Control: The use of a proxy,
protocols using the Speed Index as the primary metric for assessing particularly with BBR as the CCA, helps mitigate the effects of
user experience during web page loading. The Speed Index mea- network impairments by optimizing throughput and reducing la-
sures how quickly content appears on the user’s screen, with scores tency. The proxy’s positive impact on H2 performance highlights
of 0-3.4 seconds indicating fast performance, 3.4-5.8 seconds indicat- how BBR’s proactive congestion management can alleviate some
ing moderate performance, and scores over 5.8 seconds indicating of the drawbacks of TCP’s loss-based congestion control, reducing
slow performance. the frequency and duration of HoL blocking events. For H3, the
Under baseline conditions (0% loss, and 0ms delay), as shown in more consistent performance with or without a proxy underscores
Figure 7a, the performance of H2 and H3 varied across different QUIC’s capability to manage congestion and packet loss internally,
websites. Overall, H2 and H3 were comparable, with both protocols making it less reliant on external optimizations provided by proxies.
predominantly achieving a Speed Index within the "fast" category. By leveraging its advanced multiplexing and independent stream
When a proxy was introduced, the impact on performance varied: management capabilities, H3 delivers a more resilient and efficient
some websites experienced better performance while others showed web browsing experience, making it particularly well-suited for
slight degradation. Notably, more than half of web pages performed environments with variable and challenging network conditions.
better with a proxy under no loss and no delay conditions for both
H2 and H3. When loss and delay were introduced, nearly all web
pages achieved better or the same performance compared to direct
requests.
In the impaired network scenario (4% packet loss, and 50ms 4.5 Discussion
delay), as shown in Figure 7c, H2’s performance significantly dete- Across all experiments, the results consistently highlight the supe-
riorated, with many websites falling into the "moderate" or "slow" rior performance of H3 over H2 in a variety of network conditions,
categories. In contrast, H3 demonstrated greater resilience, main- particularly in scenarios involving packet loss, delay, and high con-
taining better performance with most websites remaining in the currency. The fundamental architectural differences between H2
"fast" or lower "moderate" categories. While H2’s performance im- and H3, particularly the underlying transport protocols (TCP for
proved with the use of a proxy and BBR, this improvement is largely H2 and QUIC for H3), play a crucial role in these performance
due to the dependency on BBR, as discussed in §4.1. H3, by compari- disparities.
son, exhibits strong performance in handling network impairments 1. QUIC’s Robustness to Network Impairments: One of the
without needing reliance on external elements like specific CCAs, most significant advantages of H3 is its resilience in impaired net-
further demonstrating its robustness. Additionally, larger websites work environments. QUIC’s design, which includes features like
with more resources generally had higher Speed Index scores, par- connection migration, independent stream management, and ad-
ticularly under impaired conditions. In the less impaired network vanced loss recovery mechanisms, ensures that H3 can maintain
scenario (2% packet loss, and 25ms delay), we observed similar con- stable performance even under high packet loss and latency condi-
clusions to the 4% loss and 50ms delay scenario, but with lower tions.
Speed Index scores. 2. Efficient Multiplexing and Avoidance of HoL Blocking: A
Analysis: The observed differences in web page loading perfor- recurring theme in the experiments is H3’s ability to handle multiple
mance between H2 and H3 can be attributed to QUIC’s inherent streams efficiently. Unlike H2, where packet loss in one stream
advantages in handling multiplexed connections. In H2, multiplex- can cause delays in others due to TCP’s sequential nature, QUIC
ing over a single TCP connection can still suffer from HoL blocking enables each stream to manage its flow control and retransmission
if packet loss occurs, as all streams within the connection are af- independently. This feature minimizes the impact of packet loss
fected by the loss. This is particularly problematic for loading web on overall performance, making H3 particularly well-suited for
pages with many resources, where the delay in one stream can web page loading scenarios with numerous small resources. The
delay others. In contrast, QUIC, used by H3, avoids HoL blocking ability to avoid HoL blocking directly contributes to H3’s better
by managing each stream independently, allowing lost packets to Speed Index scores and consistent performance in multi-stream
be retransmitted without affecting the delivery of other streams. experiments.
This results in a smoother loading experience and a better Speed 3. Role of Congestion Control: The experiments also under-
Index, even under challenging network conditions. score the impact of CCAs on protocol performance. While both H2
Efficiency in Multiplexing: H3’s better handling of multiplex- and H3 can benefit from advanced CCAs like BBR, QUIC’s internal
ing not only reduces the impact of packet loss but also optimizes congestion control mechanisms appear more adept at handling
the utilization of available bandwidth. By maintaining separate varying network conditions. The use of BBR in proxies signifi-
flow control and loss recovery for each stream, QUIC ensures that cantly boosts H2’s performance by reducing latency and optimizing
multiple resources can be fetched concurrently without waiting throughput. However, H3’s inherent design makes it less reliant on
for others to complete. This capability is crucial for modern web external congestion management.
7
 H3 Direct H2 Direct H3 With Proxy H2 With Proxy

(a) 0% Loss, 0ms Delay (b) 0% Loss, 50ms Delay (c) 4% Loss, 50ms Delay

Figure 7: Web Page Loading Results. Mean Times of 10 Runs with Standard Deviation Error Bars.

4. Connection Migration Capability: QUIC’s connection mi- reveal how they affect QUIC’s performance, offering insights into
gration feature offers a clear advantage in scenarios involving net- optimizing configurations for specific use cases such as real-time
work changes, such as mobile environments where devices fre- applications, video streaming, and mobile networks. Examining
quently switch between Wi-Fi and cellular networks. This capa- these factors could improve the efficiency and adaptability of H3 in
bility allows QUIC to seamlessly maintain connection continuity diverse scenarios.
and low request times despite IP address changes. Notably, QUIC’s Additionally, investigating the role of proxies in optimizing web
connection migration remains robust even in proxy-enhanced en- protocols, especially in edge computing and CDN environments,
vironments, further demonstrating its resilience and suitability for would be valuable. Future work could enhance H3 support in prox-
dynamic network architectures. In contrast, TCP lacks this flexibil- ies and develop specific optimizations for H3, particularly for high-
ity, resulting in higher latency and connection interruptions, even latency or lossy networks. Moreover, studies on security and privacy
when augmented with features like TCP range requests, which are implications related to QUIC’s fast connection establishment and
only beneficial for static downloads rather than real-time applica- migration could assess their impact on data integrity and confi-
tions. dentiality in scenarios like man-in-the-middle attacks or network
5. Proxy Usage and Performance Impact: The experiments handoffs. This research is essential for securing H3 in sensitive
reveal that proxies can significantly enhance H2 performance, es- environments and large-scale deployments under real-world traffic
pecially in impaired networks, by leveraging advanced CCAs and conditions.
optimizing connection handling. However, the impact on H3 is
less pronounced, suggesting that QUIC’s internal optimizations 6 CONCLUSION
are sufficient to manage most network conditions effectively. This
This study demonstrates H3’s superior performance over H2, es-
makes H3 a more versatile choice in various deployment scenarios,
pecially in challenging network conditions with high packet loss
reducing the dependency on complex proxy configurations.
and latency. H3’s features, such as connection migration and multi-
6. Practical Implications: The findings suggest that H3 is better
plexing, allow it to maintain stable performance, even with a proxy.
equipped to handle modern web traffic patterns, characterized by
Unlike H2, which relies on the right CCA, H3 delivers consistent
high concurrency, frequent network changes, and varying quality of
reliability across diverse scenarios.
service. H3’s design aligns well with the requirements of real-time
The main takeaway is H3’s robustness in both proxy and non-
applications, mobile browsing, and environments with challenging
proxy environments, making it a more dependable choice for mod-
network conditions. As such, the adoption of H3 can lead to im-
ern web communication. H3 consistently outperforms H2 without
proved user experiences, reduced latency, and more efficient use of
the need for external optimizations.
network resources.
In conclusion, H3’s design ensures resilient and efficient oper-
Overall, the comprehensive evaluation across different scenarios
ation in both stable and unstable networks, solidifying its role as
demonstrates that QUIC’s advanced features provide H3 with a
the preferred protocol for future web communication.
significant edge over H2 in terms of performance, reliability, and
adaptability. These findings have broader implications for the future
of web protocols, particularly as the demand for faster, more reliable REFERENCES
internet communication continues to grow. [1] 2013. Chromium Blog: Experimenting with QUIC. https://blog.chromium.org/
2013/06/experimenting-with-quic.html Accessed: May 8, 2024.
[2] 2024. https://en.wikipedia.org/wiki/QUIC
[3] 2024. aioquic. https://github.com/aiortc/aioquic Accessed: May 8, 2024.
5 FUTURE WORK [4] 2024. chrome. https://developer.chrome.com/blog/chrome-for-testing/ Accessed:
Future research should focus on exploring the interaction of differ- May 8, 2024.
[5] 2024. ConnectivityManager. https://developer.android.com/reference/android/
ent CCAs with QUIC across various network environments. Beyond net/ConnectivityManager Accessed: May 8, 2024.
BBR, testing algorithms like Cubic, NewReno, and newer ones could [6] 2024. curl. https://curl.se/ Accessed: May 8, 2024.
8
 [7] 2024. Envoy Proxy. https://www.envoyproxy.io/ Accessed: May 8, 2024. [41] Matt Joras and Yang Chi. 2022. How Facebook is bringing QUIC to bil-
[8] 2024. Faker’s documentation. https://faker.readthedocs.io/en/master/ Accessed: lions. https://engineering.fb.com/2020/10/21/networking-traffic/how-facebook-
May 27, 2024. is-bringing-quic-to-billions/ Accessed: May 8, 2024.
[9] 2024. HTTP range requests. https://developer.mozilla.org/en-US/docs/Web/ [42] Arash Molavi Kakhki, Samuel Jero, David Choffnes, Cristina Nita-Rotaru, and
HTTP/Range_requests Accessed: May 27, 2024. Alan Mislove. 2017. Taking a long look at QUIC: an approach for rigorous
[10] 2024. nghttp3. https://github.com/ngtcp2/nghttp3 Accessed: May 8, 2024. evaluation of rapidly evolving transport protocols. In proceedings of the 2017
[11] 2024. Nginx. https://www.nginx.com/ Accessed: May 8, 2024. internet measurement conference. 290–303.
[12] 2024. nodejs. https://nodejs.org/en Accessed: May 8, 2024. [43] Marcel Kempf, Benedikt Jaeger, Johannes Zirngibl, Kevin Ploch, and Georg Carle.
[13] 2024. OpenSSL. https://github.com/openssl/openssl Accessed: Sep 4, 2024. 2024. QUIC on the Fast Lane: Extending Performance Evaluations on High-rate
[14] 2024. Proxygen. https://github.com/facebook/proxygen Accessed: May 8, 2024. Links. Computer Communications 223 (2024), 90–100.
[15] 2024. Puppeteer. https://pptr.dev/ Accessed: May 8, 2024. [44] Mike Kosek, Hendrik Cech, Vaibhav Bajpai, and Jörg Ott. 2022. Exploring prox-
[16] 2024. QUIC Connection Migration demo. https://drive.google.com/file/d/1DlMI_ ying QUIC and HTTP/3 for satellite communication. In 2022 IFIP Networking
3MOxnWarvEVfzKxFqmD7c-u1cYG/view Accessed: May 8, 2024. Conference (IFIP Networking). IEEE, 1–9.
[17] 2024. quiche. https://github.com/cloudflare/quiche Accessed: May 8, 2024. [45] Mike Kosek, Hendrik L. Cech, Vaibhav Bajpai, and Jörg Ott. 2022. Exploring
[18] 2024. quicwg. https://github.com/quicwg/base-drafts/wiki/Implementations Proxying QUIC and HTTP/3 for Satellite Communication. 2022 IFIP Networking
Accessed: May 8, 2024. Conference (IFIP Networking) (2022), 1–9.
[19] 2024. Speed Index. https://developer.chrome.com/docs/lighthouse/performance/ [46] Mike Kosek, Luca Schumann, Robin Marx, Trinh Viet Doan, and Vaibhav Bajpai.
speed-index Accessed: May 27, 2024. 2022. DNS privacy with speed?: evaluating DNS over QUIC and its impact on
[20] 2024. State of the Web. https://httparchive.org/reports/state-of-the-web Ac- web performance. Proceedings of the 22nd ACM Internet Measurement Conference
cessed: May 8, 2024. (2022).
[21] 2024. tc-netem. https://man7.org/linux/man-pages/man8/tc-netem.8.html [47] Mike Kosek, Benedikt Spies, and Jörg Ott. 2023. Secure Middlebox-Assisted QUIC.
Accessed: May 8, 2024. In 2023 IFIP Networking Conference (IFIP Networking). IEEE, 1–9.
[22] 2024. wget. https://www.gnu.org/software/wget/ Accessed: May 8, 2024. [48] Mirja Kühlewind, Matias Carlander-Reuterfelt, Marcus Ihlar, and Magnus West-
[23] Nick Banks. 2024. Deploying HTTP/3 on Windows Server at Scale. erlund. 2021. Evaluation of QUIC-based MASQUE proxying. In Proceedings of the
https://techcommunity.microsoft.com/t5/networking-blog/deploying-http-3- 2021 Workshop on Evolution, Performance and Interoperability of QUIC. 29–34.
on-windows-server-at-scale/ba-p/2839394#:~:text=As%20seen%20in%20the% [49] Fan Liu and Patrick Crowley. 2023. Security and Performance Characteristics of
20last,a%2060%25%20reduction%20at%20P99. Accessed: May 8, 2024. QUIC and HTTP/3. Proceedings of the 10th ACM Conference on Information-Centric
[24] Divyashri Bhat, Amr Rizk, and Michael Zink. 2017. Not so QUIC: A Performance Networking (2023).
Study of DASH over QUIC. Proceedings of the 27th Workshop on Network and [50] Robert Lychev, Samuel Jero, Alexandra Boldyreva, and Cristina Nita-Rotaru. 2015.
Operating Systems Support for Digital Audio and Video (2017). How Secure and Quick is QUIC? Provable Security and Performance Analyses.
[25] Mike Bishop. 2021. Akamai Blog | HTTP/3 and QUIC: Past, Present, and Fu- 2015 IEEE Symposium on Security and Privacy (2015), 214–231.
ture. https://www.akamai.com/blog/performance/http3-and-quic-past-present- [51] Robin Marx, Tom De Decker, Peter Quax, and Wim Lamotte. 2019. Resource
and-future Accessed: May 8, 2024. Multiplexing and Prioritization in HTTP/2 over TCP Versus HTTP/3 over QUIC.
[26] Mike Bishop. 2022. RFC 9114: HTTP/3. https://datatracker.ietf.org/doc/rfc9114/ In International Conference on Web Information Systems and Technologies.
Accessed: May 8, 2024. [52] Robin Marx, Joris Herbots, Wim Lamotte, and Peter Quax. 2020. Same Standards,
[27] Gaetano Carlucci, Luca De Cicco, and Saverio Mascolo. 2015. HTTP over UDP: Different Decisions: A Study of QUIC and HTTP/3 Implementation Diversity.
an experimental investigation of QUIC. Proceedings of the 30th Annual ACM Proceedings of the Workshop on the Evolution, Performance, and Interoperability of
Symposium on Applied Computing (2015). QUIC (2020).
[28] Quentin De Coninck and Olivier Bonaventure. 2017. Multipath QUIC: Design [53] Ayush Mishra, Sherman Lim, and Ben Leong. 2022. Understanding speciation
and Evaluation. Proceedings of the 13th International Conference on emerging in QUIC congestion control. Proceedings of the 22nd ACM Internet Measurement
Networking EXperiments and Technologies (2017). Conference (2022).
[29] Quentin De Coninck and Olivier Bonaventure. 2019. MultipathTester: Comparing [54] Louis Navarre, Olivier Pereira, and Olivier Bonaventure. 2023. MCQUIC: Multi-
MPTCP and MPQUIC in Mobile Environments. 2019 Network Traffic Measurement cast and unicast in a single transport protocol. arXiv preprint arXiv:2309.06633
and Analysis Conference (TMA) (2019), 221–226. (2023).
[30] Bruno Volpato Da Cunha, Xiaochen Li, Wayne Wilson, and Khaled Harfoush. [55] Marcin Nawrocki, Raphael Hiesgen, Thomas C. Schmidt, and Matthias Wählisch.
2023. Performance Benchmarking of the QUIC Transport Protocol. In 2023 2021. QUICsand: quantifying QUIC reconnaissance scans and DoS flooding
IEEE 20th Consumer Communications & Networking Conference (CCNC). 206–212. events. Proceedings of the 21st ACM Internet Measurement Conference (2021).
https://doi.org/10.1109/CCNC51644.2023.10060785 [56] Marcin Nawrocki, Pouyan Fotouhi Tehrani, Raphael Hiesgen, Jonas Mücke,
[31] Somak R Das. 2014. Evaluation of QUIC on web page performance. Ph. D. Disser- Thomas C. Schmidt, and Matthias Wählisch. 2022. On the interplay between
tation. Massachusetts Institute of Technology. TLS certificates and QUIC performance. Proceedings of the 18th International
[32] Thomas William do Prado Paiva, Simone Ferlin, Anna Brunstrom, Ozgu Alay, Conference on emerging Networking EXperiments and Technologies (2022).
and Bruno Yuji Lino Kimura. 2023. A First Look at Adaptive Video Streaming [57] Késsia Thais Cavalcanti Nepomuceno, Igor Nogueira de Oliveira, Rafael Roque
over Multipath QUIC with Shared Bottleneck Detection. Proceedings of the 14th Aschoff, Daniel Bezerra, Maria Silvia Ito, Wesley Melo, Djamel Fawzi Hadj Sadok,
Conference on ACM Multimedia Systems (2023). and Géza Szabó. 2018. QUIC and TCP: A Performance Evaluation. 2018 IEEE
[33] Sebastian Endres, Jörg Deutschmann, Kai-Steffen Jens Hielscher, and Reinhard Symposium on Computers and Communications (ISCC) (2018), 00045–00051.
German. 2022. Performance of QUIC Implementations Over Geostationary [58] nghttp2 Team. 2024. nghttp2. https://nghttp2.org/ Accessed: May 8, 2024.
Satellite Links. ArXiv abs/2202.08228 (2022). [59] Mirko Palmer, Thorben Krüger, Balakrishnan Chandrasekaran, and Anja Feld-
[34] Mathis Engelbart and Jörg Ott. 2021. Congestion control for real-time media mann. 2018. The QUIC Fix for Optimal Video Streaming. Proceedings of the
over QUIC. Proceedings of the 2021 Workshop on Evolution, Performance and Workshop on the Evolution, Performance, and Interoperability of QUIC (2018).
Interoperability of QUIC (2021). [60] Maxime Piraux, Quentin De Coninck, and Olivier Bonaventure. 2018. Observing
[35] Anirudh Ganji and Muhammad Shahzad. 2021. Characterizing the Performance the Evolution of QUIC Implementations. Proceedings of the Workshop on the
of QUIC on Android and Wear OS Devices. 2021 International Conference on Evolution, Performance, and Interoperability of QUIC (2018).
Computer Communications and Networks (ICCCN) (2021), 1–11. [61] Alexander Rabitsch, Per Hurtig, and Anna Brunström. 2018. A Stream-Aware
[36] Alessandro Ghedini and Rustam Lalkaka. 2019. HTTP/3: the past, the present, Multipath QUIC Scheduler for Heterogeneous Paths. Proceedings of the Workshop
and the future. https://blog.cloudflare.com/http3-the-past-present-and-future on the Evolution, Performance, and Interoperability of QUIC (2018).
Accessed: May 8, 2024. [62] Florentin Rochet, Emery Kouassi Assogba, Maxime Piraux, Korian Edeline, Benoit
[37] Habtegebreil Kassaye Haile, Karl-Johan Grinnemo, Simone Ferlin Oliveira, Per Donnet, and Olivier Bonaventure. 2021. TCPLS: modern transport services with
Hurtig, and Anna Brunström. 2022. Performance of QUIC congestion control TCP and TLS. Proceedings of the 17th International Conference on emerging
algorithms in 5G networks. Proceedings of the ACM SIGCOMM Workshop on 5G Networking EXperiments and Technologies (2021).
and Beyond Network Measurements, Modeling, and Use Cases (2022). [63] Jan Rüth, Ingmar Poese, Christoph Dietzel, and Oliver Hohlfeld. 2018. A First
[38] Vany Ingenzi, Tom Barbette, and Olivier Bonaventure. [n. d.]. " Enhancing the Look at QUIC in the Wild. ArXiv abs/1801.05168 (2018).
performance of a single connection using Multi-Path QUIC. ([n. d.]). [64] Jan Rüth, Konrad Wolsing, Klaus Wehrle, and Oliver Hohlfeld. 2019. Perceiv-
[39] Jana Iyengar and Martin Thomson. 2022. QUIC: A UDP-Based Multiplexed and ing QUIC: do users notice or even care? Proceedings of the 15th International
Secure Transport RFC 9000. https://datatracker.ietf.org/doc/rfc9000/ Accessed: Conference on Emerging Networking Experiments And Technologies (2019).
May 8, 2024. [65] Constantin Sander, Ike Kunze, and Klaus Wehrle. 2022. Analyzing the Influence
[40] Benedikt Jaeger, Johannes Zirngibl, Marcel Kempf, Kevin Ploch, and Georg Carle. of Resource Prioritization on HTTP/3 HOL Blocking and Performance. In Traffic
2023. QUIC on the Highway: Evaluating Performance on High-rate Links. 2023 Monitoring and Analysis.
IFIP Networking Conference (IFIP Networking) (2023), 1–9.
9
[66] Marten Seemann and Jana Iyengar. 2020. Automating QUIC interoperability with the standardization on the horizon. Proceedings of the 21st ACM Internet
testing. In Proceedings of the Workshop on the Evolution, Performance, and Interop- Measurement Conference (2021).
erability of QUIC. 8–13.
[67] Tanya Shreedhar, Rohit Panda, Sergey Podanev, and Vaibhav Bajpai. 2022. Evalu-
ating QUIC Performance Over Web, Cloud Storage, and Video Workloads. IEEE A RESEARCH METHODS
Transactions on Network and Service Management 19 (2022), 1366–1381.
[68] Lior Siag, Gil Einziger, Wuji Liu, and Chase Wu. 2023. Characterization and A.1 Clients and Server Protocols and
Prediction of QUIC’s Performance Under Different Network Conditions. In ICC Implementations
2023-IEEE International Conference on Communications. IEEE, 3824–3829.
[69] Mukesh Soni and Brajendra Singh Rajput. 2020. Security and Performance Evalu- The clients and server protocols and implementations are shown
ations of QUIC Protocol. Lecture Notes on Data Engineering and Communications
Technologies (2020).
in Table 2.
[70] Lizhuang Tan, Wei Su, Yanwen Liu, Xiaochuan Gao, Na Li, and Wei Zhang. 2020.
Proactive Connection Migration in QUIC. MobiQuitous 2020 - 17th EAI Interna-
tional Conference on Mobile and Ubiquitous Systems: Computing, Networking and Table 2: Clients and Server Protocols and Implementations
Services (2020).
[71] Lizhuang Tan, Wei Su, Yanwen Liu, Xiaochuan Gao, and Wei Zhang. 2021. DC-
QUIC: Flexible and Reliable Software-defined Data Center Transport. IEEE INFO-
COM 2021 - IEEE Conference on Computer Communications Workshops (INFOCOM Client Protocol Language Version
WKSHPS) (2021), 1–8.
[72] Martino Trevisan, Danilo Giordano, and Ali Safari Khatouni. 2021. Measur-
Proxygen
QUIC/H3 C++ v2024.03.25.00
ing HTTP/3: Adoption and Performance. 19th Mediterranean Communica- [14]
tion and Computer Networking Conference (2021). https://doi.org/10.1109/
MedComNet52149.2021.9501274
OpenSSL [13]: v3.3.1,
Curl [6] QUIC/H3 C nghttp3 [10]: v1.1.0,
[73] Jing Wang, Yunfeng Gao, and Chenren Xu. 2019. A Multipath QUIC Scheduler
for Mobile HTTP/2. Proceedings of the 3rd Asia-Pacific Workshop on Networking Curl:8.7.2-DEV
(2019).
[74] Peng Wang, Carmine Bianco, Janne Riihijärvi, and Marina Petrova. 2018. Imple- Curl [6] TCP/H2 C nghttp2/1.40.0 [58]
mentation and Performance Evaluation of the QUIC Protocol in Linux Kernel.
Proceedings of the 21st ACM International Conference on Modeling, Analysis and Node.js [12]: v18.17.1,
Simulation of Wireless and Mobile Systems (2018). Puppeteer [15]: 22.6.1,
[75] Xiao Sophia Wang, Aruna Balasubramanian, Arvind Krishnamurthy, and David HeadlessChrome
Wetherall. 2014. How speedy is { SPDY } ?. In 11th usenix symposium on networked Chrome [4] TCP/H2 C, C++
systems design and implementation (nsdi 14). 387–399. /123.0.6312.58,
[76] Charlie Wiseman, Jonathan Turner, Michela Becchi, Patrick Crowley, John De- Puppeteer-har: 1.1.2
Hart, Mart Haitjema, Shakir James, Fred Kuhns, Jing Lu, Jyoti Parwatikar, et al.
2008. A remotely accessible network processor-based router for network experi- Node.js: v18.17.1,
mentation. In Proceedings of the 4th ACM/IEEE Symposium on Architectures for
Networking and Communications Systems. 20–29. Chrome [4] QUIC/H3 C, C++ Puppeteer: 22.6.1,
[77] Konrad Wolsing, Jan Rüth, Klaus Wehrle, and Oliver Hohlfeld. 2019. A perfor- HeadlessChrome
mance perspective on web optimized protocol stacks: TCP+TLS+HTTP/2 vs. /123.0.6312.58,
QUIC. Proceedings of the Applied Networking Research Workshop (2019).
[78] Shichang Xu, Subhabrata Sen, and Z. Morley Mao. 2020. CSI: inferring mobile Puppeteer-har: 1.1.2
ABR video adaptation behavior under HTTPS and QUIC. Proceedings of the
Fifteenth European Conference on Computer Systems (2020). Wget:1.20.3-
Wget [22] TCP/H2 C
[79] Alexander Yu and Theophilus A. Benson. 2021. Dissecting Performance of 1ubuntu2
Production QUIC. Proceedings of the Web Conference 2021 (2021).
[80] Xumiao Zhang, Shuowei Jin, Yi He, Ahmad Hassan, Z Morley Mao, Feng Qian, and Quiche: 0.20.0-47-
Zhi-Li Zhang. 2024. QUIC is not Quick Enough over Fast Internet. In Proceedings Quiche QUIC/H3 Rust
g098664eb
of the ACM on Web Conference 2024. 2713–2722.
[81] Zhilong Zheng, Yunfei Ma, Yanmei Liu, Furong Yang, Zhenyu Li, Yuanbo Aioquic:1.0.0-2-
Zhang, Jiuhai Zhang, Wei Shi, Wentao Chen, Ding Li, Qing An, Hai Hong, aioquic [3] QUIC/H3 Python
Hongqiang Harry Liu, and Ming Zhang. 2021. XLINK: QoE-driven multi-path ga6d91fb
QUIC transport in large-scale video services. Proceedings of the 2021 ACM SIG- TCP/H2
COMM 2021 Conference (2021). Nginx [11] C nginx/1.25.5
[82] Johannes Zirngibl, Philippe Buschmann, Patrick Sattler, Benedikt Jaeger, Julian QUIC/H3
Aulbach, and Georg Carle. 2021. It’s over 9000: analyzing early QUIC deployments

10