Go's Journey to Official HTTP/3 and QUIC Implementation

Sep 7 2025 golang 15 minutes read (About 2187 words)

Revolutionizing Network Programming: Go’s Journey to QUIC and HTTP/3

image.png|300

Note: The core content was generated by an LLM, with human fact-checking and structural refinement.

Go, a language celebrated for its network programming capabilities, has been on a significant journey towards integrating the next generation of internet protocols: HTTP/3 and its underlying transport, QUIC. This journey, marked by years of community anticipation and strategic development, promises to bring revolutionary changes to Go’s network stack.

Background: Community Expectation

The Go community has long awaited official support for HTTP/3, making it one of the most requested features in recent years. As early as 2019, issue #32204 was created to track the progress of HTTP/3 support within the standard library. This anticipation grew steadily as major browsers like Chrome and Firefox, along with infrastructure providers such as Cloudflare, embraced HTTP/3.

Despite the community’s eagerness, the Go team adopted a cautious approach. Their main concerns included the stability of the QUIC and HTTP/3 IETF standards (RFC 9000 and RFC 9114). Premature implementation could have led to substantial refactoring costs. Additionally, the complexity of API design for new QUIC concepts like connections, streams, and 0-RTT (zero round-trip time) posed a significant challenge in integrating with Go’s existing net.Conn and net.Listener architecture. The sheer difficulty of implementing a high-performance, secure QUIC protocol stack, involving intricate mechanisms for traffic control, congestion control, and packet loss recovery, also contributed to the delay.

Go Team Strategy: Two Steps

With the standardization of QUIC and the integration of QUIC support into crypto/tls, the Go team initiated an official implementation plan based on a clear “two-step” strategy.

First Step: Building QUIC Foundation (x/net/quic)

The initial phase focused on developing a fundamental QUIC protocol implementation within golang.org/x/net/quic. This effort, tracked under proposal #58547, is a prerequisite for HTTP/3 support. The x/net/quic package has seen significant development and has transitioned from an internal package to a public one, signaling its growing maturity, though it remains experimental with potential API changes.

The core API concepts introduced by x/net/quic include:

Endpoint (formerly Listener): Used to listen for QUIC traffic on a network address.
Conn: Represents a QUIC connection between a client and server, capable of carrying multiple streams.
Stream: An ordered, reliable byte stream, analogous to a TCP connection, over which read and write operations are performed.

Here are illustrative Go code examples for interacting with x/net/quic:

// Client initiates a connection
conn, err := quic.Dial(ctx, "udp", "127.0.0.1:8000", &quic.Config{})

// Server accepts a connection
endpoint, err := quic.Listen("udp", "127.0.0.1:8000", &quic.Config{})
conn, err := endpoint.Accept(ctx)

// Create and accept streams on the connection
stream, err := conn.NewStream(ctx)
stream, err := conn.AcceptStream(ctx)

// Read from and write to the stream
n, err = stream.Read(buf)
n, err = stream.Write(buf)
stream.Close()

It’s important to note that the official Go implementation did not directly adopt the code from the popular third-party quic-go library. The reasons for this decision included differences in API design philosophy, code style, testing framework dependencies, and the belief that building from scratch might lead to easier long-term maintenance.

Second Step: Implementing HTTP/3 (x/net/http3)

Building upon the x/net/quic foundation, proposal #70914 officially launched the development of x/net/http3. Similar to x/net/quic, this implementation will initially be developed within an internal package (x/net/internal/http3) and will move to a public package after API stabilization and a final API review. Code changes show ongoing work on core components such as QPACK (HTTP/3’s header compression algorithm), Transport, Server, and request/response body transfer mechanisms.

Impact on Go Network Programming

The arrival of official QUIC and HTTP/3 support is set to bring revolutionary changes for Go developers:

Transparent Protocol Upgrade: It is anticipated that the net/http package will eventually provide seamless support for HTTP/3, similar to its integration of HTTP/2. This means developers might be able to use existing http.Get("https://example.com/") calls, and the underlying system could automatically leverage QUIC over UDP without code modifications.
Solving Head-of-Line Blocking: One of HTTP/3’s most significant advantages is its ability to mitigate TCP’s head-of-line (HOL) blocking. In HTTP/2, a lost packet on one stream could stall all other concurrent streams due to TCP’s loss recovery. With QUIC’s native multiplexing, lost packets only impact the specific streams where data was lost, leading to lower latency and higher throughput, particularly in unreliable network conditions. This is especially beneficial for Go microservices handling numerous concurrent requests.
Faster Connection Establishment: QUIC’s support for 0-RTT connection establishment can significantly reduce handshake latency, which is crucial for applications that frequently establish new connections.
Native Multiplexed Transport Layer: Beyond HTTP/3, a standardized QUIC API will pave the way for other advanced communication protocols, such as gRPC over QUIC and WebTransport, opening up possibilities for custom protocols requiring multiple streams and low-latency communication.

Ultimate Vision: QUIC in Linux Kernel

While the development of x/net/quic represents a major step in user space, the ultimate vision for QUIC involves native support within the Linux kernel. Recent patches submitted by Xin Long aim to bring kernel-level QUIC implementation to the mainline.

Why kernel integration for QUIC? Moving QUIC from user-space libraries (like x/net/quic or quic-go) into the kernel offers several key benefits:

Extreme Performance Potential: Kernel implementations can leverage modern network hardware’s protocol offload capabilities, such as Generic Segmentation Offload (GSO) and Generic Receive Offload (GRO). This would dramatically reduce CPU overhead when processing large volumes of small UDP packets, unlocking performance levels difficult to achieve with user-space implementations.
Broader Availability: With QUIC as a kernel-supported protocol (e.g., IPPROTO_QUIC), any application could use it via standard socket() system calls, just like TCP or UDP, without being tied to a specific user-space library.
Unified Ecosystem: Kernel-level support would foster a more integrated ecosystem, benefiting projects like Samba, NFS, and curl. For Go developers, this means the standard library and underlying system calls could universally leverage QUIC’s advantages.

Current Implementation and Challenges: The proposed kernel implementation aims for a highly integrated design, allowing developers to create QUIC sockets using familiar APIs like socket(AF_INET, SOCK_STREAM, IPPROTO_QUIC), followed by bind(), connect(), listen(), and accept(). Complex TLS handshake and certificate validation logic would remain in user space, similar to kernel TLS (kTLS), with the kernel taking over encrypted data flow post-handshake.

Initial benchmarks indicate that the kernel implementation’s performance is still below kTLS or native TCP due to the lack of hardware offload support, extra memory copies, and the overhead of QUIC header encryption. However, this gap is expected to narrow as the implementation matures and hardware vendors provide more support. Full kernel-state QUIC integration is anticipated no earlier than 2026.

quic-go (Third-Party Library)

Before official Go support for QUIC and HTTP/3 emerged, the third-party library quic-go, maintained by Marten Seemann, became the de facto standard in the Go ecosystem. Described as a “production-ready QUIC implementation in pure Go”, quic-go provided essential QUIC and HTTP/3 support for various projects, including the Caddy web server.

quic-go implements the core QUIC protocol (RFC 9000, RFC 9001, RFC 9002) and HTTP/3 (RFC 9114), including QPACK (RFC 9204) and HTTP Datagrams (RFC 9297). It also supports several other RFCs and drafts, such as Unreliable Datagram Extension (RFC 9221), DPLPMTUD (RFC 8899), QUIC Version 2 (RFC 9369), QUIC Event Logging using qlog, and QUIC Stream Resets with Partial Delivery. WebTransport over HTTP/3 is available via webtransport-go.

Developers can configure an HTTP/3 transport using quic-go and then utilize it with a regular http.Client to make HTTP/3 requests. An example of this setup is available in the quic-go repository. However, it’s noted that the quic-go client is specifically for QUIC transport and does not automatically fall back to HTTP/2 or HTTP/1 servers.

An example of setting up an http.Client with a quic-go transport:

// This is a conceptual example based on source.
// The actual implementation would involve importing quic-go/http3 and configuring a client.
import (
    "net/http"
    "github.com/quic-go/quic-go/http3" // This package provides the http3.RoundTripper
)

func main() {
    // Create an HTTP/3 client using quic-go's http3.RoundTripper
    client := &http.Client{
        Transport: &http3.RoundTripper{},
    }

    // Now this client can make HTTP/3 requests
    resp, err := client.Get("https://your-http3-server.com/")
    // ... handle response and error
}

HTTP/3 Overview

HTTP/3 stands as the third major version of the Hypertext Transfer Protocol, designed to enhance information exchange on the World Wide Web. Unlike its predecessors, HTTP/1.1 and HTTP/2, which relied on TCP, HTTP/3 utilizes QUIC, a multiplexed transport protocol built on UDP. Published as RFC 9114 in June 2022, HTTP/3 also leverages the completed QUIC protocol described in RFC 9000 and related RFCs.

While maintaining similar semantics—including the same request methods, status codes, and message fields—HTTP/3 fundamentally changes how these are encoded and how session state is maintained. Its adoption of QUIC provides significant benefits, leading to lower latency and faster loading times in real-world scenarios, sometimes more than four times faster than HTTP/1.1. This speed advantage is particularly noticeable on lossy or unpredictable network connections.

The protocol’s key innovation is its ability to resolve TCP’s head-of-line blocking. By offering native multiplexing, HTTP/3 ensures that a lost packet only affects the specific data stream it belongs to, rather than stalling all active transactions on a connection. Additionally, QUIC enables 0-RTT connection establishment, further reducing handshake latency for quicker interactions.

HTTP/3 has seen rapid adoption: as of September 2024, over 95% of major web browsers support it. Chromium-derived browsers (Google Chrome, Microsoft Edge, Opera, Samsung Internet) enabled it by default in April 2020, and Mozilla Firefox followed in May 2021. Safari 14 implemented the protocol in September 2020 and began supporting it for all users on Safari 16 or newer in September 2024. HTTP/3 is also used by 34% of the top 10 million websites.

HTTP/3 Implementations (Libraries & Servers)

The growing importance of HTTP/3 has led to its implementation across various libraries and web servers:

Libraries

C: lsquic (LiteSpeed), nghttp3, libcurl, MsQuic (Microsoft)
C++: proxygen (Facebook), Cronet (Google)
C#: .NET (using MsQuic)
Go: quic-go
Haskell: http3
Java: Kwik, Flupke
Python: aioquic
Rust: quiche (Cloudflare), neqo (Mozilla), quinn, s2n-quic (Amazon Web Services)

Servers

LiteSpeed Web Server: Version 6.0.2 (June 2021) was the first to enable HTTP/3 by default.
Caddy web server: Version 2.6.0 (September 2022) enabled HTTP/3 by default.
Nginx: Supports HTTP/3 since version 1.25.0 (May 2023), with a technology preview released in June 2020. Cloudflare also provides a patch for Nginx that integrates its quiche HTTP/3 library.
Microsoft IIS: Supports HTTP/3 natively with Windows Server 2022 and Windows 11.
HAProxy: Supports HTTP/3 over QUIC since version 2.6 (May 2022).
Nimble Streamer: Supports HTTP/3 for HTTP-based protocols since version 4.1.8-1 (February 2025).

References

Excerpts from “A production-ready QUIC implementation in pure Go - GitHub” - https://github.com/quic-go/quic-go
Excerpts from “Go官方HTTP/3 实现终迎曙光：x/net/http3 提案启动，QUIC 基础已就位 - Tony Bai” - https://tonybai.com/2025/08/02/proposal-http3
Excerpts from “HTTP/3 - Wikipedia” - https://en.wikipedia.org/wiki/HTTP/3
Excerpts from “How can I make an http3 request from golang? - Reddit” - https://www.reddit.com/r/golang/comments/1359c2b/how_can_i_make_an_http3_request_from_golang/

Recent Articles:

Random Article:

How to Make Your Go Code Truly Discoverable on Medium on Website

More Series Articles about You Should Know In Golang:

https://wesley-wei.medium.com/list/you-should-know-in-golang-e9491363cd9a

And I’m Wesley, delighted to share knowledge from the world of programming.

Don’t forget to follow me for more informative content, or feel free to share this with others who may also find it beneficial. It would be a great help to me.

Give me some free applauds, highlights, or replies, and I’ll pay attention to those reactions, which will determine whether I continue to post this type of article.

See you in the next article. 👋

中文文章: https://programmerscareer.com/zh-cn/golang-quic-start/
Author: Medium,LinkedIn,Twitter
Note: Originally written at https://programmerscareer.com/golang-quic-start/ at 2025-09-07 16:06.
Copyright: BY-NC-ND 3.0

#code