Вопрос по обслуживанию изображений в App Engine (2 варианта)

Question

планирует запустить комический сайт, который обслуживает комиксы (изображения). У меня мало опыта в обслуживании / кэшировании изображений.

так вот мои 2 метода, которые я рассматриваю:

1. Использование LinkProperty

class Comic(db.Model)
  image_link = db.LinkProperty()
  timestamp = db.DateTimeProperty(auto_now=True)

Преимущества: Образы извлекаются из самого дискового пространства (а место на диске дешевое, я так понимаю?) Я могу легко настроить app.yaml с датой истечения срока действия для кэширования содержимого в браузере пользователя. Я могу настроить memcache для более быстрого извлечения объектов (для большого трафика)

2. Использование BlobProperty

Я использовал этот урок, он работал довольно аккуратно. http://code.google.com/appengine/articles/images.html

Дополнительный вопрос: могу ли я сказать, что использование BlobProperty своего рода «защищает» мои изображения от внешних связей? Это означает, что люди не могут просто ссылаться прямо на комиксы

У меня есть несколько проблем для метода 2.

• Очевидно, я могу запоминать эти объекты для более быстрого чтения.

Но потом:

• Является ли memcaching изображений хорошей вещью? Мои изображения большие (100-200 КБ на изображение). Я думаю, что memcache позволяет только до 4 ГБ кэшированных данных? Или это 1 Мб на единицу памяти, с неограниченным количеством сущностей ...

• Что делать, если в кэше appengine произошел сбой? -> Решение: мне нужно вернуться в хранилище данных.

• Как мне кэшировать эти изображения в браузере пользователя? Если бы я делал метод нет. 1, я мог бы легко добавить в свой app.yaml дату истечения срока действия для контента, и изображения будут кэшированы на стороне пользователя.

хотел бы услышать ваши мысли. Должен ли я использовать метод 1 или 2? Метод 1 звучит просто и понятно, я должен быть осторожен с этим?

[Изменено] Как решить эту дилемму?

Дилемма: последнее, что я хочу сделать, - это запретить людям получать прямую ссылку на изображение и размещать его на bit.ly, поскольку пользователь автоматически перенаправляется только на изображение на моем сервере. (а не реклама / контент вокруг него, если пользователь получил к нему доступ с самой главной страницы)

Answer 1

Вы будете использовать большую пропускную способность для передачи всех этих изображений с сервера на клиенты (браузеры). Помните, appengine имеет максимальное количество файлов, которое вы можете загрузить, я думаю, что это 1000, но в последнее время оно может увеличиться. И если вы хотите контролировать доступ к файлам, я не думаю, что вы можете использовать опцию № 1.

Вариант № 2 хорош, но ваша пропускная способность и затраты на хранение будут высокими, если у вас много контента. Чтобы решить эту проблему, люди обычно обращаются к сетям доставки контента (CDN). Amazon S3 и edgecast.com - два таких CDN, которые поддерживают URL-адреса доступа на основе токенов. Это означает, что вы можете сгенерировать токен в приложении appengine, подходящий для IP-адреса, времени, географии и некоторых других критериев, а затем передать URL-адрес cdn с этим токеном запрашивающей стороне. CDN обслуживает ваши образы и проверяет доступ на основе токена. Это поможет вам контролировать доступ, но помните, что если есть желание, есть способ, и вы не можете на 100% обезопасить что-либо - но вы, вероятно, подходите достаточно близко.

Таким образом, вместо хранения контента в appengine, вы должны сохранить его на cdn и использовать appengine для создания URL-адресов с токенами, указывающими на контент на cdn.

Вот несколько ссылок о подписанных URL. Я использовал оба из них:

http://jets3t.s3.amazonaws.com/toolkit/code-samples.html#signed-urls

http://www.edgecast.com/edgecast_difference.htm - посмотрите «Защита контента»

Answer 2

С точки зрения решения вашей дилеммы, я думаю, что есть несколько альтернатив:

• Вы можете заставить изображения быть визуализируется в объекте Flash, который будет скачать изображения с вашего сервера в каком-то зашифрованном формате, который он бы знал, как декодировать. Это будет включает в себя довольно много предварительной работы.

• у вас может быть действующая одноразовая ссылка для изображения. Каждый раз, когда ты сгенерировал окружающую веб-страницу, ссылка на изображение будет генерируется случайным образом, и код обслуживания изображений сделает недействительным эта ссылка после разрешения один раз. если ты иметь сайт с высоким трафиком, это было бы очень ресурсоемкая схема.

На самом деле вы хотите подумать, сколько работы стоит заставить людей видеть рекламу, особенно когда значительное количество из них будет приходить на ваш сайт через Firefox, и вы почти ничего не можете сделать, чтобы обойти AdBlock.

С точки зрения выбора между двумя вашими методами, есть несколько вещей, о которых стоит подумать. При первом варианте, где изображения хранятся в виде статических файлов, вы сможете добавлять новые изображения только путем обновления appcfg.py . Поскольку приложение AppEngine не позволяет вам писать в файловую систему, вам нужно будет добавить новые изображения в код разработки и выполнить развертывание кода. Это может быть сложно с точки зрения управления сайтом. Кроме того, обработка изображений из memcache, скорее всего, не даст вам улучшения по сравнению с тем, чтобы они служили статическими файлами.

Ваш второй вариант, размещение изображений в хранилище данных, защищает ваши изображения от связывания только в той степени, в которой вы можете управлять с помощью логики, обслуживаются они или нет. Проблема, с которой вы столкнетесь, заключается в том, что принятие такого решения затруднительно. Помните, что HTTP не имеет состояния, поэтому для поиска способа отличить запрос от ссылки, являющейся внешней по отношению к вашему приложению, и той, которая является внутренней по отношению к вашему приложению, потребуется хитрость.

По моим личным ощущениям, прыгать через обручи, чтобы убедиться, что люди не видят ваши комиксы при просмотре рекламы, - это решить проблему неправильно. Если контент, который вы публикуете, заслуживает защиты, люди все равно будут переходить на ваш веб-сайт, чтобы им пользоваться. Благодаря большому объему трафика, вы будете более чем наверстывать упущенное для тех, кто напрямую ссылается на ваше изображение, что позволяет обойти несколько рекламных показов. Не пытайтесь перехитрить своих потребителей. Доставьте выдающийся контент, и вы заработаете много денег.

Answer 3

Ваш метод № 1 не практичен: вам нужно будет загружать новую версию вашего приложения для каждого нового комикса.

Ваш метод # 2 должен работать нормально. Он не «автоматически» защищает ваши изображения от «горячей ссылки» - они по-прежнему размещаются по URL-адресу, как любое другое изображение, - но вы можете написать любой код в обработчике обслуживания изображений, какой захотите, чтобы попытаться предотвратить злоупотребление.

Третьим вариантом и вариантом # 2 является использование нового API BLOB-объекта . Вместо того, чтобы хранить само изображение в хранилище данных, вы можете сохранить ключ BLOB-объекта, а ваш обработчик изображений просто указывает инфраструктуре магазина BLOB-объектов, какое изображение обслуживать.