使用 gRPC 共享非常大的文件。

Question

我想使用gRPC在端点和服务器之间共享非常大的文件（超过6GB）。

我目前工作的项目需要一个中央服务器，端点可以上传和下载文件。其中一个限制是端点彼此不认识，但它们可以通过公共总线相互接收和发送消息。

为了实现这个服务器及其与端点的通信，我正在评估使用gRPC。您认为这是文件流的最佳解决方案吗？我还有哪些替代选择？

提前感谢。

- Marco Fiorillo

---

直接提供一个下载链接怎么样？HTTP服务器从一开始就可以处理大文件下载，为什么要在这里重新发明轮子呢？ - Lasse V. Karlsen

gRPC很有用，但它并不能解决巨大带宽问题；我的意思是...当然，你可以使用gRPC术语中的数据块流，但是...一个普通的vanilla http下载似乎更简单。 - Marc Gravell

巨大的带宽问题是一个大问题，但我也读到过 gRPC 在处理大于 2GB 的文件时并不优化，但除了论坛上的一篇文章外，我没有找到其他任何信息。有人知道更多吗？顺便说一句，我忘了说我需要使用安全的方式传输这个文件，比如使用 SSL。 - Marco Fiorillo

@MarcoFiorillo gRPC可以在TLS内部工作；这不是问题 - 如果您真的想使用gRPC，您将使其成为返回文件的多个段的“服务器流”方法，在单个一元响应而不是一个单一的响应中分别返回这些段; 这就是你想要的吗？ - Marc Gravell

补充Marc Gravel的回答，下载方（调用方）将不得不手动聚合流式传输块...Grpc保证按顺序重放，因此无需发送块索引。最近我提议将文件传输Proto消息标准化到Grpc和Grpc Web项目中。也许更广泛的社区会帮助实现这一目标。 - Alexander.Furer

Answer 1

使用客户端/服务器流的 gRPC 可以处理文件的上传/下载。但是，这里有一篇关于 gRPC 与 HTTP 文件上传/下载性能对比的讨论，它指出 HTTP 在上传/下载方面速度更快，因为这仅涉及到读取/写入传入的字节，而 gRPC 对每个消息流执行额外的序列化/反序列化，导致显著的开销。

还有一篇博客对此进行了一些基准测试 - https://ops.tips/blog/sending-files-via-grpc/。

如果你正在寻找要处理规模的实现，可以进行更多的研究。

- Himanshu Shekhar

Answer 2

如果您真的想通过gRPC实现这个目标，那么关键是要做出“服务器流”响应。这样，它就不会一次性返回6GiB的数据块，而是按需多次返回多个大小为128kiB 的数据块（或其他大小）。您可以使用以下方式实现：

syntax = "proto3";
message FileRequest {
    string id = 1; // or whatever
}
message FileResponse  {
    bytes chunk = 1; // some segment of the file
}

service SearchService {
  rpc GetFile(FileRequest) returns (stream FileResponse);
}

但是没有什么是自动的：现在需要你的工作将多个片段重新编写回来。

我怀疑一个普通的http下载式响应可能会更简单！

- Marc Gravell

---

谢谢您的回答，但如果您有其他选项，我想评估一下。我也在评估TCP客户端+SSL流，但我也在评估HTTP下载响应！谢谢我以为有某种自动化方式可以将所有块合并在一起。 - Marco Fiorillo

你能给我一个有关“HTTP下载式响应”的链接或更多信息吗？谢谢。 - Marco Fiorillo

@MarcoFiorillo 我的意思是普通的http[s] - 就像文件传输已经进行了几十年一样。 - Marc Gravell

对不起，我以为你在谈论基于HTTP(S)的某个框架。 - Marco Fiorillo

@MarcoFiorillo 多年来人们一直在使用HTTP/1.2，当您发送数据（字节流在您的情况下）时，它会打开一个新的TCP连接，因此打开一个新的TCP连接是昂贵的。而使用gRPC，您可以重用相同的TCP连接并流式传输数据。我不确定REST实现对您来说如何比gRPC更快。 - DV Singh