ADC

HTTP3 over QUIC protocol

HTTP/2 over TCP is the preferred standard for sending multiple streams of HTTP requests over a single connection. But, in TCP transport mechanism there are certain limitations and latency issues in accessing websites and web applications. When you multiplex several requests over the same connection they are subjected to reliability of the same connection. If packet for one request is lost, all other multiplexed requests are delayed until the lost packet is detected and retransmitted. This causes head-of-line-blocking delays and latency issues.

For connection and transport delays, HTTP/3 uses QUIC instead of TCP protocol. The QUIC is an emerging protocol that uses UDP instead of TCP as its base transport. In HTTP-over-QUIC, you can multiplex several independent requests without depending on a single TCP connection. QUIC implements a reliable connection upon which, you can stream multiple HTTP requests. QUIC also incorporates TLS as an integrated component and not as an additional layer as in HTTP/1.1 or HTTP/2.

Advantage of using HTTP/3 protocol

Some of the important benefits of using QUIC protocol for HTTP/3 data transport is given below:

• Stream multiplexing • Stream and connection-level flow control • Low-latency connection establishment • Connection migration and resilience to NAT rebinding • Authenticated and encrypted header and payload

Transport stack in HTTP protocols

The below illustration shows transport stack in HTTP/1.1, HTTP/2 and HTTP/3 protocols.

Transport stack in HTTP protocols

How QUIC and HTTP/3 connection management works in NetScaler

The following illustration shows how QUIC and HTTP/3 connection management in a NetScaler appliance and how the components interact with each other.

How QUIC and HTTP/3 connection management works

Step 1: Client-side HTTP/3 request over QUIC protocol to NetScaler appliance. Step 2: Request forwarded by NetScaler AS HTTP/1.1 or HTTP/2 depending on back-end server support. Step 3: Response through HTTP/2 or HTTP/1.1 from back-end server to NetScaler. Step 4: ADC forwards the response as HTTP/3 response to client.

How HTTP/3 protocol works

In HTTP/3, when a client knows that an HTTP/3 server exists at a certain endpoint, it opens a QUIC connection. The QUIC protocol provides multiplexing and flow control. Within each stream, the basic unit of HTTP/3 communication is a frame. Each frame type serves a different purpose. For example, HEADERS and DATA frames form the basis of HTTP requests and responses.

Multiplexing of requests is performed using the QUIC stream abstraction. Each request-response pair consumes a single QUIC stream. Streams are independent of each other, so one stream that is blocked or suffers packet loss does not prevent progress on other streams. Server push is an interaction mode introduced in HTTP/2 which permits a server to push a request-response exchange to a client in anticipation of the client making the indicated request. This trades off network usage against a potential latency gain. Several HTTP/3 frames are used to manage server push, such as PUSH_PROMISE, MAX_PUSH_ID, and CANCEL_PUSH. As in HTTP/2, request and response fields are compressed for transmission. Because HPACK relies on in-order transmission of compressed field sections (a guarantee not provided by QUIC), HTTP/3 replaces HPACK with QPACK. QPACK uses separate unidirectional streams to modify and track field table state, while encoded field sections refer to the state of the table without modifying it.

How HTTP/3 protocol works

HTTP3 over QUIC protocol