背景知识
碰巧的是，我需要在某个地方存储超过1.5tb的数据，甚至还提供普通用户通过直接链接下载它们的功能。 由于传统上这类内存已由VDS占用，因此“无所事事”类别的租金成本并没有投入到项目预算中，从源数据来看，我有一个VPS 400GB SSD，在没有无损压缩的情况下，我无法放置1.5TB的图像会成功。
然后我记得，如果您从Google磁盘上删除垃圾，例如仅在Windows XP上运行的程序，以及由于Internet不够快速和完全而在其他媒体之间徘徊的其他内容。不是无限的（例如，虚拟盒子的10-20个版本除了具有怀旧性之外，几乎没有其他价值），那么所有内容都应该非常合适。 言归正传。 因此，通过限制对api的请求数量（顺便说一句，没有问题的技术支持，每位用户的请求配额在100秒内增加到10,000个），数据迅速流到了进一步部署的地方。
一切似乎都很好，但现在需要将其传达给最终用户。 而且，无需任何重定向到该处的其他资源，因此一个人只需单击“下载”按钮，即可成为该珍贵文件的幸运所有者。
然后，我很高兴地以各种严肃的方式出发。 最初，它是AmPHP上的脚本，但是我对其创建的负载不满意（启动时急剧上升到内核消耗的100％）。 然后，ReactPHP的curl包装器开始起作用，这完全符合我对消耗的CPU时钟周期数的期望，但是它并没有提供我想要的速度（事实证明，您可以简单地减少调用间隔curl_multi_select，但是对于第一个选项，我们具有相同的贪婪性） 我什至试图用Rust编写一个小型服务，它运行起来非常快（甚至令人惊讶的是，据我所知），但是我想要更多，定制它并不容易。 此外，所有这些解决方案都以某种方式奇怪地缓冲了答案，我想追踪最高精度的文件下载结束的时间。
总的来说，有一段时间它是歪斜的，但是确实有效。 直到有一天，我才有了一个奇妙的妄想念头：从理论上讲，nginx可以完成我想要的事情，它运行迅速，甚至允许配置进行各种变态。 我们必须尝试-如果解决了怎么办？ 经过半天的持续搜索，一个解决方案可以稳定运行几个月，满足我的所有要求。
定制NGINX
在剧透下方可以看到一个简短的无评论版本 location ~* ^/google_drive/(.+)$ { internal; limit_rate 1m; resolver 8.8.8.8; set $download_url https://www.googleapis.com/drive/v3/files/$upstream_http_file_id?alt=media; set $content_disposition 'attachment; filename="$upstream_http_filename"'; proxy_max_temp_file_size 0; proxy_set_header Authorization 'Bearer $1'; proxy_pass $download_url; add_header Content-Disposition $content_disposition; proxy_hide_header Content-Disposition; proxy_hide_header Alt-Svc; proxy_hide_header Expires; proxy_hide_header Cache-Control; proxy_hide_header Vary; proxy_hide_header X-Goog-Hash; proxy_hide_header X-GUploader-UploadID; }
编写脚本来管理所有这些幸福
该示例将使用PHP编写，并故意使用最少的主体工具包编写。 我认为所有使用其他语言的人都可以使用我的示例来整合本文。
<?php
总结
通常，此方法使从任何云存储组织向用户的文件分发变得相当容易。 是的，即使通过电报或VK也是如此（前提是文件大小不超过该存储库的允许大小）。 我有一个类似的想法，但是不幸的是，我遇到的文件最大为2GB，而我还没有找到一种方法或模块来粘贴上游的答案，为此项目写一些包装很费力。
谢谢您的关注。 我希望我的故事至少对您有意思或有用。