Linux 内核提供了多种进程间通信机制，但传统方案在功能完整性和性能上往往难以兼得。2026 年初，社区同时推进了三个方向的 IPC 增强：POSIX 消息队列的非消费读取（peek）、io_uring 原生 IPC 支持，以及 bus1 的 Rust 重实现。这三项工作代表了内核 IPC 演进的不同路径，其设计思路既相互独立又存在协同可能。
POSIX 消息队列的 Peek 机制
POSIX 消息队列（mq_*系列）长期缺少一个关键能力：查看队列中消息而不将其移除。传统mq_timedreceive()调用会永久删除队首消息，这对于监控工具和 CRIU（Checkpoint/Restore in Userspace）等场景构成障碍。Mathura Kumar 提出的mq_timedreceive2()系统调用填补了这一空白。
新系统调用将参数封装为结构体以突破架构限制：
struct mq_timedreceive2_args {
size_t msg_len;
unsigned int *msg_prio;
char *msg_ptr;
};
ssize_t mq_timedreceive2(mqd_t mqdes,
struct mq_timedreceive2_args *uargs,
unsigned int flags,
unsigned long index,
const struct timespec *abs_timeout);
核心在于flags参数中的MQ_PEEK标志。当设置此标志时，内核返回最高优先级消息但不移除队列内容，index参数可进一步指定读取队列中第 N 条消息（0 为队首）。这对需要检查队列状态但不干扰正常消费的场景至关重要，例如运行时日志分析或进程状态检查点。
实现层面，内核在mq_timedreceive2()中增加条件分支：当检测到MQ_PEEK时，复制消息内容后跳过队列删除逻辑。性能开销约为普通接收的 1.02 倍，几乎可忽略。但需注意，peek 操作仍会持有队列锁，高并发场景下应评估锁竞争。
io_uring 的 IPC 子系统的设计
与消息队列的渐进式增强不同，io_uring 直接引入全新的 IPC 范式。Daniel Hodges 的补丁系列试图在 io_uring 框架内构建高带宽进程通信机制，定位为 D-Bus 的潜在替代方案。
io_uring IPC 的核心设计基于共享环缓冲区（shared ring buffers）。与传统的 socket 数据拷贝不同，发送方将数据写入共享内存区域，接收方通过映射同一区域直接访问，省去内核参与的数据复制环节。架构包含以下关键操作：
通道建立：进程通过IORING_REGISTER_IPC_CHANNEL_CREATE创建通道，其他进程在权限允许下 attach。通道本质上是共享内存池的引用。
消息传递：IORING_OP_IPC_SEND和IORING_OP_IPC_RECV对应发送接收，但数据路径不经过内核缓冲区。发送时，io_uring 将数据描述符写入共享环，接收方轮询环尾指针获取数据位置。
广播支持：设计支持一对多消息分发，适用于事件分发场景。
该方案面临与当年 kdbus 相似的挑战：完整的功能集（凭证管理、权限控制、生命周期管理）需要大量工程投入。io_uring 维护者 Jens Axboe 认可方向但指出代码尚需完善，特别是 LLM 生成的测试用例需要人工审核。
bus1 的 Rust 重生
2016 年 David Herrmann 提出的 bus1 曾试图提供类 D-Bus 的内核中介 IPC，但未能进入主线。十年后，bus1 以 Rust 实现回归，由 David Rheinsberg 重新提交。
新版 bus1 的核心设计保持不变：基于能力（capability）的访问控制，消息和文件描述符均可传递。关键变化在于实现语言从 C 转向 Rust：
我们剥离了所有功能至最小集，用 Rust 重写了模块。不再担心引用计数和对象生命周期，但 C 与 Rust 的桥接带来了新挑战。
bus1 的零拷贝机制通过 per-peer 内存池实现。发送方将消息放入接收方的内存池，接收方以只读方式映射该池，绕过数据复制。消息协议包含 per-message slice 机制和接收方完成后的回收信号。
Rust 版本的优势在于内存安全 —— 消息对象生命周期由借用检查器管理，避免 use-after-free 等内核高危漏洞。但内核 Rust 生态尚处早期，与现有 C 代码的互操作性是主要工程挑战。
三种 IPC 机制的协同路径
这三项技术并非互斥，而是对应不同场景层级。实际系统设计中可形成互补：
监控与调试层：POSIX 消息队列的 peek API 适合构建非侵入式监控。CRIU 可利用mq_timedreceive2()在进程冻结前导出队列状态，复苏时按序回填。这种模式不需要零拷贝 —— 监控频率通常较低。
高性能数据层：io_uring IPC 和 bus1 面向高频交易、实时音视频等低延迟场景。两者都采用共享内存模型，但 io_uring 优势在于与现有异步 I/O 框架的无缝集成，bus1 则提供更完整的抽象层（能力、句柄传递）。
混合架构示例：考虑一个金融风控系统 —— 主进程通过 bus1 接收市场数据（低延迟要求），将风控信号写入 POSIX 消息队列（便于审计 peek），风控应用通过 io_uring 将高频信号推送至下游（极限吞吐）。这种分层设计利用各技术所长。
落地参数与监控要点
若计划在生产环境采用这些机制，以下参数值得参考：
POSIX 队列 peek：消息队列默认上限由/proc/sys/kernel/msgmnb（最大队列字节数）和/proc/sys/kernel/msgmni（队列数量）控制。peek 操作本身无特殊配置，但建议监控队列深度突变 —— 可能指示消费端积压。
io_uring IPC：共享内存池大小直接影响性能。过大浪费内存，过小导致频繁 ring 重置。初期可按单条消息最大体积 ×1024 设置，观察ioring_setup返回的user_flags中的缓冲区使用率调整。
bus1：目前仍在积极开发，生产环境需关注其与内核版本的兼容性。建议从边缘业务切入，建立性能基线后再迁移核心业务。
综合来看，内核 IPC 正在经历从 “功能完备” 到 “场景细分” 的演进。开发者应根据延迟阈值、吞吐量需求和运维复杂度选择合适层级，而非追求单一完美方案。
参考资料
- LWN.net: 《IPC medley: message-queue peeking, io_uring, and bus1》（https://lwn.net/Articles/1065490/）
- Linux 内核源码：
ipc/msg.c、include/uapi/linux/msg.h