На одном из моих мобильных сайтов я просто сохраняю изображения профиля моего пользователя как «1.jpg» в их пользовательской папке и постепенно отправляюсь оттуда за любыми дополнительными фотографиями, которые они загружают. Это означает, что всякий раз, когда они меняют свой профиль, например, имя файла остается неизменным.
Я хотел воспользоваться преимуществами кэширования изображений, чтобы одна и та же старая картинка не загружалась снова и снова при просмотре и повторном просмотре профиля пользователя, но в то же время я хочу, чтобы браузеры моих пользователей скачать новый, если он изменился.
Из того, что я читал, кажется, что единственный способ действительно сделать это - фактически использовать случайные имена файлов и отслеживать все эти имена файлов в БД, так что вы можете установить кэш с неограниченным сроком действия, в то время как в последнее время измененные фотографии снова вытащены, так как у них новое имя файла. Однако прелесть того, как я их структурировал до сих пор, заключается в том, что я могу полностью пропустить базу данных и получить доступ к файлам напрямую, поскольку их местоположение предсказуемо.
Итак, мой вопрос: стоит ли мне менять всю файловую структуру моего сайта, а также добавлять элемент БД, чтобы обеспечить вечное кэширование и автоматическую повторную загрузку при новой загрузке?
Это огромная задача, но если она будет сочтена достойной, у меня не будет проблем с продвижением вперед в этом кардинальном изменении. Я просто хочу убедиться, что именно так "большие мальчики" делают это, чтобы мне больше никогда не приходилось менять структуру файлов.
Спасибо.
Существует несколько способов кэширования.
Условный GET
Если вы храните эти изображения в файловой системе и обслуживаете их непосредственно через веб-сервер, вы, вероятно, уже используете условное получение . Веб-сервер будет автоматически использовать метаданные файловой системы для установки заголовка ETAG и автоматически ответит «304 Not Modified», если браузер включает
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
заголовок. Браузер будет кэшировать этот ресурс навсегда и не делать любые GETs, пока строка запроса не меняется.Недостатком является то, что сложно или невозможно указать веб-серверу новый URL для элемента, если вы хотите принудительно аннулировать кэш. Например, если в браузере есть кэшированная HTML-страница со
/1.jpg?v=1
ссылкой, но в ней произошла очистка записи/1.jpg?v=1
(возможно, ей не хватило места в файле или в памяти), он отправит новый запрос/1.jpg?v=1
. Если за это время изображение изменилось на/1.jpg?v=2
, правильным ответом будет либо:301 Moved Permanently
. Вы бы сделали это, если бы хотели, чтобы все ресурсы были как можно более новыми.И то, и другое сложно сделать только с одним веб-сервером, а это означает, что вам нужно вызывать веб-приложение даже для запросов изображений, что может быть как более сложным, так и более ресурсоемким. Веб-серверы очень быстро обслуживают файлы, поэтому накладные расходы веб-приложения могут в конечном итоге поглотить вашу пропускную способность и увеличить задержки.
Имена файлов
Вместо добавления строки запроса вы меняете имя файла. Это означает, что в файловой системе легко хранить несколько версий файлов, но вам, вероятно, потребуется хранить метаданные файлов и вести другие записи в базе данных, чтобы отслеживать ваши ресурсы и их имена.
источник
прочитав о статусе http
304 Not Modified
, вы должны быть в состоянии ответить на запрос на загрузку с 304 и тем самым сообщить серверу использовать кэшированные данные, вместо того, чтобы отправить их в браузер. и прочитайте этот вопрос /programming/2978496/make-php-page-return-304-not-modified-if-it-hasnt-been-modifiedисточник