適用於 Rust 的零拷貝 Protobuf 與 ConnectRPC 實作

背景

Anthropic 的工程師 Iain McGinniss 近期開源了兩款 Rust 函式庫：buffa 與 connect-rust。buffa 是一個純 Rust 實現的 Protocol Buffers 工具，核心特色在於支援最新的 Editions 規範與零拷貝（Zero-copy）訊息視圖；connect-rust 則是基於 Tower 框架的 ConnectRPC 實現，能同時處理 Connect、gRPC 與 gRPC-Web 協議。這套工具已在 Anthropic 的生產環境中運行，旨在解決 Rust 生態系中 Protobuf 支援滯後以及 RPC 效能瓶頸的問題。

社群觀點

針對這項新工具的發布，Hacker News 社群展開了多層面的討論。首先是關於 Rust 標準函式庫（stdlib）範疇的爭議。有部分開發者認為像 HTTP 或序列化這類基礎工具應納入官方維護的「擴展標準庫」中，以減少專案初期挑選套件的負擔，並降低供應鏈攻擊的風險，特別是像 serde 或 syn 這種幾乎所有專案都會依賴的底層套件。然而，反對者則以 Python 為戒，指出將網路協議強行塞入標準庫往往會導致維護停滯，最終開發者仍會轉向社群維護的第三方套件。Go 語言的 HTTP 標準庫常被視為正面案例，但 Rust 社群普遍認為其語言特性更傾向於保持核心精簡。

在技術細節上，關於「零拷貝」的定義引發了深入的辯論。部分留言指出，Protobuf 的編碼特性（如 varints 變長整數）決定了它無法像 FlatBuffers 那樣實現真正的硬體級零拷貝，buffa 所實現的更精確來說應是「零分配」（zero-allocations），即透過 Rust 的借用檢查機制，讓字串或位元組欄位直接指向輸入緩衝區，而非重新分配記憶體。雖然這在語言層面極大地減輕了記憶體配置器的壓力，但對於數值型欄位，仍需在讀取時進行解碼處理。

此外，現有的 Rust RPC 生態系痛點也成為討論焦點。有開發者分享了在使用 Hyper 或 Tonic 時遇到的 HTTP/2 規範相容性問題，例如在 Nginx 或 ALB 後端處理 GOAWAY 訊號時的失效情況，因此對 connect-rust 抱持期待。與此同時，也有觀點提醒 Google 官方正在開發新的 grpc-rust 實現，未來可能出現官方與社群方案的競爭。最後，一些追求極致效能的開發者則認為，無論 Protobuf 如何優化，對於特定場景而言，自定義的 C 結構體搭配 UDP 傳輸依然是不可替代的低延遲方案。

延伸閱讀

• musttail: 一篇關於如何利用編譯器優化（如 tail calls）讓 Protobuf 解碼速度突破 2GB/s 的技術部落格。
• Protobuf String View: Google 官方關於 C++ 實現中引入 string_view 以減少拷貝的參考文件。
• upb: Google 官方 Rust 實作（protobuf v4）所依賴的微型 C 語言 Protobuf 函式庫。