gRPC-Web 流式传输路线图全解读：服务端流式现状、WebTransport 双向流与 WebSocket 取舍-北京尧图网络

后端微服务【免费下载链接】grpc-webgRPC for Web Clients项目地址https://gitcode.com/gh_mirrors/gr/grpc-web点击查看免费下载gRPC-Web 是 gRPC 的浏览器端 JavaScript 实现浏览器客户端需要借助 Envoy 等代理才能访问 gRPC 服务。本文以仓库内 doc/streaming-roadmap.md 为核心系统梳理 gRPC-Web 对流式 RPC 的完整规划服务端流式Server-streaming当前已支持并将持续增强、客户端流式与半双工流式暂不支持的决策逻辑、计划基于 WebTransport 实现全双工双向流式的技术路线以及团队为何明确放弃 WebSocket 方案的深层原因并结合仓库源码给出可验证的实现证据。一、路线图总览四类流式能力的现状与规划gRPC 共有四类 RPC 模式它们在 gRPC-Web 中的支持状态截然不同RPC 模式数据流向gRPC-Web 当前状态未来规划Unary一元单请求 → 单响应✅ 已支持持续维护Server-streaming服务端流式单请求 → 多响应✅ 已支持仅grpcwebtext模式持续改进见下文Client-streaming客户端流式多请求 → 单响应❌ 不支持随 WebTransport 全双工流式一并解决Full-duplex / half-duplex双向流式多请求 ↔ 多响应❌ 不支持依赖 WebTransport2023 规划这份路线图doc/streaming-roadmap.md明确列出了三个演进方向服务端流式的增强、客户端流式与半双工流式的未来方案、基于 WebTransport 的全双工流式并附带了对 WebSocket 的明确态度。主路线图文档 doc/roadmap.md 中Streaming Support与Bidi Streaming两节也分别指向本文档可见流式能力是 gRPC-Web 整体演进的核心议题之一。仓库中的 echo 示例net/grpc/gateway/examples/echo/echo.proto完整定义了这四类方法其中客户端流式与双向流式的定义旁都注有同一行说明Notice: Client side streaming and Bidi streaming are not supported at the moment.目前不支持客户端流式与双向流式。这份 proto 与路线图互为印证能力边界在服务定义和客户端运行时两个层面都是一致的。二、服务端流式Server-streaming已支持仍在演进2.1 当前支持范围服务端流式是 gRPC-Web 目前支持的两种 RPC 模式之一。仓库根目录 README.md 明确说明gRPC-web currently supports 2 RPC modes: Unary RPCs and Server-side Streaming RPCsNOTE: Only whengrpcwebtextmode is used.即服务端流式调用必须在grpcwebtextapplication/grpc-web-text线格式模式下才能工作使用二进制grpcwebapplication/grpc-webproto模式时仅支持一元调用。这一点在 README.md 的 Wire Format Mode 小节有详细描述modegrpcwebtextpayload 经 base64 编码Content-type: application/grpc-web-text一元与服务端流式调用均支持modegrpcweb二进制 protobufContent-type: application/grpc-webproto仅支持一元调用。客户端侧的服务端流式调用代码模式如下摘自 README.mdvar stream echoService.serverStreamingEcho(streamRequest, metadata); stream.on(data, function(response) { console.log(response.getMessage()); }); stream.on(status, function(status) { console.log(status.code); console.log(status.details); console.log(status.metadata); }); stream.on(end, function(end) { // stream end signal }); // to close the stream stream.cancel()2.2 服务端流式的底层实现链路从源码看服务端流式调用的入口在 javascript/net/grpc/web/grpcwebclientbase.js 的serverStreaming()方法它先解析出 hostname将发起流式请求包装为 invoker 后交给拦截器链最终返回一个GrpcWebClientReadableStream。该流对象在 javascript/net/grpc/web/grpcwebclientreadablestream.js 中实现on()注册事件支持data、status、metadata、end、error五类回调源码 grpcwebclientreadablestream.js与 README 示例中的用法一一对应cancel()取消流将aborted_置位并调用xhr.abort()源码 grpcwebclientreadablestream.js取消后的 ABORT 错误不会被当作异常抛出XHR 事件驱动流数据在READY_STATE_CHANGE事件中增量解析流结束状态在COMPLETE事件中统一判定并从响应头提取grpc-status/grpc-message与初始 metadata。响应体的帧解析由 javascript/net/grpc/web/grpcwebstreamparser.js 完成它实现goog.net.streams.StreamParser接口状态机在INIT帧字节→LENGTH4 字节长度→MESSAGE消息体之间流转支持流式分段输入partial stream segments。帧类型定义在源码 grpcwebstreamparser.jsGrpcWebStreamParser.FrameType { DATA: 0x00, // 数据帧 TRAILER: 0x80, // trailer 帧 };即服务端流式的响应在线上形如0x00 message1 0x00 message2 ... 0x80 trailers每条消息独立成帧最终以 trailer 帧携带 gRPC 状态收尾。2.3 路线图规划的服务端流式改进项路线图文档为服务端流式列出的改进方向与时间预期如下Fetch 取消支持2024当前客户端运行时基于 XHRgoog.net.XhrIo实现流取消依赖xhr.abort()迁移到 Fetch 后需要补齐 Fetch 的AbortController取消语义性能优化与 whatwg Fetch/streams 支持包括 Service Workers2024Fetch/ReadableStream 相比 XHR 在流式吞吐、内存占用上有优势也能让 gRPC-Web 请求进入 Service Worker 缓存/拦截体系完善 keep-alive 支持通过 Envoy2024长连接保活依赖代理层配合见 doc/roadmap.md 中 Envoy 相关说明弥合 Fetch 与 XHR 之间的运行时行为差异2024包括错误映射、超时语义、响应头可见性等细粒度行为对齐。这些条目都属于持续打磨性质说明服务端流式是当前主战场功能可用但传输层基座从 XHR 走向 Fetch/streams的替换是未来两年的主线。三、客户端流式与半双工流式为何暂不支持路线图对客户端流式的态度非常明确We dont plan to support client-streaming via Fetch/upload-streams. As a result, half-duplex bidi streaming wont be supported via Fetch/streams either.也就是说团队不计划通过 Fetch 的upload-streaming请求体流式上传能力去支持客户端流式因此依赖客户端先传完再收响应的半双工双向流式也不会借道 Fetch/streams 落地。这两类能力将被统一推迟到 WebTransport 全双工流式方案中一并解决。这一决策的直接背景是附录中记录的 Chrome Origin Trial详见第五节upload-streaming规范尚未定稿且 HTTP/1.1 下的安全性仍在讨论无法作为可靠的技术底座。从服务定义侧同样能看到印证echo 示例中ClientStreamingEcho、FullDuplexEcho、HalfDuplexEcho三个方法均带not supported at the moment注释echo.proto生成客户端代码时不会为它们产生可用的流式调用实现。四、全双工流式押注 WebTransport路线图规划的全双工双向流式方案是基于 WebTransport 实现时间预期为 2023按文档编写时的表述。WebTransport 的价值在于它在浏览器与服务器之间提供真正的双向、多路复用字节流能力天然契合 gRPC 全双工 RPC 的客户端流服务端流同时进行的语义而这正是 HTTP 请求/响应模型含 Fetch/streams无法覆盖的缺口。主路线图 doc/roadmap.md 的 Bidi Streaming 一节同样声明We plan to leverage WebTransport for bi-directional streaming两份文档口径一致。需要说明的是从当前仓库代码结构看javascript/net/grpc/web/ 目录下的运行时仍以 XHR 传输为主GrpcWebClientBase内部直接构造XhrIo并xhr.send()尚未包含 WebTransport 传输适配器WebTransport 支持仍处于路线图规划阶段而非已落地功能。这也意味着客户端流式与双向流式在本文撰写时仍是规划中状态读者不应期望在现网环境直接使用。五、WebSocket明确不采用以及背后的 HTTP 兼容性逻辑路线图给出了一个非常明确的负面决策We have no plan to support full-duplex streaming over WebSockets (over TCP or HTTP/2). We will not publish any experimental spec for gRPC over WebSockets either.即不打算在 WebSocket无论跑在 TCP 还是 HTTP/2 之上上支持全双工流式也不会发布任何gRPC over WebSocket的实验性规范。理由集中在一点——WebSocket 与 HTTP以及承载 Web 的普遍基础设施不兼容HTTP 回退总是必要WebSocket 一旦不可用网络设备、企业代理、部分移动网络等必须回退到 HTTP 通道这意味着每个使用 WebSocket 的方案都要维护两套传输逻辑HTTP/2 上的 WebSocket 隧道普及度不足虽然 IETF 有将 WebSocket 封装进 HTTP/2 的提案但并未被广泛实现无法形成可靠基线对比之下WebTransport 构建在 HTTP/3 生态之上与现有 Web 基础设施TLS、代理、CDN的兼容路径更清晰这也是团队选择 WebTransport 而非 WebSocket 的关键考量。六、附录解读Chrome Origin Trial 与upload-streaming的来龙去脉路线图附录记录了团队参与推进 whatwgfetch/upload-streamAPI 规范的背景他们参与了 Chrome 的 Origin Trial试验编号 3524066708417413121目标是让浏览器能通过 Fetch API 流式上传请求体。阻塞最终规范定稿的核心问题是是否允许 upload-streaming 跑在 HTTP/1.1 上。团队立场是 HTTP/2 与 HTTP/1.1 都应启用 upload-streaming并给出一个针对 gRPC-Web 场景的独特论据the server cant control the client deployment. As a result, if upload-streaming is only enabled over HTTP/2, a gRPC service will have to implement a non-streaming method as a fallback for each client-streaming method.翻译过来就是gRPC-Web 的服务端无法控制浏览器客户端的部署环境。如果 upload-streaming 只在 HTTP/2 下可用那么任何提供客户端流式方法的 gRPC 服务都必须为每个客户端流式方法额外实现一个非流式一元方法作为回退——这会显著增加服务端负担。因此他们主张 HTTP/1.1 同样支持上传流式。正是由于该规范尚未定稿、且存在 HTTP 版本兼容性分歧客户端流式方案无法建立在 Fetch/upload-streams 之上最终被并入 WebTransport 路线——这正是第六节暂不支持客户端流式决策的完整逻辑链条。七、结论与决策摘要结合 doc/streaming-roadmap.md 与仓库实现可以得出 gRPC-Web 流式能力的完整时间线认知服务端流式当前可用仅grpcwebtext模式底层由GrpcWebClientReadableStreamGrpcWebStreamParser提供事件驱动解析2024 年起逐步将传输基座从 XHR 迁移到 Fetch/streams补齐取消、Service Worker、keep-alive 等能力客户端流式 / 半双工流式不通过 Fetch/upload-streams 支持等待 WebTransport 方案统一解决全双工流式规划基于 WebTransport 实现2023 规划当前仓库代码尚无对应传输层实现WebSocket明确弃用核心原因是与 HTTP 基础设施的不兼容及 HTTP/2 隧道普及度不足。对于正在基于 gRPC-Web 做技术选型的读者这份路线图的实用价值在于短期可放心使用一元与服务端流式注意选择grpcwebtext线格式并配置好 Envoy 代理参考 net/grpc/gateway/examples/echo/envoy.yaml 中的grpc_web过滤器与 CORS 配置若业务强依赖客户端流式或双向流式则当前阶段需要评估服务端方案如 gRPC over HTTP/2 直连、或等待 WebTransport 生态成熟这与上游 doc/roadmap.md 的整体规划一致。赞分享后端微服务【免费下载链接】grpc-webgRPC for Web Clients项目地址https://gitcode.com/gh_mirrors/gr/grpc-web点击查看免费下载相关推荐使用 Node.js 客户端库接入 Google Analytics Data API v1beta安装、认证与报表实战指南使用 Node.js 客户端库接入 Google Analytics Data API v1beta安装、认证与报表实战指南 Google Analytics后端微服务gRPC Python 数据传输四种调用模式一元、客户端流、服务端流与双向流完整实战解析gRPC Python 数据传输四种调用模式一元、客户端流、服务端流与双向流完整实战解析本指南基于 gRPC 官方仓库中的 data_transmissio后端RPC框架微服务通信gRPC Python 四种数据传输模式实战从 proto 定义到一元、客户端流、服务端流与双向流gRPC Python 四种数据传输模式实战从 proto 定义到一元、客户端流、服务端流与双向流 gRPC 在 Python 中支持四种 RPC 数据传输模后端RPC框架微服务通信上一篇Awoo Installer1个NSP安装器3种方式装Switch游戏下一篇跨平台私有音乐服务终极指南any-listen快速搭建与深度使用创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

gRPC-Web 流式传输路线图全解读：服务端流式现状、WebTransport 双向流与 WebSocket 取舍

相关推荐

PHP 自动化请求与模拟登录：不写刷赞工具也能练透这些技术

酒店智能客房设备和服务响应系统如何管理，如何选择

SPL 迁移到 Axiom APL 实战指南：基于 spl-to-apl 技能的完整查询翻译手册

更多资讯

Moto 状态转换机制深度解析：State Manager 使用与扩展指南

swagger-codegen 生成 Java 客户端复杂 Map 模型实战：以 Petstore 的 MapTest 为例

CLI Agent 运行时工程化：MCP 与 OpenRouter 集成实践

Atlas 300V实战：YOLOv8部署全流程解析

金融场景下的Managed Agents实战：从Claude API到plugin接入

Comsol仿真Ar棒板粗通道流注放电的工程实践

今日更新

AI元人文：从工具使用到思维重构的深度探索

Python+CNN车牌识别实战：从数据预处理到模型训练与部署

Vim基础操作全攻略：保存退出、模式切换与高频命令实战

本周精选

深入解析Transformer多头注意力机制与工程优化

OpenClaw 的 Skills 跑学习任务，模型通道改到 TaoToken 通道行不行？

ChatGPT报错Oops, an error occurred! 全链路排查指南

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？