1 简介

本文简要介绍 Homa 的背景与设计理念，再说明它的实现机制，最后总结它与现代主流 gRPC（基于 HTTP/2 + TCP/QUIC） 的优缺点对比。

Homa 协议概述与 gRPC 对比

TCP 和 UDP 诞生已有 50 年，虽然它们仍是大多数网络应用的基础，但并非所有场景都最优。特别是在数据中心内部，应用通常涉及 大量主机之间的短小 RPC（远程过程调用）消息，而 TCP 的连接建立、字节流排序和拥塞控制会带来较大开销。

为解决这一问题，John Ousterhout（Tcl/Tk 和 Raft 的作者）提出了 Homa 传输协议，它专门为 低延迟的 RPC 数据中心应用而设计。目前已有一个 Linux 内核最小实现原型。

2 Homa 协议设计特点

无连接开销

不需要三次握手，客户端直接发送请求。

每个请求携带唯一 ID，响应引用该 ID。

高效的消息传输机制

请求可直接发送一小部分“未调度数据”（~10KB），保证管道不中断。

如果请求较大，需等待服务器发回 grant 授权才能继续传输，类似于 TCP 接收窗口，但更灵活。

优先级队列与公平性

短小请求优先，以减少平均延迟。

剩余传输量越少的消息优先级越高，避免大消息“霸占”带宽。

简化状态管理

服务器处理完响应即可丢弃状态（最新版本支持显式确认，保证可靠性）。

丢包检测交由接收端完成，而非发送端。

实现接口（Linux 原型）

使用 socket(AF_INET, SOCK_DGRAM, IPPROTO_HOMA)。

发送端通过 sendmsg() 携带 Homa 特定参数（请求 ID、完成 cookie）。

接收端需事先注册缓冲区（bpages），通过 recvmsg() 接收响应。

3 与 gRPC 的对比

  特性	Homa	gRPC（基于 TCP/HTTP2/QUIC）
  设计目标	数据中心内的超低延迟 RPC	跨语言、跨平台的通用 RPC 框架
  传输协议	Homa（自定义内核协议）	TCP + HTTP/2（或 QUIC）
  连接管理	无连接，按请求 ID 区分	需要连接建立与维护（TCP/QUIC）
  延迟	极低，针对小型 RPC 优化	相对较高，因握手、流控、TLS、HTTP/2 帧开销
  流控机制	grant-based，短请求优先	TCP/QUIC 窗口控制，HTTP/2 流优先级
  状态管理	轻量级，响应后可清除	长连接，保持状态
  实现复杂度	需要内核支持，API 不够通用	用户态库即可使用，生态成熟
  生态与工具链	实验性，主要在研究与部分数据中心原型中	成熟：负载均衡、认证、可观测性等工具齐全
  适用场景	大规模数据中心内部 RPC，追求极致低延迟	云服务、跨数据中心、语言/平台互通 RPC

3 使用场景：

在 Homa 的早期论文中，其评估工作负载不少引用了来自谷歌、Facebook、Hadoop 相关的 数据中心 RPC 场景，但这些是用于研究与性能测评，并不一定意味着实际部署在生产环境。

Kernel upstreaming 的工作正在进行中，Homa transport protocol 已提交内核补丁系列，并有 Linux kernel 模块（HomaModule）在 GitHub。该项目持续维护，目标是 部署在 Linux 内核中。

gRPC 与 Homa 的集成研发也在进行中；当前有C++ 版本的 gRPC Homa 驱动正在开发中，并且 Java 支持还在初期阶段。这意味着某些服务或框架可能已经测试或准备在数据中心内部 RPC 场景切换到 Homa。

在 Netdev 会议（2023 年）有演讲题为 “Leveraging Homa: Enhancing Datacenter RPC Transport Protocols”，展示 在大规模数据中心 RPC 场景中测试 Homa vs TCP 的性能优势。这表明存在研究/原型层面的实际部署或演示。

4 小结

Homa 的优势

面向数据中心的低延迟优化，能显著降低 RPC 请求-响应时间。

无需连接建立，减少 CPU 与内核开销。

公平性与短消息优先机制，保证 tail latency。

Homa 的劣势

实现依赖内核修改，部署难度高。

生态缺失，缺乏 gRPC 那样的工具链和语言绑定。

主要适用于单一数据中心内部通信，不适合跨互联网的通用 RPC。

gRPC 的优势

成熟的生态和工具链，广泛支持。

支持跨语言、跨平台，具备安全、流控和可观测性功能。

适合云服务、微服务架构。

gRPC 的劣势

TCP/HTTP/2/QUIC 带来额外延迟和开销，难以做到像 Homa 那样的极致优化。