Cloudflare Workers 支持入站 TCP，gRPC 成为基于此构建的协议的首个

Cloudflare Workers "现在可以 接受入站的TCP连接 "。自2017年该平台推出以来，Worker可以打开到数据库或服务的出站套接字，但只能作为HTTP服务器。新的连接（套接字）处理器移除了该限制，而 gRPC "支持是首个构建在其上的协议。 这项公告是在“Agents Week（智能体周）”期间发布的，该特性主要围绕语音AI展开，因为在这种场景下，低延迟以及客户端与模型之间保持持久的双向连接至关重要。然而，其底层支持的能力实际上比这一应用场景所暗示的要广泛得多。 此次同时发布了三项功能，它们各自有着不同的性能上限。 连接（套接字）处理程序可以接收原始的入站套接字，并通过 Spectrum "路由至Worker。Spectrum是Cloudflare现有的用于处理非HTTP流量的入口代理。Worker可以直接读写该套接字，将其传递给另一个Worker，或者转交给 Durable Object "进行处理： export default { async connect(socket): Promise { const writer = socket.writable.getWriter(); await writer.write(new TextEncoder().encode("Hello, world!\n")); await writer.close(); }, } satisfies ExportedHandler; 通过Durable Object，套接字还可以借助getTcpPort()方法进一步传递给 Container "，全双工通信路径也会在此处终结。Cloudflare提供的示例包括一个Go语言编写的gRPC回显（echo）服务器和一个Python语言编写的socketserver，两者均不需要任何修改即可运行。用官方的话来说，这为客户端与服务器之间的全双工通信打开了大门，支持运行任何程序、使用任何语言以及基于任何TCP协议。 相比之下，Workers本身获得的能力要少一些。它们无需Container即可提供一元（unary）和服务器流式（server-streaming）的gRPC服务，也能调用外部的gRPC服务器，但不支持双向的流式传输。它的底层机制是协议转换而非原生支持：开发者代码使用的是 gRPC-web "，Cloudflare负责将传入的gRPC转换为gRPC-web，并将传出的gRPC-web转换回gRPC。 文章直接解释了这一限制背后的平台约束原因： HTTP/2 "将请求拆分为携带流ID（stream ID）的帧，而gRPC的流式传输、取消操作、流量控制和尾部元数据（trailers）都依赖于这种流级别的控制。然而，Web平台API（比如，fetch()）并未暴露这种控制能力。浏览器也面临同样的问题，这正是gRPC-web诞生的原因。 自2020年以来 "，Cloudflare一直在其反向代理内部将gRPC转换为HTTP/1.1，以便 相关博客 "），以便 WAF规则 "和机器人管理（Bot Management）能够检查消息的内容。 针对这一限制，Sebastian Buzdugan在Cloudflare发布 公告的评论区 "提出了一个更务实的限制问题：Workers是否为gRPC流提供了足够的回压（backpressure）控制？他指出，正是这些流处理的边缘情况决定了该实现是否真正可靠。但官方文章并未对此作出回应。 从实际效果来看，现有的客户端无需做任何更改。Worker可以为使用 grpc-swift-2 "或 grpc-kotlin "的移动应用提供服务，也可以像现在支持REST API一样，部署在现有的gRPC后端的前面。在服务端，只需使用开源的 @connectrpc/connect "包编写几行代码即可实现。 公告中最坦诚的部分，是 Cloudflare解释了为什么这项功能目前处于私有测试（private beta）阶段而非全面可用（GA）：Cloudflare内部并不使用gRPC。 “在 Cloudflare，我们使用的是 Cap'n Proto "、Cap'n Web以及内置于Cloudflare Workers中的JavaScript原生RPC系统，而不是gRPC。我们在发布任何功能时，始终力求自己也在实际使用它们。” 一家供应商在发布新功能时附带这样的说明是非常罕见的，这也为外界设定了一个诚实的预期。Cloudflare表示，他们希望先与一小部分gRPC开发者合作，在确保实现无误后再向所有人开放。评估该功能的团队应将其视为关于技术成熟度的信号，而非单纯的谦虚之辞。 对于平台团队而言，更关键的问题在于，除了公告中提到的应用场景，这一底层原语还能带来什么？八年来，Workers一直受限于HTTP协议，这直接排除了许多类型的工作负载，如消息代理、数据库代理、自定义二进制协议，以及所有依赖套接字的应用。现在，将套接字从Worker传递给Durable Object再传递给Container，使得边缘节点成为了任意TCP协议的终止点，并且在此之前可以通过JavaScript编写路由逻辑。 这种路由位置非常值得注意。Worker在决定连接的去向之前，会先“看到”该连接。这与API网关在转发请求前进行决策的逻辑完全一致，只不过这里针对的是原始套接字而非HTTP。Worker处于这个位置时，能对套接字进行哪些检查或策略干预，公告中并未提及。 gRPC的这一进展也恰逢其时。 2026年7月28日发布的MCP规范 "在HTTP之外，新增了gRPC作为可选的传输协议。针对该版本，有开发者指出，如今的智能体基础设施在很大程度上只是在重新发现早于它的远程过程调用（RPC）规范。一个由谷歌在近十年前发布的协议，如今不断成为机器间通信的首选答案，甚至包括那些原本围绕HTTP设计的系统。 尽管文章中提到的所有功能目前都需要通过注册表单才能进入私有测试阶段，但是Cloudflare官方社交媒体上的宣传文案却称， 对gRPC的支持“现已可用”，并描述了在边缘原生环境提供了gRPC服务而无需翻译层。从该宣传渠道了解情况而来的读者会发现，实际发布的范围比宣传的要更窄。Cloudflare表示，下一步将支持基于UDP的协议。 查看英文原文： Cloudflare Workers Accept Inbound TCP, with gRPC the First Protocol on Top "