尬住了，Go HTTP/3 又又被擱置了！
2024 年，Go 核心團(tuán)隊(duì)成員 @neild 提交了一個(gè)新提案 #70914[1]，打算在 x/net/http3 中添加 HTTP/3 的實(shí)驗(yàn)性實(shí)現(xiàn)。
圖片
本以為這次也算是正式啟動(dòng)了。能有些苗頭。結(jié)果萬萬沒想到，這個(gè)提案能又被半路擱置了！
圖片
要知道，這已經(jīng)不是 Go HTTP/3 第一次 "跳票" 了。
背景：多年的苦等
說起來挺無奈的，Go 社區(qū)對(duì) HTTP/3 的呼聲由來已久。早在 2019 年 5 月，社區(qū)就開了 Issue #32204[2] 來追蹤 HTTP/3 在標(biāo)準(zhǔn)庫(kù)中的實(shí)現(xiàn)進(jìn)度。那時(shí)候 HTTP/3 還只是 IETF 的草案，大家也能理解官方的謹(jǐn)慎態(tài)度。
圖片
但是現(xiàn)在都 2025 年了！HTTP/3 早在 2022 年 6 月就被 IETF 正式發(fā)布為提議標(biāo)準(zhǔn)(RFC 9114)了，主流瀏覽器的支持率已經(jīng)超過 95%，全球前 1000 萬網(wǎng)站中也有 34%支持了 HTTP/3。
圖片
簡(jiǎn)單來說，HTTP/3 已經(jīng)不是什么"新鮮玩意兒"了，它是實(shí)打?qū)嵉纳a(chǎn)級(jí)協(xié)議。可 Go 官方在標(biāo)準(zhǔn)庫(kù)層面，依然沒有動(dòng)靜。
提案內(nèi)容：看似穩(wěn)妥的方案
我們來看看 @neild 這次提出的方案到底是什么。
這個(gè)提案的思路其實(shí)挺保守的，和之前被接受的 QUIC 提案 #58547[3] 基本一致：
- 先在 x/net/internal/http3 中實(shí)驗(yàn)性開發(fā)
- 等 API 穩(wěn)定后，再移到 x/net/http3 供外部測(cè)試
- 最后提交正式的 API 審查提案
這個(gè)策略看起來很穩(wěn)妥對(duì)吧？先內(nèi)部折騰，等成熟了再放出來。照理說應(yīng)該問題不大。
但是很無奈的是，就是這么個(gè)穩(wěn)妥的方案，也被擱置了！也是絕了。
社區(qū)討論：無奈與不解
在 Issue #32204 的討論中，我們能看到社區(qū)對(duì)這個(gè)問題的長(zhǎng)期關(guān)注。
主要包含以下幾種態(tài)度/想法：
1、時(shí)間線： 2020 年，Brad Fitzpatrick 就在評(píng)論中提到過，Go 團(tuán)隊(duì)在觀望 HTTP/3 的成熟度。現(xiàn)在 5 年過去了，HTTP/3 早就從草案變成了正式標(biāo)準(zhǔn)，主流語(yǔ)言和框架也都有了成熟實(shí)現(xiàn)。
2、生態(tài)問題： 目前想在 Go 中使用 HTTP/3，只能依賴第三方庫(kù) quic-go[4]。這個(gè)庫(kù)做得確實(shí)不錯(cuò)，實(shí)現(xiàn)了完整的 QUIC 和 HTTP/3 支持：
package main
import (
"github.com/quic-go/quic-go/http3"
"log"
"net/http"
)
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
w.Write([]byte("Hello, HTTP/3!"))
})
// 啟動(dòng) HTTP/3 服務(wù)器
log.Fatal(http3.ListenAndServeQUIC(
"0.0.0.0:8443",
"/path/to/cert.pem",
"/path/to/key.pem",
mux,
))
}但問題在于:
- 第三方庫(kù)的維護(hù)周期和 Go 官方不一致
- 沒有標(biāo)準(zhǔn)庫(kù)的背書，企業(yè)級(jí)項(xiàng)目用起來總是有顧慮
- API 設(shè)計(jì)上無法和 net/http 無縫集成
3、多語(yǔ)言對(duì)比：隔壁 Rust、C++、Java、C# 等語(yǔ)言，人家早就把 HTTP/3 支持做進(jìn)標(biāo)準(zhǔn)庫(kù)或官方庫(kù)了。Go 作為云原生時(shí)代的代表語(yǔ)言，在網(wǎng)絡(luò)協(xié)議支持上反而顯得保守，這確實(shí)讓人有點(diǎn)心里不平衡。
為什么又又被擱置？
那問題來了，為什么一個(gè)看起來如此合理的提案，會(huì)被擱置呢？
根據(jù) Go 團(tuán)隊(duì)的處理風(fēng)格，我推測(cè)可能有這么幾個(gè)原因：
1. API 設(shè)計(jì)的復(fù)雜性
HTTP/3 基于 QUIC 協(xié)議，和傳統(tǒng)的 TCP 有本質(zhì)區(qū)別。要讓它和現(xiàn)有的 net/http 優(yōu)雅地集成，不是簡(jiǎn)單加幾個(gè)接口就能搞定的。
舉個(gè)例子，HTTP/3 的連接是基于 UDP 的，這意味著：
- TLS 握手方式不同(使用 QUIC 的 TLS 1.3)
- 連接遷移特性需要特殊處理
- 流控機(jī)制完全不同
這些都需要在 API 設(shè)計(jì)上仔細(xì)考慮。
2. 向后兼容的壓力
Go 一直以向后兼容聞名，這是好事，但也帶來了設(shè)計(jì)上的約束。HTTP/3 的 API 怎么設(shè)計(jì)，既要考慮現(xiàn)有 net/http 用戶的習(xí)慣，又要支持 HTTP/3 的新特性，這是個(gè)難題。
看看在 Go1.24 加入的 HTTP 版本選擇 API te'xing #67814[5] 就知道了：
type Protocol uint64
const (
HTTP1 Protocol = (1 << iota)
HTTP2
// HTTP3 還沒有...
)
// Server 可以選擇支持的協(xié)議
s := &http.Server{}
s.Protocols = HTTP1 | HTTP2
// Transport 也可以選擇
tr := &http.Transport{}
tr.Protocols = HTTP1 | HTTP2這個(gè) API 預(yù)留了擴(kuò)展空間，但 HTTP3 的位置還是空著的。為什么？因?yàn)楣俜竭€沒想好怎么搞！
3. 資源分配問題
Go 核心團(tuán)隊(duì)人手有限，他們現(xiàn)在的重點(diǎn)在：
- 把 x/net/http2 移到標(biāo)準(zhǔn)庫(kù) #67810[6]。預(yù)計(jì)在 Go1.26 版本支持。
- 支持明文 HTTP/2 #67816[7]。這個(gè)特性在 Go1.24 版本支持了。
- 完善 HTTP/2 的一系列雜七雜八的問題。
說白了，HTTP/2 都還沒徹底搞定，甚至都還沒有進(jìn)入標(biāo)準(zhǔn)庫(kù)（尷尬了），可能他們認(rèn)為哪有精力去搞 HTTP/3？
4. 實(shí)用主義的考量
有個(gè)不得不承認(rèn)的事實(shí)：雖然 HTTP/3 很先進(jìn)，但在實(shí)際生產(chǎn)環(huán)境中，HTTP/2 已經(jīng)夠用了。大多數(shù)場(chǎng)景下，HTTP/3 帶來的性能提升并不是質(zhì)的飛躍。
所以從實(shí)用主義角度看，Go 團(tuán)隊(duì)可能覺得 HTTP/3 不是當(dāng)務(wù)之急。資源就沒有分配在這里。
總結(jié)
Go HTTP/3 的推進(jìn)，可以說是 "起了個(gè)大早，趕了個(gè)晚集"。2019 年就有人提議，2025 年提案又被擱置，這個(gè)過程確實(shí)有點(diǎn)魔幻。
但換個(gè)角度想，這也是 Go 一貫的風(fēng)格：穩(wěn)字當(dāng)頭，又或是 ”less is more“。至于什么時(shí)候能在標(biāo)準(zhǔn)庫(kù)中用上 HTTP/3，就看 Go 核心團(tuán)隊(duì)的魄力和資源分配了。
在那之前，可以先繼續(xù)使用 quic-go。
參考資料
[1] #70914: https://github.com/golang/go/issues/70914
[2] Issue #32204: https://github.com/golang/go/issues/32204
[3] #58547: https://github.com/golang/go/issues/58547
[4] quic-go: https://github.com/quic-go/quic-go
[5] #67814: https://github.com/golang/go/issues/67814
[6] #67810: https://github.com/golang/go/issues/67810
[7] #67816: https://github.com/golang/go/issues/67816
