2013-06-14 2 views
0

Я создаю сайт фотографии, где пользователи могут загружать фотографию и использовать ее позже. Эти фотографии не являются публичными и частными. Я храню фотографии и миниатюры в S3. В настоящее время реализация, за которой я следую, заключается в том, что когда пользователь приходит на страницу, я обслуживаю подписанные URL-адреса эскизов и загружается с S3 (хотя я также думаю об использовании подписанных URL-адресов из облачного интерфейса).Хранилище изображений в S3 и безопасно работает

Вопросы сейчас:

  • В каждом запросе другой URL подается для каждой миниатюры, поэтому кэш браузера не могут быть использованы. Это заставляет браузер загружать каждое изображение снова, когда пользователь обновляет сайт. Это делает нашу страницу медленной.
  • Это также создает еще одну проблему: если кто-то всматривается в источник и все, он может узнать подписанный URL-адрес фотографий и распространять его другим для просмотра (хотя подписанный URL-адрес всего 10 минут). Мне бы хотелось, чтобы URL-адрес был передан моим приложением, чтобы я мог решить, разрешено ли пользователю или нет.

Пожалуйста, помогите мне с каким подходом, который я должен предпринять, я хочу, чтобы время загрузки страницы было быстрым, а также обслуживало проблему безопасности. Я также хотел бы знать, что работа с облачным браузером будет быстрее, чем кеш браузера (я прочитал его где-нибудь) даже для разных подписанных URL-адресов каждый раз. Не стесняйтесь описать ваш ответ.

+0

Возможная копия [Порция файлов, хранящихся в S3 в экспрессе/nodejs приложение] (https://stackoverflow.com/questions/17516820/обслуживающие файлы сохраненных в-s3-в-экспресс-nodejs-приложение) –

ответ

1

Я не думаю, что есть прекрасный ответ на то, что вы хотите. Некоторые случайные идеи/компромиссы:

1) переход на HTTPS. Таким образом, вы можете игнорировать людей, обнюхивающих URL-адреса. Но элементы HTTPS нельзя кэшировать в браузере очень долго.

2) Если вы выдаете подписанные URL-адреса, не устанавливайте expires = "time + 10m", но делайте «время + 20 м и округлите до ближайшего 10 м». Таким образом, URL-адреса будут постоянными не менее 10 м, и браузер может их кэшировать. (Не забудьте также установить срок действия: заголовки файлов в S3, чтобы браузер знал, что их можно кэшировать.)

3) Вы можете проксировать все URL-адреса. Попросите браузер запросить фотографию с вашего сервера, а затем напишите веб-прокси для проксирования запроса на фотографию в S3. По пути вы можете проверить auth пользователя, создать подписанный URL для S3 и даже кешировать фотографию локально.) Это кажется вам менее эффективным, но позволяет браузеру кэшировать ваши URL-адреса столько, сколько они хотят. Это также удобно для ваших пользователей, поскольку они могут добавлять закладки в URL-адрес, и он всегда работает. Даже если они переходят на другой компьютер, они попадают на ваш сервер, который может попросить их войти в систему, прежде чем показывать фотографию.

Обязательно используйте «evented» сервер, например Python Twisted, или Node.js. Таким образом, вы можете проксировать тысячи фотографий одновременно без использования большого количества памяти/процессора на вашем сервере. (Вы будете использовать большую пропускную способность, поскольку все данные передаются через ваш сервер, но вы можете легко «масштабировать», запустив несколько серверов.)

4) Cloudfront - это кэш. Он будет медленнее (на несколько сотен мс) при первом запросе ресурса с CF-сервера. Но не ожидайте, что второй запрос будет кэширован! Каждое местоположение CF имеет ~ 20 разных серверов, и каждый раз вы попадаете в случайное. Таким образом, запрос на фото 10 раз, скорее всего, приведет к 10 промахам в кеше, и у вас все еще будет только 50% вероятность получить кеш-хит при следующем запросе. CF полезен только для популярного контента, который будет запрашиваться сотни раз. CF несколько полезен для иностранных пользователей, потому что частное соединение CF-to-S3 может быть лучше, чем обычный Интернет.

Я точно не знаю, как бы вы сделали CF для вашей проверки безопасности. Но если вы пройдете через S3 auth (не по умолчанию), тогда вы можете использовать трюк «mod 10 минут», чтобы сделать URL-адреса, которые можно кэшировать в течение 10 минут.

Невозможно, чтобы CF был «быстрее, чем кеш браузера». Но если вы НЕ используете кеш браузера, CF может быть быстрее, чем S3, но в основном в зарубежных точках.

Взгляните на то, что другие люди делают (т.е. SmugMug использует S3, я думаю.)