情况
我的团队正在创建一个接收大型结构化文本文件的API（100MB - 1TB，预期为1GB）并修改每一行并返回生成的文件。我们可以像传输文件一样快速处理文件，因此我们希望避免在我们的服务器上缓存文件。我们倾向于为我们的客户使用易用的资源，因此这不是一项艰难的要求。
部分选项
HTTP/1.1隐式要求在发送回复（except in the case of errors）and bad things can happen, especially with proxies, if you try to get around this之前处理完整请求。因此，我们要咬紧牙关并存储请求或响应，并使用我们组织中的其他资源上传大文件进行处理。
所有主流浏览器都支持HTTP / 2 explicitly allows you to send before the request has finished and requires that the client read what you send和HTTP / 2。
所以，我看到一些潜在的api（所有POST）：
HTTP1.x：上传/下载 - 此
已有一些基础设施/transformed_file_id/ --> returns id for the uploaded file
/transformed_file/{id} --> returns the transformed data
HTTP1.x：单个请求
/transformed_file/ --> returns the transformed version of the file - stores stuff under-the-hood
HTTP2：单一请求
/transformed_file/ --> returns the transformed version of the file - starts sending response as soon as it receives the first couple of K.
问题
虽然我不会回避它的浏览器内容，但为了访问此功能，使用HTTP / 2服务是否明智？
或者这是一个坏主意，客户应该被迫一次上传文件的较小部分（我们需要编写一个前端来允许在浏览器界面上 - 这可能是相当的韧）。
答案 0 :(得分：3)
我对各种客户端，服务器和代理的经验是，HTTP / 1.1要求在应用程序开始响应之前发送完整请求是不正确的。它一直在发生。
另一方面，如果您的客户必须在单个请求中上传100 MiB - 1 TiB数据（！），我会设置一些机制来恢复上传失败，类似于下载的范围标题。 另见：Standard method for HTTP partial upload, resume upload
话虽如此，使用HTTP / 2和大型上传，您必须特别注意客户端的流控制发送窗口。 这默认为64 KiB，这意味着客户端在等待服务器确认该内容之前最多只能发送64 KiB。 确认必须从服务器传送到客户端，因此网络延迟在这里发挥着重要作用：客户端可能非常快速地写入64 KiB，但随后大部分时间等待服务器确认。 这可能会导致上传速度大幅下降。
为了给你一个想法，浏览器（Firefox）修改他们的接收窗口，以便能够从64 KiB到12 MiB（几乎200x）的服务器执行快速下载。 不幸的是，他们不会对上传做同样的事情。
您不指定您的客户是否是浏览器;如果没有，请确保您可以控制流控制窗口的配置，包括发送和接收，并放大它们，以免流量控制确认减慢速度。
答案 1 :(得分：0)
正如sbordet所提到的，HTTP / 1.1支持流式下载。每次下载大文件时都会发生这种情况。
但是，我不认为您的用例可以同时上传下载新文件。客户端上传1TB需要多长时间？如果连接中途掉线怎么办？
允许客户端上传整个文件然后在后台处理它可能更简单，更安全。完成后，客户端可以使用浏览器下载整个文件。
我认为您需要一种管理上传过程的好方法。虽然您可以编写Javascript或扩展程序，但应该有许多优秀的上传管理器扩展程序。通过HTTP和浏览器进行文件传输非常强大。