Go 要搞 HTTP/3 了！新提案正式啟動
Go 核心團隊又有新動作了。最近在 golang/go 倉庫里看到了一個新提案 #70914：在 x/net/http3 中添加實驗性的 HTTP/3 實現。
圖片
畢竟 HTTP/3 也出了有幾年了：
圖片
相對應的，HTTP/3 的支持呼聲在 Go 社區里已經高喊了好幾年了。
這事意義不小。
背景
其實 Go 對 HTTP/3 的討論由來已久。早在 2019 年就有 issue #32204 在討論 net/http 包支持 HTTP/3 的事情。
為什么現在才開始正式推進？我覺得可能有幾個原因：
- 第一：底層 QUIC 實現有了基礎。x/net/quic 包的提案已經通過，為 HTTP/3 提供了必要的底層支撐。
- 第二：HTTP/3 標準已經穩定。RFC 9114 早就發布了，各大廠商的支持也基本到位。
- 第三：社區需求確實強烈。現在云原生、邊緣計算這些場景下，HTTP/3 的性能優勢還是很明顯的。
新提案：experimental HTTP/3
這個提案的訴求很 “簡單”，目的就是：在 x/net/http3 包中添加 HTTP/3 的客戶端和服務器實現。
套路跟之前的 x/net/quic 提案（#58547）一模一樣：
- 想要先搞個實驗性的包。
- API 在開發過程中可以隨時調整。
- 等實現完整了再單獨提 API 審查提案。
開發計劃
提案里提到的開發路線還挺清晰：
- 階段一：在內部包
x/net/internal/http3里開發，等細節穩定了再說。 - 階段二：遷移到
x/net/http3，開放給外部測試。 - 階段三：API 穩定后，提交正式的 API 審查提案。
這種漸進式的策略還是很穩妥的。
因為 HTTP/3 涉及的東西太多了，一步到位確實存在一定的風險。
思考：可能的 HTTP/3 代碼例子
雖然具體的 API 還沒確定，但根據 Go 的一貫風格，估計使用起來會很簡潔。
現在用第三方庫 quic-go 寫 HTTP/3 服務器大概是這樣：
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 配置
},
}
server.ListenAndServe()
}等 Go 官方的實現出來，估計 API 會更符合 Go 的設計哲學。
我們暢想一下，未來可能會是這樣：
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!"))
})
// 估計會跟現有的 http 包整合得很好
server := &http3.Server{
Addr: ":8080",
Handler: mux,
}
server.ListenAndServe()
}客戶端的使用估計也會很簡潔：
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)
}當然，這些只是我的推測，具體的 API 設計還得等官方實現出來才知道。
個人看法
說實話，這個提案我還是很期待的。
Go 在網絡編程方面一直是強項，net/http 包也是 Go 生態里的經典之作。但在 HTTP/3 這塊確實有點落后，現在想用 HTTP/3 基本都得依賴第三方庫。
有了官方實現，相信未來在以下這幾個方面會有改善：
- 兼容性更好：官方實現肯定會跟現有的 net/http 包整合得更好。
- 維護更穩定：不用擔心第三方庫突然不維護了。
- 性能更優化：Go 核心團隊對運行時的優化能力還是很強的。
不過 HTTP/3 的復雜度確實不小，要做到生產級別的穩定性，估計還需要不少時間的迭代。
總結
這個提案雖然內容簡單，但釋放的信號很明確：Go 要認真搞 HTTP/3 了。
從提案的策略來看，Go 核心團隊還是很謹慎的，采用了漸進式的開發方式。
這種做法雖然保守，但對于基礎設施級別的功能來說，穩妥總比激進好。
接下來就看具體的開發進展了。希望能早日用上 Go 原生的 HTTP/3 支持，告別各種第三方庫的依賴。
