我是一名客户，我为其开发了Rails应用程序。该应用程序依赖于他的客户上传各种图像，文件和pdf大小范围从1mb到100mb。
他一直在告诉我，他的很多客户都在抱怨上传速度缓慢和不稳定。
我使用直接连接到Amazon S3来处理上传。我向他解释说，在上传速度方面，有些因素是我无法控制的。
但他坚持认为我们可以做些什么来提高上传速度。
我在这里缺乏想法和专业知识。有没有人有解决方案？
答案 0 :(得分：1)
从表面上看，有两个答案 - 不，当然，你无能为力，互联网是一种尽力而为的交通工具等等......，不，真的不应该一个问题，因为S3上传效果非常好。
但是有一个值得考虑的选择。
您可以在S3前部署代理服务器的全局网络，并使用地理DNS将这些客户路由到最近的代理。然后从代理回到S3安装高速，低延迟光路，减少路径中“未知”的数量，并减少浏览器和所选代理节点之间的往返时间和数据包丢失潜力。网络的优势，提高吞吐量。
我希望上一段在第一次阅读时很有趣，因为这听起来像是一个改进上传到S3的荒谬宏伟计划......但当然，我指的是CloudFront。
您实际上不必将其用于下载;如果你愿意，你可以用它上传。
您的用户现在可以从加速内容上传中受益。为应用程序的分发启用其他HTTP方法后，PUT和POST操作将通过CloudFront边缘位置发送到源（例如Amazon S3），从而提高效率，减少延迟，并允许应用程序受益于受监视的持久性CloudFront从边缘位置维护到源服务器的连接。
https://aws.amazon.com/blogs/aws/amazon-cloudfront-content-uploads-post-put-other-methods/
为了说明这里的好处确实有一个坚实的理论基础......
在我们仍然使用telnet的那天，当T1是快速互联网连接而33.6kbps是一个很好的调制解调器时，我发现我有更好的家庭响应，如果我第一次与远程系统建立telnet连接在调制解调器链路的另一端立即建立到服务器的telnet连接，然后从服务器内建立到远程节点的telnet连接。
与远程系统的直接telnet连接遵循完全相同的路径，通过所有相同的路由器和电路，然而，它是如此迟缓以至于无法使用。为什么明显的差异，以及是什么导致了实质性的改善？
解释是，与服务器建立中间连接意味着有两个独立的 TCP连接，只有它们的有效负载连在一起：我到服务器......服务器到远程系统。这两种连接都以他们自己的方式很糟糕 - 我的调制解调器链路上的高延迟，以及远程链路上的拥塞/数据包丢失（往返时间低得多，但流量超载）。直接连接意味着我有一个TCP连接，在处理过多的延迟时必须从丢包中恢复。建立中间连接意味着我的调制解调器连接所增加的额外延迟不会进一步削弱数据包丢失的恢复，因为数据包丢失仅在连接的第二段处理。
在S3之前使用CloudFront可以反过来解决同样的问题 - 通过将TCP连接拆分为两个独立的连接，在用户最近的位置，提高未知质量连接的响应速度，从而提高吞吐量CloudFront边缘。