谷歌云存储媒体签名Url

Answer 1

经过更多的研究，我得出以下结论：

我的第一次计算是使用Google的gsutil工具完成的，它在计算带签名的URL散列时似乎引入了很多开销，例如：

gsutil代码：

gsutil signurl -d 60m /path/to/google.p12 gs://bucket/file

function storageURL($bucket,$archivo) {
    $expires = time()+60; 
    $to_sign = ("GET\n\n\n".$expires."\n/".$bucket.'/'.$archivo);
    $fp = fopen('/path/to/google.pem', 'r');
    $priv_key = fread($fp, 8192);
    fclose($fp);
    $pkeyid = openssl_get_privatekey($priv_key);
    if(!openssl_sign($to_sign,$signature,$pkeyid,'sha256')) {
        $signature = 'sinfirma';
    } else {
        $signature = urlencode(base64_encode($signature));
    }
    return ('https://'.$bucket.'.storage.googleapis.com/'.$archivo.'?GoogleAccessId=[e-mail]&Expires='.$expires.'&Signature='.$signature);
}

这看起来很好，因为用户习惯于更长的视频的更长的“加载”或“缓冲”时间，所以当视频更长时，0.5-1.5秒的额外时间不会对可用性造成太大影响。

另外，在当前状态下，服务器上目前有689个视频，总共有864,138个相关的.ts和.AAC文件，每个视频有6个m3u8s(180,360,480,720,108,AAC）加上一个用于主播放列表的额外m3u8...因此，为所有视频生成每小时的url需要(689[master m3u8]+864,138[assets]+4134[qual m3u8])868,961次PHP代码迭代，总运行时间为467.15262699127(~7分钟），这是可以管理的，但考虑到动态生成每个url的运行时间，这是没有意义的。

这一切都是使用Google Compute n1-highmem-2实例，它没有那么强大，所以切换到一台更强大的机器将使这一切变得更快。

但所有这些都带来了另一个维度，因为谷歌（和所有其他公司一样）对每个桶的每次PUT操作收费，所以成本计算是合适的。看看我们上个月的统计数据，我看到总共有447,103个视频播放（嘿，这是一个小网站），在提议的方案下，每个视频点击将产生7次PUT操作（6比特率m3u8+1主m3u8)，当月总共有3,129,721次额外的PUT操作，计算成本(3129721/10000*0.01)给我的数字是3.13美元的额外成本...很小，但如果网站变得更受欢迎，可能会成为一个问题。另一个解决方案（每个人每小时签名的URLs）将产生((689[master m3u8]+4134[qual m3u8])*24[gens]*30[每月])3,472,560个额外的put...大致相同，所以我在这两个方案之间进行选择时处于或接近盈亏平衡点（成本方面）。我必须在这里做更多的数字，使用前几个月的数据，以得到一个更好的想法，因为一个方案（每次点击的URL）取决于用户的数量，另一个方案（全局URL生成）取决于视频的数量...它们以完全不同的方式缩放。

本质上，使用本机代码，问题似乎纯粹是金钱上的，只需要一个小的编码矢量（重写视频播放代码还是引入每小时的URL生成）。在做出最终决定之前，两者都需要进行审视和比较。

不过，云存储API中的一个新ACL（比如以m3u8为有效负载的媒体部分文件）可以绑定到m3u8上，这将使一切都变得更加顺利...我有什么地方可以向谷歌存储团队提出这个建议吗？

--30/10编辑：最终解决方案--

这是我想出的最终解决方案，到目前为止似乎效果很好。

设置：

这个bucket应用了一个默认的ACL，它使所有文件都是私有的，但用于生成签名URL的Google ID可以访问这些文件。

因此，单个视频有以下文件：

SERVER/nginx/mp4/uniqid/uniqid.m3u8
SERVER/nginx/mp4/uniqid/180p/stream.m3u8
SERVER/nginx/mp4/uniqid/360p/stream.m3u8
SERVER/nginx/mp4/uniqid/480p/stream.m3u8
SERVER/nginx/mp4/uniqid/720p/stream.m3u8
SERVER/nginx/mp4/uniqid/1080p/stream.m3u8
SERVER/nginx/mp4/uniqid/audio/stream.m3u8

GS/bucketmp4/uniqid/180p/segment##.ts
GS/bucketmp4/uniqid/360p/segment##.ts
GS/bucketmp4/uniqid/480p/segment##.ts
GS/bucketmp4/uniqid/720p/segment##.ts
GS/bucketmp4/uniqid/1080p/segment##.ts
GS/bucketmp4/uniqid/audio/segment##.aac

（所以似乎认为这是代码，不让我格式化它）

这样，对GS的写入只做一次，而且，由于所有客户机都认为他们接收的是普通的m3u8文件，所以不需要在客户端进行黑客攻击。