Cloudflare Workers 自 2017 年推出以來，長期以來在網路通訊協定上存在一個核心限制：它僅能作為 HTTP 伺服器接收請求。雖然 Worker 可以透過出站 Socket（Outbound Sockets）主動連接外部資料庫或服務，但無法直接接收來自客戶端的非 HTTP 流量。這種設計雖然簡化了伺服器無伺服器化（Serverless）的部署，卻也讓許多需要持久連線或自定義二進位協定的應用場景無法在邊緣端實作。
為了打破這個限制，Cloudflare 近期推出了新的 connect(socket) 處理程序，正式讓 Workers 能夠接收入站 TCP 連線（Inbound TCP Connections）。這意味著 Workers 不再僅限於處理 HTTP 請求，而是可以處理任何基於 TCP 的原始流量。此次更新的重點在於將 gRPC 作為第一個正式支援的協定，旨在滿足對低延遲、雙向通訊有高度需求的現代應用，例如 AI 語音代理（Voice AI Agents）。
技術實作與流量路徑
這次功能的實現依賴於 Cloudflare 現有的 Spectrum 服務。Spectrum 是一個入站代理（Ingress Proxy），專門處理非 HTTP 的流量。當 TCP 流量進入時，Spectrum 會將其路由至 Worker 的 connect(socket) 處理程序中。開發者可以在這個處理程序中直接讀寫 Socket，或者將該 Socket 轉交給另一個 Worker，甚至是傳遞給 Durable Object（一種提供狀態儲存與單一執行實例的邊緣物件）。
如果需要更深層的處理，Durable Object 還可以透過 getTcpPort() 將 Socket 轉發至容器（Container），從而完成完整的全雙工（Full-duplex）通訊路徑。這使得開發者能夠在邊緣端運行未經修改的 Go gRPC 伺服器或 Python socketserver，實現客戶端與伺服器之間任意語言、任意 TCP 協定的雙向溝通。
gRPC 的轉譯機制與限制
儘管底層支援了 TCP，但 Cloudflare 在實作 gRPC 時採取了轉譯而非原生支持的策略。對於不使用容器的純 Worker 環境，目前僅支援單一請求（Unary）與伺服器串流（Server-streaming）gRPC，並不支援雙向串流（Bidirectional streaming）。
這種限制源於 Web 平台 API 的底層設計。gRPC 依賴於 HTTP/2 的幀（Frames）與串流 ID（Stream IDs）來實現流控、取消請求與傳送 Trailer（尾端標頭）。然而，目前的 Web 標準 API（如 fetch）並不暴露這些底層控制權，瀏覽器同樣面臨此問題，這也是為何業界需要 gRPC-web 的原因。
因此，Cloudflare 的運作方式是將接收到的 gRPC 流量在內部轉譯為 gRPC-web，讓 Worker 處理，再將結果轉譯回 gRPC 回傳給客戶端。雖然這對現有的行動端客戶端（如使用 Swift 或 Kotlin 的 App）是透明的，無需修改代碼，但對於需要極端精準背壓控制（Backpressure Control）的串流應用，這種轉譯層可能會帶來潛在的穩定性挑戰。
實務意義與平台潛力
從平台工程的角度來看，這次更新的意義遠超 gRPC 本身。將 Worker 定位在 TCP 流量的進入點，使其扮演了類似 API 閘道（API Gateway）的角色，但在處理層級更低——它在決定流量去向之前，就能先看到原始的 Socket 連線。這為未來實作自定義二進位協定、訊息代理（Message Brokers）或資料庫代理（Database Proxies）打開了大門。
此外，這次更新與 MCP（Model Context Protocol）規範的趨勢相吻合。隨著 AI 代理基礎設施的發展，開發者發現許多機器對機器（M2M）的通訊需求，最終又回到了 gRPC 這種高效能的遠端程序呼叫（RPC）慣例上。
目前該功能仍處於私人測試階段（Private Beta）。值得關注的是，Cloudflare 坦承內部並不使用 gRPC，而是使用 Cap'n Proto 等其他系統。這顯示出該功能目前更多是為了滿足生態系開發者的需求，而非經過內部大規模驗證的成熟產品。對於評估此技術的團隊而言，應將其視為一個強大的原語（Primitive），但在正式部署前需謹慎考慮其在串流處理上的成熟度。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。