Чи варто змінити всю структуру файлів зображень користувачів, щоб скористатися простим кешуванням браузера?

На одному з моїх мобільних сайтів я просто зберігаю зображення профілю мого користувача як "1.jpg" у своїй папці користувача і поступово переходжу звідти на додаткові завантажені фотографії. Це означає, що щоразу, коли вони змінюють свою фотографію профілю, наприклад, ім'я файлу залишається однаковим.

Я хотів скористатися кешуванням зображень, щоб той самий старий малюнок не завантажувався знову і знову при кожному перегляді та перегляді профілю користувача, але в той же час я хочу, щоб браузери моїх користувачів завантажити нову, якщо вона змінилася.

З того, що я читав, здається, що єдиний спосіб по-справжньому зробити це - фактично використовувати випадкові імена файлів і відслідковувати всі ці імена файлів у БД, щоб ви могли встановити кеш, що не закінчується, а останнім часом -змінені фотографії знову витягнуті, оскільки вони мають нове ім'я файлу. Краса того, як я їх структурував дотепер, полягає в тому, що я можу повністю пропустити базу даних та отримати доступ до файлів безпосередньо, оскільки їх розташування передбачувано

Отже, моє запитання: чи варто мені змінити всю файлову структуру мого сайту, а також додати елемент DB, для отримання вічного кешування та автоматичного повторного завантаження при новому завантаженні?

Це величезне завдання, але якщо це буде гідно, я не маю жодних проблем рухатися вперед із цією різкою зміною. Я просто хочу переконатися, що так роблять "великі хлопчики", щоб мені більше ніколи не довелося змінювати структуру файлів.

Дякую.

Одне з часто використовуваних рішень - зробити так, щоб URL-адреси ваших зображень виглядали приблизно так:

http://www.example.com/path/to/images/1.jpg?v=123456

Ось /path/to/images/1.jpgфактичний шлях до URL-адреси зображення, в той час як ?v=123456це лише фіктивний запит, на який вказується кінець URL-адреси. Рядок запиту може бути будь-яким - номером версії, часовою позначкою, хешем вмісту зображення, якщо ви змінюєте його, коли зображення змінюється, і зберігати його таким самим, коли воно не відбувається.

Хитрість полягає в тому, що веб-сервер, коли його попросять подати таку URL-адресу, ігнорує рядок запиту, оскільки URL-адреса насправді вказує на статичний файл. Але для браузера користувача (і до будь-яких проксі-серверів між ними) URL-адреси з різними рядками запитів будуть абсолютно різними, і тому будь-яка зміна рядка запиту змушує браузер перезавантажити файл.

Таким чином, ви можете налаштувати свій веб-сервер для надсилання Expiresта Cache-Controlзаголовків HTTP, щоб дозволити кешоване керування на невизначений час, впевнені, що ви можете змусити перезавантажити, змінивши рядок запиту. Один із способів зробити це, якщо ви використовуєте Apache з mod_expires , - це помістити .htaccessфайл у свою каталог зображень з рядками:

ExpiresActive On
ExpiresDefault "access plus 1 year"

Ця методика використовується багатьма популярними веб-сайтами. Наприклад, якщо ви подивитесь на джерело HTML цієї сторінки, ви побачите, що таблиця стилів для неї завантажується з такої URL-адреси:

http://cdn.sstatic.net/stackoverflow/all.css?v=7cd8ea9d6f1e

Тут, ?v=7cd8ea9d6f1eрядок фіктивних запитів, як я описав вище; Ви можете підтвердити це, змінивши його і побачивши, що він дійсно все одно повертає той самий файл.

Існує кілька способів кешування.

Умовно GET

Якщо ви зберігаєте ці зображення у файловій системі та обслуговуєте їх безпосередньо через веб-сервер, ви, ймовірно, вже використовуєте умовний get . Веб-сервер автоматично використовуватиме метадані файлової системи для встановлення заголовка ETAG, і автоматично відповість "304 не змінено", якщо браузер включає If-Modified-Sinceабо If-Matchesзаголовки у своєму запиті. (Усі браузери будуть.)

У цьому випадку все зображення не подається назад, тому у вас є економія пропускної здатності. Однак GET-запит все одно буде виданий, тому ви все одно матимете накладні та затримки запиту.

Ви можете трохи зменшити кількість запитів за рахунок свіжості кешу, встановивши Cache-Controlзаголовки веб-сервера зі public,max-age=Nзначенням для ваших зображень. Це говорить про те, що кеші можуть зберігати ресурс не більше max-ageсекунд, перш ніж вони повинні перевірити, чи оновлений він.

Однак HTTP визначає лише один спосіб визнання недійсним запису кешу, який може не відповідати семантиці вашої програми: якщо ви відправляєте POST або PUT на URL-адресу, що оновлює фотографію профілю, відповідь із Location: [url of photo]заголовком, а запис у кеші для цього URL буде недійсним.

(Це механізм , який дозволяє кешувати веб - сторінку з коментарями, а потім сторінка примусово перезавантажувати браузер після повідомлень користувача нового коментаря. Браузер буде відповідати до POST /commentз 303 See Otherі Location: /page/with/comment. Зверніть увагу , що це не використовується працювати в Firefox через давню помилку .)

Якщо у вас багато трафіку, такий підхід до кешування чудово.

Зміна URL-адрес

URL - це представлення ресурсу, тому інший спосіб управління кешуванням - це не зміна параметрів кешу для ресурсу, а створення абсолютно нового ресурсу з директивою "кеш назавжди". Це підхід , що «великі хлопчики» за, тому що це дозволяє їм не генерувати НЕ додаткових запитів, зберігаючи їх великої пропускної здатності. Мінус полягає в тому, що це вимагає набагато більше додаткових бухгалтерій.

Для цього є дві загальні методи.

Рядки запиту

Веб-сервери ігнорують рядки запитів під час подання файлу з файлової системи. Кешів, однак, немає: /1.jpg?t=12345і /1.jpg?t=67890це два абсолютно різних, не пов'язаних між собою ресурсів, хоча сервер вважає, що вони однакові.

Отже, одна проста річ, яку ви можете зробити, - додавати часову позначку файлової системи як рядок запиту, коли ви посилаєтесь на ресурс у своєму html та встановлюєте довгий Expiresзаголовок. Потім браузер буде кешувати цей ресурс назавжди і не робити жодних GET, поки рядок запиту не зміниться.

Мінусом є те, що важко або неможливо доручити веб-серверу нової URL-адреси для елемента, якщо ви хочете примусово визнати недійсним кеш. Наприклад, якщо веб-переглядач має кешовану HTML-сторінку з /1.jpg?v=1посиланням, але стаття видалила запис /1.jpg?v=1(можливо, у ньому не вистачає файлу чи пам’яті), він подасть новий запит на /1.jpg?v=1. Якщо тим часом зображення змінилося на /1.jpg?v=2, відповідна відповідь є або:

1. Подайте стару версію файлу. Ви зробите це, якби хотіли, щоб усі ресурси узгоджувались один з одним, як вони були у певний момент часу. Це те, що ви повинні зробити, наприклад, з CSS-файлами, оскільки новий файл css зі старим html-файлом може не працювати належним чином!
2. Перенаправлення на нову версію файлу за допомогою 301 Moved Permanently. Ви зробили б це, якби хотіли, щоб усі ресурси були максимально новими.

І те й інше важко зробити лише з веб-сервером, а це означає, що вам потрібно викликати веб-додаток навіть для запитів зображень, які можуть бути як складнішими, так і більш ресурсомісткими. WebServers є дуже швидко в обслуговуючих файлах, тому накладні витрати веб - додатку , можуть в кінцевому підсумку ковтання пропускної здатності і латентність вигоди.

Імена файлів

Замість додавання рядка запиту ви змінюєте ім'я файлу. Це означає, що легко зберігати декілька версій файлів у файловій системі, але, ймовірно, вам потрібно буде зберігати метадані файлів та робити інший облік даних баз даних, щоб відслідковувати ваші ресурси та їх імена.

читаючи про статус http 304 Not Modified, ви повинні мати можливість відповісти на запит на завантаження з номером 304, і тим самим скажіть серверу використовувати кешовані дані, надіслані на повторне надсилання їх у браузер. і прочитайте це питання /programming/2978496/make-php-page-return-304-not-modified-if-it-hasnt-been-modified