Как реализовать хранение картинок от пользователя на сервере?

Question

[M L]

Интересует подход с точки зрения безопасности и производительности.
Сначала решил это сделать как в ВК, чтобы адрес картинки был типо:
"example.com/c637820/v637821842/115d2/imageName.jpg"
Интересует здесь, что обозначает именно
1. c637820
2. v637821842
Откуда эти id?
Также очень понравилась реализация на Facebook,
там вообще доступ по определенному токену в get параметре у картинке:
"example.com/v/t1.0-9/283048_103813746439563_31482813_n.jpg?oh=63f4724d166e6e322316283885f15ddc&oe=58D3C4F4"

Получается, что в картинках есть доступ программному коду, что не безопасно.

Answer 1

[Dimonchik]

отсюда
если не в той статье, то точно на сайте есть общий принцип - md5 и распределение по папкам

а если ВК хочешь спалить - то да, последние три цифры совпадают с цифрами в ИД

Answer 2

[T_y_l_e_r]

Исчерпывающий ответ
bablogon.net/view.php?p=151

В социальных сетях файлы разбросаны по разным серверам да еще привязаны к определенному id, поэтому их принцип хранения отличается от односерверной реализации

Comments

[M L]

Картинке хранятся на pp.vk.me, у ВК, что про facebook, не осведомлен скорее всего.
Меня интересует как hash такой сделать

[T_y_l_e_r]

вы наивно думаете что pp.vk.me это 1 сервер?
у них целый дата центр размером с завод
все примитивно
выдача одинаково устроена что в вк что в фб, по адресу .jpg лежит файл php интепретатор настроен на выполнение jpg файлов

[M L]

T_y_l_e_r: ни у того ни у другого нет php. И как это относится к моему вопросу. Я читал HightLoad++ 2012 как устроен ВК поэтому стоит ли?

Answer 3

[Philipp]

Получается, что в картинках есть доступ программному коду, что не безопасно.

В картинках нет доступ к программному коду. Это абсолютный бред.

Что же на самом деле происходит?
Для этого нужно понимать, как работает современная архитектура.

Когда вы запрашиваете картинку, то ваш запрос отправляется на балансировщики (да, их может быть несколько), для выбора ближайшего используется протокол anycast.
Далее балансировщик выбирает ближайший наименее загруженный веб-сервер.
Веб-сервер принимает запрос и разбирает его на компоненты.

Например в вышеприведенном примере, можно увидеть, что запрос выглядит примерно так
"scontent-lga3-1.xx.fbcdn.net/v/t1.0-9/283048_103813746439563_31482813_n.jpg?oh=63f4724d166e6e322316283885f15ddc&oe=58D3C4F4"

scontent-lga3-1 - имя хоста, на котором может храниться изображение. Этот хост является частью сети доставки контента.
v/t1.0-9 - понятно, что это версия, скорее всего версия варианта хранения. Facebook непрерывно развивается, поэтому наверняка имеется процедура миграции между различными версиями хранения данных.

283048_103813746439563_31482813 - уникальный идентификатор изображения, три части которого являются разного рода идентификаторами.
oh - скорее всего object hash - некая цифровая подпись объекта.
oe - object expiration - фейсбучный аналог e-tag, специальный параметр указывающий на устаревание объекта.

Если интересно, как работает хранилище фоток в Фейсбук можете почитать в их блоге https://code.facebook.com/posts/685565858139515/ne...

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

Так вот, после того, как получен идентфикатор изображения и метаданные, система знает, с какого участка файловой системы его можно читать. Дальше все просто, отправить заголовок, считывать данные с диска, отправлять их клиенту.

Итак, с точки зрения производительности, самое напряжное - скорость чтения данных с диска, т.е. обычное I/O, поэтому если вам нужна именно скорость, то надо сфокусироваться на быстром хранилище, т.е. SSD просто обязательно.

Далее нужны соображения по поводу надежности, балансировки, обеспечения безопасности доступа.
Вам нужно понять, что мир не заканчивается на уровне Apache и PHP. Например может быть свой особый модуль для nginx, который будет ходить в базу и проверять доступность объекта и лишь затем считывать его с диска. Т.е. то, что вы видите в адресной строке может не иметь ничего общего с тем, как эти данные фактически хранятся на диске, например они могут лежать в HDFS или GridFS.

В вашем случае с учетом вашего уровня знаний лучше всего воспользоваться проверенными решениями вроде хранения картинок в S3 и отдачи их через Cloudflare c кэшированием, например так
https://habrahabr.ru/post/245165/
или так https://habrahabr.ru/company/io/blog/257533/

Comments

[M L]

с помощью чего проверяется цифровая подпись?

[M L]

Если файл заканчивается на .jpg, а далее идет get параметр, без которого доступ к серверу пропадает.

[M L]

Чисто теоретически я могу разрешить доступ интерпретатору ко всем файлам. Тогда он будет сначала проверять url адрес, а потом в случае успеха выдавать картинку.

[M L]

Или же выдавать 403 ошибку.

[Philipp]

staffID: Цифровая подпись проверяется сервером, а не конкретным файлом. Вы не понимаете как работает веб-сервер.
Смотрите, сначала ваш запрос попадает в веб-сервер, веб-сервер его разбирает на составные части, делает необходимые модификации в адресе (рерайты), затем может передавать управление модулям, которые тоже могут что-то делать с запросом. Просто смысл в том, что то, как выглядит адрес может не иметь ничего общего с тем, как он хранится. Плюс большие компании могут позволить доработать существующий веб-сервер так, чтобы он служил их целям.

Например в вашем случае путь к картинке может выглядеть так: `//server.tld/image-specific-session/pictureId.ext`, вы можете передавать этот адрес php скрипту, который проверит, если у пользователя с сессией доступ к картинке и потом прочитать тело картинки из каталога, доступ к которому ограничен.