gRPC 客户端流是如何实现的

Posted 2023-03-10

【中文标题】gRPC 客户端流是如何实现的

【英文标题】：How is gRPC client streaming implemented

【发布时间】：2019-04-13 12:37:22

【问题描述】：

gRPC 客户端流式传输/双向流式传输如何使用 HTTP/2 实现？ 服务器流式传输是有道理的，因为它可以利用服务器推送向请求发送多个响应，但我不清楚它如何像通过 websocket 那样通过 HTTP/2 进行双向消息传递。

【参考方案1】：

gRPC 将流编码为 HTTP 主体。每条消息前有一个 5 字节的头，由消息长度和标志字节组成。它不使用 SERVER_PUSH 或其他特定于 HTTP/2 的功能进行流式传输。

gRPC 的核心是流式传输。一元（单个请求，单个响应）和服务器流式处理（单个请求）只是用于生成更清晰的 API 或更优化的 I/O 行为的特殊情况。但在网络上，一切看起来都与流式传输相同。

HTTP/1 的规范允许但不要求流式连接和双向连接，但某些实现不支持它们。但是由于 HTTP/2 的性质，通常不支持它们需要更多的工作。此外，没有十年前的 HTTP/2 代理会导致兼容性问题。 gRPC 能够与 HTTP/2 生态系统一起工作，以鼓励支持流式传输。

有关 gRPC 编码的更多信息，请参阅 gRPC 的PROTOCOL-HTTP2.md，尤其是Length-Prefixed-Message。

【讨论】：

那么在这种情况下，响应头和正文中的消息是在收到整个请求之前发送的（在双向流的情况下）？

是的，可能。这里实际上有两个独立的概念：流式传输（多条消息）和双向通信（同时发送和接收）。流在 HTTP/1 中很常见，用于大文件上传/下载。在接收到整个请求之前响应在 HTTP/1 中很常见，例如 404 错误。Bidi 有点多，因为它允许服务器在开始响应后继续接收。这在 HTTP/1 的实践中很少见，因为状态码已经返回；以后的任何处理错误都是非标准的沟通方式。