【发布时间】：2019-04-13 12:37:22
【问题描述】：
gRPC 客户端流式传输/双向流式传输如何使用 HTTP/2 实现？
服务器流式传输是有道理的，因为它可以利用服务器推送向请求发送多个响应，但我不清楚它如何像通过 websocket 那样通过 HTTP/2 进行双向消息传递。
【问题讨论】：
【发布时间】：2019-04-13 12:37:22
【问题描述】：
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 的实践中很少见，因为状态码已经返回；以后的任何处理错误都是非标准的沟通方式。