为什么在GRPC/protobuf文件传输中使用“stream”？

Question

我见过几个这样的例子：

service Service{
  rpc updload(stream Data) returns (google.protobuf.Empty) {};
  rpc download(google.protobuf.Empty) returns (stream Data) {};
}

message Data { bytes bytes = 1; }

使用流的目的是什么，它是否能提高传输效率？

理论上-是的-我显然不想流式传输我的文件传输，但这就是在连接上发生的。。。那么，这个关键字的实际好处是什么呢？它是否强制执行某种形式的特殊缓冲以减少一些开销？无论哪种方式，数据都在完整传输！

Answer 1

它更有效，因为在一次调用中，可能会发送多条消息。

这不仅避免了与服务器重新建立另一个（希望是TLS，即更多工作）连接，而且避免了客户端和服务器“存根”的旋转；客户端和服务器都准备好接收更多消息。

这有点类似于和你的朋友打电话，他在挂断电话前说“哦，另一件事......”。而不是挂断电话，然后，5分钟后，给你回电话，打断晚餐，让你暂停电影。

Answer 2

答案与gRPC图像上传问题非常相似，尽管从不同的角度来看。

将大下载（10 MB）作为单个响应消息对下载的大小有很大限制，因为整个响应消息是一次发送和处理的。对于大多数用例，将100 MB的文件分块成1-10 MB的块比要求所有100 MB一次都在内存中要好得多。这也允许下载器在获取整个文件之前开始处理文件，从而减少处理延迟。

如果没有流，分块将需要多个RPC，这很烦人，协调起来很麻烦，而且性能复杂。因为完成RPC有延迟，为了获得合理的性能，您要么必须并行执行许多RPC（但是有多少？）或者有很大的批量大小（但是有多大？）。多个RPC也可以访问更冷的应用程序缓存，因为每个RPC都去到不同的后端。

使用流式传输提供了与非分块方法相同的吞吐量，而没有普通分块方法的许多麻烦。由于流式传输是流水线式的（服务器可以在发送前一个块后立即开始发送下一个块），因此客户端和服务器之间不会增加每个块的延迟。这使得选择块大小变得更加容易，因为有各种各样的“合理”大小会表现相似，系统会随着网络性能的变化而自然做出反应。

虽然在现有流上发送消息比创建新的RPC开销更小，但对于许多用户来说，这种差异可以忽略不计，通常最好以对应用程序有利的架构方式构建RPC，而不仅仅是在gRPC中进行小的优化。在这种情况下使用流的原因是为了使您的应用程序在较低的复杂性下性能更好。