Quick UDP Internet Connections (QUIC) is a general-purpose transport layer protocol designed to replace the Transmission Control Protocol (TCP) through its flexibility, built-in security, fewer performance issues, and faster adoption rate. Originally developed by Google, QUIC uses User Datagram Protocol (UDP) as the low‑level transport mechanism for moving packets between client and server. Notably, QUIC also incorporates Transport Layer Security (TLS) as an integral component, not as an additional layer like HTTP/1.1 and HTTP/2.

HTTP/3, based on QUIC, is the third major version of the Hypertext Transfer Protocol (HTTP) and was adopted as an IETF standard in 2022. QUIC+HTTP/3 were created to solve inherent limitations with TCP that constrain performance and user experience.

How Do APIs Work?

APIs are the “public face” of applications, revealing the functions they perform and the information they can provide, and defining the proper format of requests. When a developer creates and exposes the API for an application, it allows other applications to communicate with it.

In many cases, APIs save valuable developer time because they make commonly used functions readily available. Rather than duplicating the functionality of an existing application, developers can integrate the functionality into their applications by making calls to the existing application’s API.

Http diagram

High-level overview of HTTP transport stacks

QUIC+HTTP/3 Basics

The goal of QUIC is to provide a high‑performance, high‑reliability, and high‑security transport protocol for HTTP/3 (although QUIC is also suitable for non‑HTTP traffic).

If QUIC is entirely new to you, we recommend watching the introductory video below.


UDP is a simple, lightweight protocol that does not need a complex three-way handshake like TCP to establish the first connection. This simplicity makes UDP fast and connectionless, but it also means that it lacks the features essential for reliable and secure communication when compared to TCP.

QUIC is unique because it merges the benefits of both UDP and TCP protocols. While it is connectionless and leverages UDP for the low-level transport protocol to reduce the connection and transport delays, it is connection-oriented in the higher layers due to its reimplementation of TCP’s connection establishment and loss detection features which guarantee packet delivery. It handles the tasks of identifying lost data and completing re-transmissions to ensure a seamless user experience.

QUIC also incorporates TLS as an integral component, not as an additional layer as is the case with HTTP/1.1 and HTTP/2. This incorporation ensures the messages are encrypted by default.

Overview of a QUIC Network

The diagram below depicts the basic anatomy of a QUIC network. As seen in the diagram, the logical objects that contain HTTP/3 requests, responses, or any application data are QUIC streams. For transmission between network endpoints, QUIC streams are wrapped inside multiple logical layers.

Network Anatomy of Quic diagram

Anatomy of a QUIC stream

Starting from the outside in, the logical layers and objects are:

  • UDP Datagram – Contains a header specifying the source and destination ports (along with length and checksum data), followed by one or more QUIC packets. The datagram is the unit of information transmitted from client to server across the network.
  • QUIC Packet – Contains one QUIC header and one or more QUIC frames.
  • QUIC Header – Contains metadata about the packet. There are two types of header:
    • The long header, used during connection establishment.
    • The short header, used after the connection is established. It contains (among other data) the connection ID, packet number, and key phase (used to track which keys were used to encrypt the packet, in support of key rotation). Packet numbers are unique (and always increase) for a particular connection and key phase.
  • Frame – Contains the type, stream ID, offset, and stream data. Stream data is spread across multiple frames, but can be assembled using the connection ID, stream ID, and offset, which is used to present the chunks of data in the correct order.
  • Stream – A unidirectional or bidirectional flow of data within a single QUIC connection. Each QUIC connection can support multiple independent streams, each with its own stream ID. If a QUIC packet containing some streams is lost, this does not affect the progress of any streams not contained in the missing packet (this is critical to avoiding the head-of-line blocking experienced by HTTP/2). Streams can be bidirectional and created by either endpoint.
How QUIC Works with a TLS Handshake

A TLS handshake provides a secure connection between client and server. The encryption provided by QUIC requires TLS v1.3. As seen in the diagram below, QUIC keeps the TLS “Content Layer” which provides the cryptographic keys but replaces the “Record Layer” with its own transport mechanism.

QUIC also relies on TLS for authentication and negotiation of parameters that are critical to security and performance. Rather than a strict layering, the two protocols cooperate: QUIC uses the TLS handshake to establish a secure connection while TLS uses the reliability, ordered delivery, and record layer provided by QUIC.

At a high level, there are two main interactions between the TLS and QUIC components:

  • The TLS component sends and receives messages via the QUIC component, with QUIC providing a reliable stream abstraction to TLS.
  • The TLS component provides a series of updates to the QUIC component, including (a) new packet protection keys to install and (b) state changes such as handshake completion, the server certificate, etc.

HTTP/3 Support Options for QUIC TLS

QUIC TLS is a variant of TLS that is designed specifically for the QUIC protocol. Currently there are two options for users looking for HTTP/3 support in QUIC TLS:

  • OpenSSL QUIC Implementation – OpenSSL is currently working on implementing a complete QUIC stack on its own. This development will encapsulate all QUIC functionality within the implementation, making it much easier for HTTP/3 users to use the OpenSSL TLS API without worrying about QUIC-specific functionality.
  • Libraries supporting BoringSSL QUIC API – Various SSL libraries like BoringSSL, quicTLS, and LibreSSL (which started as a fork of OpenSSL) now provide QUIC TLS functionality by implementing the BoringSSL QUIC API. This is currently the only option for users wanting to use HTTP/3 because the OpenSSL QUIC TLS implementation is not ready yet.
Advantages of QUIC+HTTP/3

QUIC+HTTP/3 aim to enhance the performance of web applications by reducing latency and improving data delivery over unreliable networks. Their advantages include:

  • Reduced latency – Traditional protocols like TCP suffer from latency due to their connection setup process. QUIC+HTTP/3’s multiplexing capabilities allow them to establish connections more efficiently, resulting in lower latency for establishing connections and transmitting data.
  • Faster connection establishment – QUIC+HTTP/3 combines the TLS handshake and encryption setup into a single step, reducing the number of round trips required to establish a secure connection.
  • Multiplexing – By handling multiple streams of data within a single connection, QUIC+HTTP/3 allow for more efficient use of network resources and help avoid the head-of-line blocking problem, where one slow stream could delay others in traditional TCP connections.
  • Improved error correction – QUIC incorporates forward error correction techniques, which can help recover lost packets without needing retransmissions, reducing the impact of packet loss on performance.
  • Reduced packet loss impact – UDP is connectionless and allows for faster transmission without the need for the rigorous error-checking of TCP. This is particularly advantageous in scenarios where network conditions are less stable.
  • Adaptive congestion control – QUIC+HTTP/3 are designed to be more efficient and responsive than TCP’s congestion control, leading to better performance in varying network environments.
  • Migration support – QUIC+HTTP/3 can transition seamlessly between different network connections (e.g., switching from Wi-Fi to cellular) without disrupting the application’s performance.
  • Improved security – QUIC+HTTP/3 integrate encryption by default, enhancing security and privacy for data transmission. This encryption prevents eavesdropping and tampering with the data in transit.
  • NAT traversal – QUIC+HTTP/3’s use of UDP can help with Network Address Translation (NAT) traversal, making it more straightforward to establish connections in scenarios where traditional TCP connections might face issues.
  • Constant evolution – Since QUIC+HTTP/3 were designed to be implemented and updated by software rather than requiring changes to the underlying network infrastructure, they can be updated and improved more rapidly to adapt to changing network conditions and security concerns.
Learn About Using QUIC+HTTP/3 with NGINX

Explore the resources below to learn about NGINX’s QUIC+HTTP/3 implementation and other ways you can use QUIC+HTTP/3 for faster and more efficient communication.