Comments 25
Я использовал такую систему и не раз в разных проектах, только хеши не применял. Так в чем изюминка статьи?
Ну… Давайте же поддержим Mail.ru бурными аплодисментами ))
А как насчет возможного совпадения хешей для разных URL или тел изображений? Или я один из немногих, у кого паранойя по этому поводу?
Это может случиться, но, я думаю, это слишком редкая ситуация в реальном мире. А если уже совсем хочется перестраховаться, можно хешировать двумя алгоритмами(например md5+sha1) и, соответственно, сохранять два хеша.
Всем, кто боится коллизий в md5:
1) 2 ^ 128 это ОЧЕНЬ БОЛЬШОЕ ЧИСЛО. Количество элементарных частиц во Вселенной меньше.
2) найденные коллизии, которых все боятся — это результат кропотливого подбора параметров с глубоким пониманием алгоритма MD5, а не просто «вдруг совпало».
Поэтому вероятность найти коллизию у двух файлов, или урлов, или любых других данных произвольно взятых из WWW не просто мала, а охренеть как мала. Если не использовать специализированные алгоритмы подбора для нахождения коллизий до конца существования человеческой цивилизации можно не волноваться.
Проблема коллизий в md5 на самом деле в другом — если у вас УЖЕ ЕСТЬ фиксированное сообщение, от которого считается хеш, то тогда возможно нахождение коллизии. Но для этого нужно очень сильно потрудиться.
1) 2 ^ 128 это ОЧЕНЬ БОЛЬШОЕ ЧИСЛО. Количество элементарных частиц во Вселенной меньше.
2) найденные коллизии, которых все боятся — это результат кропотливого подбора параметров с глубоким пониманием алгоритма MD5, а не просто «вдруг совпало».
Поэтому вероятность найти коллизию у двух файлов, или урлов, или любых других данных произвольно взятых из WWW не просто мала, а охренеть как мала. Если не использовать специализированные алгоритмы подбора для нахождения коллизий до конца существования человеческой цивилизации можно не волноваться.
Проблема коллизий в md5 на самом деле в другом — если у вас УЖЕ ЕСТЬ фиксированное сообщение, от которого считается хеш, то тогда возможно нахождение коллизии. Но для этого нужно очень сильно потрудиться.
Если что-то плохое может произойти, то оно обязательно произойдет :)
Любой алгоритм хеширования будет иметь колизии, так как из нескончаемого множества сообщений получается вполне конечное множество хешей.
Но алгоритм хеширования считается стойким если никому не удалось найти два разных сообщения с одинаковым хешом.
md5 — считается не стойким, уже найдено много разных сообщений с одинаковыми хешами.
sha1 — не могу точно утверждать, но помоему пары находились
sha256 — еще не найдено колизий.
Используйте sha256, а найденая колизия — большая удача, переведт алгоритм в категорию не стойких.
Но алгоритм хеширования считается стойким если никому не удалось найти два разных сообщения с одинаковым хешом.
md5 — считается не стойким, уже найдено много разных сообщений с одинаковыми хешами.
sha1 — не могу точно утверждать, но помоему пары находились
sha256 — еще не найдено колизий.
Используйте sha256, а найденая колизия — большая удача, переведт алгоритм в категорию не стойких.
Я не утверждаю, что md5 является стойким алгоритмом. Еще раз повторяю, если есть готовое сообщение (файл) то намеренно подобрать другое сообщение(файл) с тем же md5 реально. Для решения задач обеспечения безопасности md5 сейчас действительно недостаточно.
Но для данной задачи его более чем достаточно. Самое худшее развитие в случае коллизии — фотография не загрузится, а будет использоваться другая, загруженная ранее. Можно вполне смириться с этим.
Плюс sha256 еще и медленнее md5 (вроде в несколько раз)
Но для данной задачи его более чем достаточно. Самое худшее развитие в случае коллизии — фотография не загрузится, а будет использоваться другая, загруженная ранее. Можно вполне смириться с этим.
Плюс sha256 еще и медленнее md5 (вроде в несколько раз)
По чистке фото можно так:
1. Определяем сколько хранятся фото. Пусть три месяца.
2. Находим все фото старше трех месяцев.
3. Если фото устарело — удаляем. Если нет — делаем touch и забываем о нём на три месяца.
Таким образом при каждой чистке нужно смотреть только те фото, которые вот-вот стали старше трех месяцев, а не все подряд.
1. Определяем сколько хранятся фото. Пусть три месяца.
2. Находим все фото старше трех месяцев.
3. Если фото устарело — удаляем. Если нет — делаем touch и забываем о нём на три месяца.
Таким образом при каждой чистке нужно смотреть только те фото, которые вот-вот стали старше трех месяцев, а не все подряд.
Мне вот что интересно, какова вероятность загрузки той же фотки?
Можно же смотреть на хеши и цеплять уже загруженную, вместо crop/resize/etc
Или это экономия на спичках?
Можно же смотреть на хеши и цеплять уже загруженную, вместо crop/resize/etc
Или это экономия на спичках?
Не ожидал такой простой темы от mail.ru. А расскажете как храните ресайзы? Я в данный момент храню картинки в папках ceil(id/10000), а ресайзы в подпапках, что не совсем удобно.
Это разумный комментарий, плюсанул его, действительно тема очень простая.
Тем не менее у многих знакомых на проектах такая схема не используется, т.к. эта задача очень часто решается в лоб. Еще раз повторяю, это простое решение, я и не претендовал за представление нового супер-алгоритма
Тем не менее у многих знакомых на проектах такая схема не используется, т.к. эта задача очень часто решается в лоб. Еще раз повторяю, это простое решение, я и не претендовал за представление нового супер-алгоритма
Ресайзы мы храним просто набором файлов с соотв. постфиксами, типа
/a7/b8/a7b8a284fb75cf4c41913679b5b56a9b_530x240.jpg
/a7/b8/a7b8a284fb75cf4c41913679b5b56a9b_200x100.jpg
и т.п.
Так удобнее для формирования урлов, чистки и переезда на новые схемы. Мы храним лишь несколько базовых размеров, а все остальные (всего у нас около десятка) ресайзим на лету, используя ближайший подходящий размер и nginx.
Кстати, возможно, скоро парни напишут про результаты исследования нескольких алгоритмов ресайза и их слепое тестирование на дизайнерах, думаю будет интересно.
/a7/b8/a7b8a284fb75cf4c41913679b5b56a9b_530x240.jpg
/a7/b8/a7b8a284fb75cf4c41913679b5b56a9b_200x100.jpg
и т.п.
Так удобнее для формирования урлов, чистки и переезда на новые схемы. Мы храним лишь несколько базовых размеров, а все остальные (всего у нас около десятка) ресайзим на лету, используя ближайший подходящий размер и nginx.
Кстати, возможно, скоро парни напишут про результаты исследования нескольких алгоритмов ресайза и их слепое тестирование на дизайнерах, думаю будет интересно.
Для фотографий более приятный результат получается с небольшим добавлением шарпинга после ресайза
У нас для данной задачи время обработки фотографии один из важнейших параметров. А дополнительные фильтры сразу увеличивают время обработки в разы. Когда писали краулер, пробовали несколько вариантов, в т.ч. и с sharpen, но как то не удалось подобрать комбинацию, удовлетворяющую нас по скорости и качеству, по моему дело было в артефактах, которые иногда давал sharpen. Поэтому мы ограничиваемя только ресайзом
Спасибо за ответ. Часто встречаю такой способ хранения, но почему то забыл о нем, когда писал модель. Возможно, это хороший способ, но разве такой способ позволяет избежать хранение более 10000 файлов в одной директории?
Можно body_hash фотки считать на клиенте и не загружать фотку на сервер, если она уже там есть.
Мы использовали стандартный загрузчик фоток, и не стали копать в эту сторону, а мысль очень здравая, спасибо.
не секьюрно получается. легким движением руки можно проверить есть ли фотография в сервисе.
У нас были полностью публичные картинки, распространять которые собственно и являлось основной задачей сайта :) Можно, наверное, прятать оригинал фотки, и выкладывать обработанную версию, хешировать тоже по ней (с пострипанным EXIF-ом, заресайзенную, с нашим водяным знаком, тогда одним движением не получится — проверящему придется сделать нужную обработку собственной фотки.
Sign up to leave a comment.
Простые решения. Прокачиваем картинки