我认为您想要的没有完美的答案。一些随机的想法/权衡:
1)切换到HTTPS。这样您就可以忽略嗅探 URL 的人。但是 HTTPS 项目不能在浏览器中缓存很长时间。
2) 如果你要给出签名的 url,不要设置 expires = "time + 10m",而是 "time + 20m and round to most 10m"。这样,URL 将至少保持 10m 不变,并且浏览器可以缓存它们。(请务必在 S3 中的文件上设置 expires: 标头,以便浏览器知道它们可以被缓存。)
3) 你可以代理所有的 URL。让浏览器从您的服务器请求照片,然后编写一个 Web 代理将请求代理到 S3 中的照片。在此过程中,您可以检查用户身份验证,为 S3 生成签名 URL,甚至在本地缓存照片。)这对您来说似乎“效率较低”,但它可以让浏览器尽可能长时间地缓存您的 URL。这对您的用户也很方便,因为他们可以为照片 URL 添加书签,而且它始终有效。即使他们移动到另一台计算机,他们也会访问您的服务器,服务器会要求他们在显示照片之前登录。
确保使用“事件”服务器,例如 Python Twisted 或 Node.js。这样,您可以同时代理数千张照片,而无需在服务器上使用大量内存/CPU。(您将使用大量带宽,因为所有数据都通过您的服务器。但是您可以通过运行多个服务器轻松“扩展”。)
4) Cloudfront 是一个缓存。第一次从 CF 服务器请求资源时,它会更慢(几百毫秒)。但是不要指望第二个请求会被缓存!每个 CF 位置都有大约 20 个不同的服务器,每次你都会随机访问一个。所以请求一张照片 10 次可能会产生 10 次缓存未命中,而你仍然只有 50% 的机会在下一次请求中获得缓存命中。CF 仅对将被请求数百次的流行内容有用。CF 对外国用户有点用处,因为私有 CF-to-S3 连接可以比普通互联网更好。
我不确定您将如何让 CF 为您进行安全检查。但是,如果您通过 S3 身份验证(不是默认设置),那么您可以使用“mod 10 minutes”技巧来制作可以缓存 10 分钟的 URL。
CF 不可能“比浏览器缓存更快”。但如果你不使用浏览器缓存,CF 可能比 S3 更快,但主要是在国外。
看看其他人在做什么(我认为,smugmug 使用 S3。)