标签 Kernel 下的文章

为何Go语言迟迟未能拥抱 io_uring?揭秘集成的三大核心困境

本文永久链接 – https://tonybai.com/2025/08/11/why-go-not-embrace-iouring

大家好,我是Tony Bai。

在 Linux I/O 的世界里,io_uring 如同划破夜空的流星,被誉为“终极接口”。它承诺以无与伦比的效率,为数据密集型应用带来革命性的性能提升。正如高性能数据库 ScyllaDB 在其官方博文中所展示的,io_uring 能够将系统性能推向新的高峰。

然而,一个令人费解的问题摆在了所有 Go 开发者面前:作为云原生infra和并发编程的标杆,Go 语言为何对这颗唾手可得的“性能银弹”表现得如此审慎,甚至迟迟未能将其拥抱入标准库的怀抱?一场在 Go 官方仓库持续了五年之久的 Issue 讨论(#31908),为我们揭开了这层神秘的面纱。这并非简单的技术取舍,而是 Go 在其设计哲学、工程现实与安全红线之间进行反复权衡的结果。本文将深入这场讨论,为您揭秘阻碍 io_uring 在 Go 中落地的三大核心困境。

io_uring:一场 I/O 模型的革命

要理解这场争论,我们首先需要明白 io_uring 究竟是什么,以及它为何具有革命性。

在 io_uring 出现之前,Linux 上最高效的 I/O 模型是 epoll。epoll 采用的是一种“拉(pull)”模型:应用程序通过一次 epoll_wait 系统调用来询问内核:“有我关心的文件描述符准备好进行 I/O 了吗?”。内核响应后,应用程序需要再为每个就绪的描述符分别发起 read 或 write 系统调用。这意味着,处理 N 个 I/O 事件至少需要 N+1 次系统调用

而 io_uring 则彻底改变了游戏规则。它在内核与用户空间之间建立了两个共享内存环形缓冲区:提交队列(Submission Queue, SQ)完成队列(Completion Queue, CQ)

其工作流程如下:

  1. 提交请求: 应用程序将一个或多个 I/O 请求(如读、写、连接等)作为条目(SQE)放入提交队列中。这仅仅是内存操作,几乎没有开销
  2. 通知内核: 应用通过一次 io_uring_enter 系统调用,通知内核“请处理队列中的所有请求”。在特定模式(SQPOLL)下,这个系统调用甚至可以被省略。
  3. 内核处理: 内核从提交队列中批量取走所有请求,并异步地执行它们。
  4. 返回结果: 内核将每个操作的结果作为一个条目(CQE)放入完成队列。这同样只是内存操作。
  5. 应用收获: 应用程序直接从完成队列中读取结果,无需为每个结果都发起一次系统调用。

这种模式的优势是颠覆性的:它将 N+1 次系统调用压缩为 1 次甚至 0 次,极大地降低了上下文切换的开销,并且首次为 Linux 带来了真正意义上的、无需 O_DIRECT 标志的异步文件 I/O

最初的希望:一剂治愈 Go I/O“顽疾”的良药

讨论伊始,Go 社区对 io_uring 寄予厚望,期待它能一举解决 Go 在 I/O 领域的两大历史痛点:

  1. 真正的异步文件 I/O: Go 的网络 I/O 基于 epoll 实现了非阻塞,但文件 I/O 本质上是阻塞的。为了避免阻塞系统线程,Go 运行时不得不维护一个线程池来处理文件操作。正如社区所期待的,io_uring 最大的吸引力在于“移除对文件 I/O 线程池的需求”,让文件 I/O 也能享受与网络 I/O 同等的高效与优雅。
  2. 极致的网络性能: 对于高并发服务器,io_uring 通过将多个 read/write 操作打包成一次系统调用,能显著降低内核态与用户态切换的开销,这在“熔断”和“幽灵”漏洞导致 syscall 成本飙升的后时代尤为重要。

然而,Go 核心团队很快就为这股热情泼上了一盆“冷水”。

核心困境一:运行时模型的“哲学冲突”

这是阻碍 io_uring 集成最根本、最核心的障碍。Go 的成功很大程度上归功于其简洁的并发模型——goroutine,以及对开发者完全透明的调度机制。但 io_uring 的工作模式,与 Go 运行时的核心哲学存在着深刻的冲突。

冲突的焦点在于“透明性”。Ian Lance Taylor 多次强调,问题不在于 io_uring 能否在 Go 中使用,而在于能否“透明地”将其融入现有的 os 和 net 包,而不破坏 Go 开发者早已习惯的 API 和心智模型。

io_uring 的性能优势源于批处理。但 Go 的标准库 API,如 net.Conn.Read(),是一个独立的、阻塞式的调用。Go 用户习惯于在独立的 goroutine 中处理独立的连接。如何将这些分散的独立 I/O 请求,在用户无感知的情况下,“透明地”收集起来,打包成批?这几乎是一个无解的难题。

社区也提出了“每个 P (Processor) 一个 io_uring 环”的设想,但 Ian 指出这会引入极高的复杂性,包括环的争用、空闲 P 的等待与唤醒、P 与 M 切换时的状态管理等。正如一些社区成员所总结的,io_uring 需要一种全新的 I/O 模式,而这与 Go 现有网络模型的模式完全不同。强行“透明”集成,无异于“在不破坏现有 API 的情况下进行不必要的破坏”。

核心困境二:现实世界的“安全红线”

如果说运行时模型的冲突是理论上的“天堑”,那么安全问题则是实践中不可逾越的“红线”。

在 2024 年初,社区成员 jakebailey 抛出了一个重磅消息:出于安全考虑,Docker 默认的 seccomp 配置文件已经禁用了 io_uring

引用自 Docker 的 commit 信息: “安全专家普遍认为 io_uring 是不安全的。事实上,Google ChromeOS 和 Android 已经关闭了它,所有 Google 生产服务器也关闭了它。”

这个消息对标准库集成而言几乎是致命一击。Go 程序最常见的部署环境就是容器。一个不被“普遍情况”支持的特性,无论其性能多么优越,都难以成为Go运行时和标准库的基石。

核心困境三:追赶一个“移动的目标”

在这场长达五年的讨论中,io_uring 自身也在飞速进化。其作者Jens Axboe 甚至亲自下场,解答了 Go 团队早期的疑虑,例如移除了并发数限制、解决了事件丢失问题等。

但这恰恰揭示了第三重困境:要集成一个仍在高速演进、API 不断变化的底层接口,本身就充满了风险和不确定性。标准库追求的是极致的稳定性和向后兼容性。过早地依赖一个“移动的目标”,可能会带来持续的维护负担和潜在的破坏性变更。对于一个需要支持多个内核版本的语言运行时来说,这种复杂性是难以承受的。

小结:审慎的巨人与退潮的社区热情

io_uring 未能在 Go中落地,并非因为 Go 团队忽视性能,而是其成熟与审慎的体现。三大核心困境层层递进,揭示了其迟迟未能拥抱 io_uring 的深层原因:哲学上的范式冲突、现实中的安全红线、以及工程上的稳定性质疑。

然而,现实比理论更加残酷。在讨论初期,Go 社区曾涌现出一批充满激情的用户层 io_uring 库,如 giouring、go-uring 等,它们是开发者们探索新大陆的先锋。但时至 2025 年,我们观察到一个令人沮丧的趋势:这些曾经的追星项目大多已陷入沉寂,更新寥寥,星光黯淡。

与之形成鲜明对比的是,Rust 的 tokio-uring 库依然保持着旺盛的生命力,社区活跃,迭代频繁。这似乎在暗示,问题不仅在于 io_uring 本身,更在于它与特定语言运行时模型的“契合度”。Go 运行时的 G-P-M 调度模型和它所倡导的编程范式,使得社区自发的集成尝试也步履维艰,最终热情退潮。

这是否意味着 Go 与 io_uring 将永远无缘?或许未来之路有二:一是等待 io_uring 自身和其生态环境(尤其是安全方面)完全成熟;二是 Go 也许可能会引入一套全新的、非透明的、专为高性能 I/O 设计的新标准库包。

在此之前,Go 运行时可能会选择先挖掘 epoll 的全部潜力。这场长达五年的讨论,最终为我们留下了一个深刻的启示:技术的采纳从来不是一场单纯的性能赛跑,它是一场包含了设计哲学、生态现实与工程智慧的复杂博弈。

资料链接:

  • https://github.com/golang/go/issues/31908
  • https://www.scylladb.com/2020/05/05/how-io_uring-and-ebpf-will-revolutionize-programming-in-linux/

关注io_uring在Linux kernel内核演进的小伙伴儿们,可以关注io-uring.vger.kernel.org archive mirror这个页面,或io_uring作者Jens Axboe的liburing wiki


你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?

  • 想写出更地道、更健壮的Go代码,却总在细节上踩坑?
  • 渴望提升软件设计能力,驾驭复杂Go项目却缺乏章法?
  • 想打造生产级的Go服务,却在工程化实践中屡屡受挫?

继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。

目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!


商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求,请扫描下方公众号二维码,与我私信联系。

Go官方 HTTP/3 实现终迎曙光:x/net/http3 提案启动,QUIC 基础已就位

本文永久链接 – https://tonybai.com/2025/08/02/proposal-http3

大家好,我是Tony Bai。

在社区长达数年的热切期盼之后,Go 官方终于迈出了支持 HTTP/3 的关键一步。一项编号为#70914的新提案,正式建议在 x/net/http3 中添加一个实验性的 HTTP/3 实现。这一进展建立在另一项更基础的提案 #58547(x/net/quic) 之上,该提案的实现已取得重大进展,并已从内部包移至公开的 x/net/quic。这意味着 Go 的网络栈即将迎来一次基于 UDP 的、彻底的现代化升级。本文将带您回顾 Go 社区对 HTTP/3 的漫长期待,深入解读官方 QUIC 和 HTTP/3 的实现策略,并探讨其对未来 Go 网络编程的深远影响。

一场长达五年的等待

对 HTTP/3 的支持,可以说是 Go 社区近年来呼声最高的功能之一。早在 2019 年,issue #32204 就被创建,用于追踪在标准库中支持 HTTP/3 的进展。在随后的五年里,随着 Chrome、Firefox 等主流浏览器以及 Cloudflare 等基础设施提供商纷纷拥抱 HTTP/3,社区的期待也日益高涨。

在此期间,由 Marten Seemann 维护的第三方库 quic-go 成为了 Go 生态中事实上的标准,为 Caddy 等项目提供了生产级的 QUIC 和 HTTP/3 支持。然而,许多开发者仍然期盼一个“电池内置”的官方解决方案,以保证与 Go 标准库(特别是 net/http 和 crypto/tls)的最佳集成和长期维护。

Go 团队对此一直持谨慎态度,主要原因在于:

  1. 协议稳定性:在 QUIC 和 HTTP/3 的 IETF 标准(RFC 9000 和 RFC 9114)正式发布前,过早投入实现可能会面临巨大的变更成本。
  2. API 设计复杂性:QUIC 协议引入了连接、流、0-RTT 等新概念,其 API 设计需要与现有的 net.Conn 和 net.Listener 体系进行权衡,这是一个巨大的挑战。
  3. 实现难度巨大:一个高性能、安全的 QUIC 协议栈,涉及复杂的流量控制、拥塞控制、丢包恢复等机制,其实现工作量远超 HTTP/2。

两步走战略:先 QUIC,后 HTTP/3

现在,随着协议的标准化和 crypto/tls 中 QUIC 支持的落地,Go 团队终于启动了官方的实现计划,并采取了清晰的“两步走”战略。

第一步:构建 QUIC 基础 (x/net/quic)

提案 #58547 旨在 golang.org/x/net/quic 中提供一个 QUIC 协议的实现。这是支持 HTTP/3 的必要前提。经过一段时间的开发,该包的实现已取得重大进展。

Go 团队的核心成员 neild 最近宣布,该 QUIC 实现已从内部包 (internal/quic) 移至公开的 x/net/quic,虽然仍处于实验阶段且 API 可能变化,但这标志着它已足够成熟,可以供社区“尝鲜”和提供反馈。

x/net/quic 的核心 API 概念:

  • Endpoint (原 Listener): 在一个网络地址上监听 QUIC 流量。
  • Conn: 代表一个客户端和服务器之间的 QUIC 连接,可以承载多个流。
  • Stream: 一个有序、可靠的字节流,类似于一个 TCP 连接。
// 客户端发起连接
conn, err := quic.Dial(ctx, "udp", "127.0.0.1:8000", &quic.Config{})

// 服务器接受连接
endpoint, err := quic.Listen("udp", "127.0.0.1:8000", &quic.Config{})
conn, err := endpoint.Accept(ctx)

// 在连接上创建和接受流
stream, err := conn.NewStream(ctx)
stream, err := conn.AcceptStream(ctx)

// 对流进行读写操作
n, err = stream.Read(buf)
n, err = stream.Write(buf)
stream.Close()

值得注意的是,官方实现并未直接采用 quic-go 的代码,rsc 在讨论中解释了原因,包括 API 设计理念的差异、代码风格、测试框架依赖以及从零开始实现可能更易于维护等。

第二步:实现 HTTP/3 (x/net/http3)

在 x/net/quic 的基础上,提案 #70914 正式启动了 x/net/http3 的开发。与 QUIC 一样,它将首先在内部包 (x/net/internal/http3) 中进行开发,待 API 稳定后再移至公开包,并提交最终的 API 审查提案。

从 gopherbot 自动发布的 CL(代码变更)列表中,我们可以看到 HTTP/3 的实现正在紧锣密鼓地进行中,涵盖了 QPACK(HTTP/3 的头部压缩算法)、Transport、Server、请求/响应体传输等核心组件。

对 Go 网络编程的深远影响

官方 QUIC 和 HTTP/3 的到来,将为 Go 开发者带来革命性的变化:

  1. 透明的协议升级:可以预见,未来的 net/http 包将能够像当年无缝支持 HTTP/2 一样,透明地支持 HTTP/3。开发者可能无需修改现有代码,http.Get(“https://example.com/”) 就可能自动通过 UDP 下的 QUIC 协议执行,正如 ianlancetaylor 在讨论中确认的那样。

  2. 解决队头阻塞 (Head-of-Line Blocking):HTTP/3 最大的优势之一是解决了 TCP 队头阻塞问题。对于需要处理大量并发请求的 Go 微服务,这意味着更低的延迟和更高的吞吐量,尤其是在网络不稳定的情况下。

  3. 更快的连接建立:QUIC 支持 0-RTT 连接建立,对于需要频繁建立新连接的应用场景,可以显著降低握手延迟。

  4. 原生多路复用传输层:QUIC 本身就是一个多路复用的传输协议。虽然提案的初期重点是支持 HTTP/3,但一个标准化的 QUIC API 将为 gRPC over QUIC、WebTransport 以及其他需要多流、低延迟通信的自定义协议打开大门。

终极形态——当 QUIC 走进 Linux 内核

尽管 x/net/quic 的开发标志着 Go 官方在用户空间迈出了重要一步,但关于 QUIC 协议的终极愿景,则指向了更深的层次:Linux 内核原生支持。最近,由 Xin Long 提交的一系列补丁,首次将内核态 QUIC 的实现提上了 mainline 的议程

为什么要将 QUIC 移入内核?

将 QUIC 从用户空间库(如 x/net/quic 或 quic-go)下沉到内核,主要有以下几个核心动机:

  1. 极致的性能潜力:内核实现能够充分利用现代网络硬件的协议卸载(protocol offload)能力,例如 GSO/GRO (Generic Segmentation/Receive Offload)。这将极大地降低 CPU 在处理大量小型 UDP 包时的开销,释放出用户空间实现难以企及的性能潜力。
  2. 更广泛的可用性:一旦 QUIC 成为内核支持的协议(如 IPPROTO_QUIC),任何应用程序都可以像使用 TCP 或 UDP 一样,通过标准的 socket() 系统调用来使用它,而无需绑定到任何特定的用户空间库。
  3. 统一的生态系统:内核级别的支持将极大地促进生态系统的发展。Samba、NFS 甚至 curl 等项目已经表现出对内核态 QUIC 的浓厚兴趣。对于 Go 开发者而言,这意味着未来不仅是 net/http,甚至标准库的其他部分或底层系统调用,都可能从 QUIC 中受益。

当前的实现与挑战

Xin Long 的补丁集展示了一个高度集成化的设计:

  • 熟悉的 Sockets API:开发者将能够使用 socket(AF_INET, SOCK_STREAM, IPPROTO_QUIC) 这样的调用来创建一个 QUIC 套接字,并继续使用 bind(), connect(), listen(), accept() 等熟悉的 API。
  • 用户空间 TLS 握手:与内核 TLS (KTLS) 的设计类似,复杂的 TLS 握手和证书验证逻辑仍然被委托给用户空间处理。一旦握手完成,内核将接管加密和解密的数据流。
  • 性能仍在优化:初步的基准测试显示,当前的内核实现性能尚不及 KTLS 甚至原生 TCP。这主要是由于缺少硬件卸载支持、额外的内存拷贝以及 QUIC 头部加密的开销。但随着实现的成熟和硬件厂商的跟进,这一差距有望迅速缩小。

不过,预计内核态 QUIC 的合入可能要到 2026 年甚至更晚。

小结:Go 网络生态的下一座里程碑

尽管距离在 Go 标准库中稳定地使用 http.Server{…}.ListenAndServeQUIC() 可能还有一段时间,但 x/net/quic 的公开和 x/net/http3 提案的启动,标志着 Go 官方已经吹响了向下一代网络协议进军的号角。

对于 Go 社区而言,这是一个令人振奋的信号。它不仅回应了开发者们长久以来的期待,也确保了 Go 在未来依然是构建高性能、现代化网络服务的首选语言。我们期待着 x/net/http3 的成熟,并最终看到它被无缝地集成到 net/http 标准库中,为所有 Go 开发者带来更快、更可靠的网络体验。

参考资料

  • https://github.com/golang/go/issues/70914
  • https://github.com/golang/go/issues/58547
  • https://github.com/golang/go/issues/32204
  • https://lwn.net/Articles/1029851/

你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?

  • 想写出更地道、更健壮的Go代码,却总在细节上踩坑?
  • 渴望提升软件设计能力,驾驭复杂Go项目却缺乏章法?
  • 想打造生产级的Go服务,却在工程化实践中屡屡受挫?

继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。

目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!


商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求,请扫描下方公众号二维码,与我私信联系。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 Go语言精进之路1 Go语言精进之路2 Go语言第一课 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats