我是否应该为转换大文件的 REST API 使用 HTTP/2 特定功能
Should I use an HTTP/2 specific feature for a REST API that transforms a large file
情况
我的团队正在创建一个 API 接收大型结构化文本文件（100MB - 1TB，预计 1GB）并修改每一行和 returns 生成的文件。我们可以在传输文件时尽可能快地处理文件，因此希望避免在我们的服务器上缓存文件。与我们自己的资源使用相比，我们更倾向于为客户提供易用性，因此这不是硬性要求。
部分选项
HTTP/1.1 implicitly requires that the full request be processed before the response is sent (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：upload/download - 已经有一些基础设施
/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 服务以访问此功能是否明智？
或者这一切都是一个坏主意，应该强制客户一次上传文件的较小部分（我们需要编写一个前端以允许在浏览器界面上进行此操作 - 这可能相当艰难）。
我对各种客户端、服务器和代理的经验是，HTTP/1.1 要求在应用程序开始响应之前发送完整请求是不正确的。它一直在发生。
另一方面，如果您的客户必须在单个请求中上传 100 MiB - 1 TiB 的数据 (!)，我会设置一些机制来恢复上传失败，类似于范围 headers下载。
另见：Standard method for HTTP partial upload, resume upload
话虽如此，对于 HTTP/2 和大上传，您必须特别注意客户端的流量控制发送 window。
默认情况下为 64 KiB，这意味着客户端在等待服务器确认该内容之前最多只能发送 64 KiB。
确认必须从服务器传输到客户端，因此网络延迟在这里起着重要作用：客户端在写入 64 KiB 时可能非常快，但大部分时间都在等待服务器确认。
这可能会导致上传速度严重下降。
为了给你一个想法，浏览器 (Firefox) 修改了它们的 receive window 以便能够从 64 KiB 到 12 MiB 的服务器执行快速下载（几乎 200 倍）。
不幸的是，他们不对上传做同样的事情。
您没有指定您的客户端是否是浏览器；如果没有，请确保您可以控制流量控制的配置 window，包括发送和接收，并将它们放大到足以不被流量控制确认减慢。
如 sbordet 所述，HTTP/1.1 支持流式下载。每次下载大文件时都会发生这种情况。
但是，我认为您的用例不适合同时上传和下载新文件。客户端上传1TB需要多长时间？中途掉线怎么办？
让客户端上传整个文件然后在后台处理它可能更简单和更安全。完成后，客户端可以使用浏览器下载整个文件。
我认为您需要一种管理上传过程的好方法。尽管您可以编写 Javascript 或扩展程序，但应该已经有许多不错的上传管理器扩展程序可用。通过 HTTP 和浏览器的文件传输是可靠的。
情况
我的团队正在创建一个 API 接收大型结构化文本文件（100MB - 1TB，预计 1GB）并修改每一行和 returns 生成的文件。我们可以在传输文件时尽可能快地处理文件，因此希望避免在我们的服务器上缓存文件。与我们自己的资源使用相比，我们更倾向于为客户提供易用性，因此这不是硬性要求。
部分选项
HTTP/1.1 implicitly requires that the full request be processed before the response is sent (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：upload/download - 已经有一些基础设施
/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 服务以访问此功能是否明智？
或者这一切都是一个坏主意，应该强制客户一次上传文件的较小部分（我们需要编写一个前端以允许在浏览器界面上进行此操作 - 这可能相当艰难）。
我对各种客户端、服务器和代理的经验是，HTTP/1.1 要求在应用程序开始响应之前发送完整请求是不正确的。它一直在发生。
另一方面，如果您的客户必须在单个请求中上传 100 MiB - 1 TiB 的数据 (!)，我会设置一些机制来恢复上传失败，类似于范围 headers下载。 另见：Standard method for HTTP partial upload, resume upload
话虽如此，对于 HTTP/2 和大上传，您必须特别注意客户端的流量控制发送 window。 默认情况下为 64 KiB，这意味着客户端在等待服务器确认该内容之前最多只能发送 64 KiB。 确认必须从服务器传输到客户端，因此网络延迟在这里起着重要作用：客户端在写入 64 KiB 时可能非常快，但大部分时间都在等待服务器确认。 这可能会导致上传速度严重下降。
为了给你一个想法，浏览器 (Firefox) 修改了它们的 receive window 以便能够从 64 KiB 到 12 MiB 的服务器执行快速下载（几乎 200 倍）。 不幸的是，他们不对上传做同样的事情。
您没有指定您的客户端是否是浏览器；如果没有，请确保您可以控制流量控制的配置 window，包括发送和接收，并将它们放大到足以不被流量控制确认减慢。
如 sbordet 所述，HTTP/1.1 支持流式下载。每次下载大文件时都会发生这种情况。
但是，我认为您的用例不适合同时上传和下载新文件。客户端上传1TB需要多长时间？中途掉线怎么办？
让客户端上传整个文件然后在后台处理它可能更简单和更安全。完成后，客户端可以使用浏览器下载整个文件。
我认为您需要一种管理上传过程的好方法。尽管您可以编写 Javascript 或扩展程序，但应该已经有许多不错的上传管理器扩展程序可用。通过 HTTP 和浏览器的文件传输是可靠的。