Source: Reprinted with permission from 脑子进煎鱼了 (ID: eddycjy)<br />Author: Chen JianyuThe Go core team has made new moves. Recently, a new proposal was seen in the golang/go repository: Add experimental HTTP/3 implementation in x/net/http3.
After all, HTTP/3 has been around for a few years now:
Correspondingly, the call for HTTP/3 support has been strong in the Go community for several years.
This is quite significant.
Background
In fact, discussions about HTTP/3 in Go have been ongoing for a long time. As early as 2019, issue #32204 was discussing <span>net/http</span> package support for HTTP/3.
Why is it only now that formal progress is being made? I think there are several reasons:
- First: The underlying QUIC implementation has a foundation. The proposal for the x/net/quic package has been approved, providing the necessary underlying support for HTTP/3.
- Second: The HTTP/3 standard has stabilized. RFC 9114 has been published, and major vendors’ support is basically in place.
- Third: The community demand is indeed strong. In scenarios like cloud-native and edge computing, the performance advantages of HTTP/3 are quite evident.
New Proposal: Experimental HTTP/3
The proposal’s request is quite “simple”, aiming to:Add HTTP/3 client and server implementations in the x/net/http3 package.
The approach is exactly the same as the previous <span>x/net/quic</span> proposal (#58547):
- First, create an experimental package.
- The API can be adjusted at any time during development.
- Once the implementation is complete, a separate API review proposal will be submitted.
Development Plan
The development roadmap mentioned in the proposal is quite clear:
- Phase One: Develop in the internal package
<span>x/net/internal/http3</span>, and discuss once the details are stable. - Phase Two: Migrate to
<span>x/net/http3</span>, open for external testing. - Phase Three: After the API stabilizes, submit a formal API review proposal.
This gradual strategy is quite prudent.
Because HTTP/3 involves a lot, going all in does carry certain risks.
Thoughts: Possible HTTP/3 Code Examples
Although the specific API has not been determined, based on Go’s consistent style, it is expected to be very straightforward to use.
Currently, writing an HTTP/3 server using the third-party library quic-go looks something like this:
package main
import (
"crypto/tls"
"net/http"
"github.com/quic-go/quic-go/http3"
)
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
w.Write([]byte("Hello HTTP/3!"))
})
server := &http3.Server{
Addr: ":8080",
Handler: mux,
TLSConfig: &tls.Config{
// TLS configuration
},
}
server.ListenAndServe()
}
Once the official implementation from Go is released, the API is expected to align better with Go’s design philosophy.
Let’s imagine what it might look like in the future:
package main
import (
"net/http"
"x/net/http3"
)
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
w.Write([]byte("Hello HTTP/3!"))
})
// It is expected to integrate well with the existing http package
server := &http3.Server{
Addr: ":8080",
Handler: mux,
}
server.ListenAndServe()
}
The client usage is also expected to be very straightforward:
package main
import (
"fmt"
"x/net/http3"
)
func main() {
client := &http3.Client{}
resp, err := client.Get("https://example.com")
if err != nil {
panic(err)
}
defer resp.Body.Close()
fmt.Println("Response:", resp.Status)
}
Of course, these are just my speculations; the specific API design will have to wait for the official implementation to be revealed.
Personal Opinion
To be honest, I am quite looking forward to this proposal.
Go has always been strong in network programming, and the net/http package is a classic in the Go ecosystem. However, it has indeed lagged behind in HTTP/3, and currently, using HTTP/3 basically relies on third-party libraries.
With an official implementation, I believe there will be improvements in the following areas:
- Better Compatibility: The official implementation will definitely integrate better with the existing net/http package.
- More Stable Maintenance: No need to worry about third-party libraries suddenly becoming unmaintained.
- Optimized Performance: The Go core team has strong capabilities in runtime optimization.
However, the complexity of HTTP/3 is indeed considerable, and achieving production-level stability will likely require significant iterations over time.
Conclusion
This proposal, while simple in content, sends a very clear signal:Go is serious about implementing HTTP/3.
From the proposal’s strategy, the Go core team is quite cautious, adopting a gradual development approach.
This conservative approach, while safe, is better than being aggressive for infrastructure-level features.
Next, we will see the specific development progress. I hope to soon use Go’s native HTTP/3 support and say goodbye to dependencies on various third-party libraries.
1. The company has released a benefit bomb, no need for approval for working from home, directly approved.
2. Interviewer: Is it better to write try-catch inside the loop or outside? Most people will answer incorrectly!
3. 10 scenarios where I use MQ in my work.
4. Interviewing at Tencent, holding on until the end!!
5. These 4 amazing GitHub open-source projects are too high quality.