我在 2 个 EC2 实例上有一个应用程序，位于 ELB 后面。ELB 执行 HTTPS 终止，然后通过 HTTP 与实例通信。
通过 HTTPS 上传时，传输速度似乎限制为每个文件约 10 Mbps（例如，2 个文件上传速度为 20 Mbps，3 个文件上传速度为 30 Mbps，依此类推），而如果我通过 HTTP 传输，一个文件就可以轻松填满 100 Mbps 的上传链接。
我尝试将 HTTPS 终止移至实例（nginx），并且我的测试给出了相同的结果。
我尝试过不同的客户端（操作系统和浏览器）和不同的上行链路网络。结果总是相同的。
我真的不知道从哪里开始解决这个问题，所以任何指导都将非常感谢。
答案1
我猜 ELB 是为水平可扩展性而设计的，不一定是为高单流吞吐量而设计的。这也是您所观察到的 - 许多并发流都表现良好，但每个流都限制在某个最大吞吐量。
如果你想加快上传到 AWS 的速度，请查看S3 传输加速- 这可能会快得多，并且您的文件将直接保存到 S3 存储桶中，然后您的应用程序可以对其进行进一步处理。您甚至可以获得SNS 通知每当有新文件上传完成时，您就可以立即开始处理。
当然取决于您的用例，但通过 ELB 和 Nginx 上传大文件似乎并不是您为此目的使用的最佳服务。这些更适合处理大量并发用户，而不是少数重度用户。
希望有帮助:)
答案2
所以事实证明这是一个 HTTP2 问题。
引用 AWS Support 代表的话：
虽然 ALB 在通过 HTTPS 连接时支持使用 HTTP 2.0 协议传输数据，但如果客户端在连接中使用单个流上传文件，则上传文件的速度可能会比 HTTP1.1 慢。
在一般用途中，HTTP2 在 TCP 流控制之上引入了一个额外的流控制层，旨在允许应用程序控制每个 HTTP2.0 流的吞吐量，从而允许应用程序确保平等处理连接上的所有流，或者相反，优先考虑一个或多个流。
在 ALB 中，单个流的 HTTP/2.0 窗口更新上限为 64K。客户端必须每 64KB 持续通告一次 WINDOW_UPDATE 帧，否则，如果速度较慢，当在相对高延迟的网络上仅使用一个流进行较大上传时，将对吞吐量产生负面影响，而 HTTP/1.1 或更低版本则没有此功能。
一般来说，互联网上的客户端，如 Chrome、Firefox 等，都设计为以缓慢的方式宣传这一点，因为服务器对帧的限制较大，会产生延迟。
我们禁用了 HTTP2，上传速度现在非常快！