Articles

Monitor HTTP/3 Server Metrics for QUIC Connections (2026)

April 18, 2026 5 min read

HTTP/3, built on QUIC, is fundamentally different from HTTP/1.1 and HTTP/2, and so is how you monitor it.

Let’s see what a QUIC connection looks like from the server’s perspective.

# Simulate a client request and capture QUIC packets
# This assumes you have tcpdump installed and are running it as root.
# Replace 'eth0' with your actual network interface.
sudo tcpdump -i eth0 -w quic_capture.pcap udp port 443

# On the client side, use curl to make an HTTP/3 request
# Ensure your curl supports HTTP/3 (built with nghttp3 and ngtcp2)
curl --http3 https://your-server.com/some-path -v

You’ll see UDP packets, not TCP segments. Each UDP packet contains one or more QUIC frames. This is where the magic happens: QUIC multiplexes streams within a single UDP connection.

The QUIC Connection Lifecycle

Unlike TCP’s three-way handshake, QUIC uses a "0-RTT" or "1-RTT" handshake.

  1. Initial Handshake (0-RTT/1-RTT):

    • The client sends an Initial packet.
    • The server responds with its own Initial and Handshake packets.
    • If it’s a new connection, the server sends a Handshake packet containing its TLS certificate. The client verifies it and sends its Handshake packet.
    • From this point on, both sides can start sending application data within encrypted QUIC packets.
    • The key takeaway: QUIC negotiates security and connection parameters concurrently with its own connection establishment.

  2. Connection Migration:

    • If the client’s IP address or port changes (e.g., switching from Wi-Fi to cellular), QUIC can often maintain the connection. The client sends packets with a new source IP/port but the same Connection ID. The server, if configured, can accept this.

  3. Stream Multiplexing:

    • Within a single QUIC connection (identified by a Connection ID), multiple independent HTTP/3 streams can exist. These are bidirectional and can be initiated by either the client or server.
    • Each stream has its own flow control. This is a critical difference from HTTP/2, where stream multiplexing was built on top of TCP.

  4. Packet Loss and Congestion Control:

    • QUIC implements its own congestion control at the application layer over UDP. This means it can use algorithms like BBR or Cubic, independent of the OS’s TCP stack.
    • When a packet is lost, QUIC uses packet numbers to identify it, and acknowledgments (ACKs) carry information about received packet ranges.

Monitoring Your HTTP/3 Server

The metrics you’ll care about fall into several categories:

1. Connection Establishment & Health:

  • Active Connections: How many QUIC connections are currently open.
  • New Connections: Rate of new connection attempts.
  • Connection Errors: Failures during handshake, TLS negotiation, or packet processing.
    • Diagnosis: Look for logs from your web server (Nginx, Caddy, Envoy) or the QUIC implementation itself. Common errors include TLS handshake failed, Invalid packet number, Connection ID mismatch.
    • Fix: Ensure your server’s TLS configuration is valid and up-to-date. Check firewall rules for UDP port 443. If you see Invalid packet number, it might indicate packet reordering or loss before QUIC can establish reliability.
    • Why it works: QUIC relies on UDP. If UDP packets aren’t reaching the server or are being dropped by intermediate network devices, the handshake will fail.
  • Connection Migration Success/Failure: Monitor how often clients successfully migrate their connections.

2. Stream Activity:

  • Active Streams: Number of concurrent HTTP/3 streams.
  • New Streams: Rate of new stream initiations.
  • Stream Errors: Failures within a stream (e.g., application-level errors, flow control violations).
    • Diagnosis: Web server logs will show HTTP status codes. For QUIC-specific stream issues, you’ll need to dig into the QUIC library logs.
    • Fix: Address application errors (e.g., 5xx status codes). If you see Flow control limit reached, you might need to adjust the server’s receive window size for streams or connections.
    • Why it works: QUIC defines per-stream flow control. If the server can’t process data fast enough for a specific stream, it signals this, and the client stops sending on that stream.

3. Packet Processing & Performance:

  • Packets Received/Sent (UDP): Raw UDP traffic volume.
  • Bytes Received/Sent (UDP): Data transfer volume.
  • Packet Loss Rate: The crucial metric. QUIC’s performance is highly sensitive to packet loss.
    • Diagnosis: This is often inferred. If your server logs show a high number of retransmissions (a QUIC concept, not TCP), or if round-trip times (RTT) are consistently high and variable, it points to packet loss. Some QUIC libraries expose packet loss counters directly.
    • Fix: This is usually a network issue. Optimize network path, reduce buffer bloat, or consider using QUIC’s built-in congestion control features (like BBR) if your implementation supports it.
    • Why it works: QUIC’s reliability is built on packet acknowledgment and retransmission. High loss means more retransmissions, which directly impacts latency and throughput.
  • Packet Reordering: QUIC uses packet numbers to reorder packets. High reordering can degrade performance.
    • Diagnosis: Similar to packet loss, high reordering can be inferred from high RTTs and packet loss metrics if the QUIC stack has to do a lot of reordering work.
    • Fix: Network path optimization.
  • RTT (Round-Trip Time): Measure the time for a packet to go from server to client and back.
    • Diagnosis: Many QUIC libraries provide RTT estimates. You can also infer it from PING frames and their PONG responses.
    • Fix: Primarily network latency, but also affected by server processing time and packet loss.

4. TLS Metrics:

  • TLS Handshake Time: How long it takes to establish the secure channel.
  • TLS Version/Cipher Suite Usage: Ensure you’re using modern, secure protocols.
  • Certificate Validity: Monitor expiry.

Tools for Monitoring:

  • Web Server Metrics: Nginx (nginx-module-quic), Caddy, and Envoy often expose QUIC-specific metrics via Prometheus or other exporters.
  • QUIC Libraries: Libraries like lsquic, quiche, or ngtcp2 might have their own internal metrics or debugging interfaces.
  • Network Monitoring Tools: tcpdump, Wireshark (with QUIC dissector), and dedicated network performance monitoring solutions can provide packet-level insights.
  • Application Performance Monitoring (APM) Tools: Integrate with your web server’s metrics.

The most challenging aspect of monitoring HTTP/3 is that the underlying transport is UDP. Traditional TCP monitoring tools won’t tell you about QUIC connection state or stream behavior. You’re essentially monitoring a stateful application protocol running over a stateless datagram service.

When you’ve got all your QUIC metrics flowing, the next thing you’ll likely wrestle with is how to effectively alert on the subtle degradation of QUIC performance before it impacts users.

Want structured learning?

Take the full Http3 course →