Перейти к содержимому 
Условный HTTP Запросы снижают затраты на передачу данных, гарантируя, что клиент загрузит ресурс полностью только в том случае, если он действительно был изменен с момента последнего запроса. Я покажу, как Проверка кэша с ETag, Last-Modified, If-None-Match, If-Modified-Since и 304 Not Modified работает надежно, а время загрузки заметно сокращается.
Центральные пункты
- Валидация вместо полной загрузки: 304 экономит полосу пропускания и время.
- ETag и Last-Modified работают вместе для чистого контроля.
- Управление кэшем Определяет свежесть, истекает срок годности только добавок.
- Предпосылки например, безопасные процессы записи If-Match.
- Безопасность для конфиденциального содержимого требуется приватное/нехранимое.
Что делают условные запросы в повседневной жизни
Я установил Условный запросы, чтобы задать серверу четкий вопрос: Действительно ли мне нужно передавать новые данные или достаточно моего кэша? Браузер или прокси отправляет условия, сервер проверяет, изменился ли файл, и отвечает сообщением 304 Not Modified без тела. Такая схема позволяет поддерживать HTML, CSS, JavaScript, изображения и ответы API в актуальном состоянии и значительно снижает нагрузку на инфраструктуру. Для активов с большим сроком действия я использую длинные значения max-age и проверяю их актуальность с помощью валидации. Если у вас есть правильные Стратегии управления кэшем позволяет извлечь максимум из кэша без риска получить устаревшее содержимое.
Заголовки, обеспечивающие проверку кэша
Для надежных Кэш-Клиенту нужны четкие сигналы от ответа, чтобы принимать решения. Я использую Cache-Control для свежести и правил, Expires иногда в качестве дополнения, а Last-Modified и ETag - для фактической проверки. Last-Modified обеспечивает время модификации, которое можно быстро проверить, а ETag - идентификатор версии, который также используется для динамического контента. Важно отметить, что no-cache означает проверку перед использованием, а не удаление. Если вы правильно примените эту семантику, вы получите заметно меньший трафик данных, сохранив при этом актуальность содержимого. Содержание.
Последовательность условного запроса без обходных путей
При первом вызове клиент сохраняет файл и значения проверки, такие как ETag или Last-Modified в кэше. Позже срок действия ресурса истекает или требуется новая проверка перед использованием, и клиент отправляет If-None-Match или If-Modified-Since. Сервер сравнивает полученную информацию с текущим статусом и возвращает либо 200 OK с новым телом, либо 304 Not Modified без полезной нагрузки. Клиент продолжает использовать существующую копию и экономит передачу, нагрузку на TLS и время. Этот пинг-понг кажется незаметным, но Эффект на ощущении нагрузки и нагрузке на сервер очевидна.
Прямое сравнение ETag и Last-Modified
Я использую Last-Modified Мне нравится использовать временные метки в качестве быстрой и простой ссылки, но для более тонкого контроля я использую ETags. Временные метки могут достичь своего предела при очень коротких интервалах между изменениями или фальсифицировать динамические результаты. Я создаю ETags из хэшей файлов, версий баз данных или вариантов рендеринга, при этом каждое изменение в содержимом генерирует новый идентификатор. Оба механизма можно комбинировать: Клиент может параллельно отправлять If-None-Match и If-Modified-Since, а сервер выбирает соответствующую проверку. Вот как я обеспечиваю надежность Валидация, что в равной степени относится как к статическим, так и к динамическим ресурсам.
| Критерий | Last-Modified | ETag |
|---|---|---|
| Точность | Второе разрешение, подходящее для файлов | Идентификатор версии для каждого изменения содержимого |
| Динамика | Слабость при частых изменениях, не связанных с файлами | Сильные для API и визуализированного контента |
| Расходы | Низкий, доступен из файловой системы | Низкий или умеренный уровень, генерация в приложении/прокси |
| Конфликты | Возможны отклонения часов | Возможна неправильная настройка слабых/сильных тегов |
Правильные настройки кэширования браузера и API
Для статических активов я использую длинные max-age и сохраняйте по ETag или хэшу имени файла, чтобы обновления распознавались немедленно. Я часто помечаю HTML и API-ответы значком no-cache, чтобы клиент проверял их перед использованием без необходимости каждый раз перезагружать все заново. Я помечаю персонализированные страницы значком private, чтобы общие кэши не выдавали ничего, что было сохранено для других. Ошибки часто вызваны противоречивыми директивами или отсутствием заголовков валидации, которых я избегаю с помощью четких правил. Если вы знаете типичные камни преткновения, вы можете легко их избежать; хорошие примеры этого можно найти в статье о Ловушки заголовков при кэшировании, на которые мне нравится ориентироваться.
Эффективное использование кодов состояния и условий
Я организую Коды состояния Понятно: 200 OK доставляет содержимое, 304 Not Modified подтверждает использование кэша, а 412 Precondition Failed отменяет выполнение условия, если оно не выполнено. Для безопасных операций записи я использую If-Match, чтобы обновления вступали в силу только в том случае, если ETag соответствует ожидаемой версии. Чтение с помощью If-None-Match или If-Modified-Since предотвращает появление лишней полезной нагрузки и обеспечивает синхронизацию клиентов. Последовательное поведение очень важно: Одна и та же конечная точка должна одинаково отвечать на одинаковые предусловия. Для SEO и ботов я обращаю внимание на то, как кэши и краулеры интерпретируют статусные сообщения; хороший обзор Коды состояния HTTP и ползание помогает принимать чистые решения.
Безопасность и защита данных при кэшировании
Я отношусь к чувствительному содержимому с без магазина и тем самым не даю им шанса оказаться в кэше браузера или прокси-сервера. Я помечаю персонализированные страницы с помощью Cache-Control: private и проверяю, что никакие персональные данные не появляются в долгосрочных кэшированных URL. Я разрабатываю ETags нейтрально, не позволяя делать выводы об учетных записях пользователей или внутренних идентификаторах. Я последовательно отключаю все кэширование для просмотра входа в систему и банковских потоков. Если вы сочетаете минимизацию данных, подходящие директивы и чистые заголовки, вы снижаете риск и защищаете свои данные. Конфиденциальность.
Реализация: шаги для сервера и приложения
В начале я отделяю статический динамических ресурсов и решаю, где имеет смысл использовать длительные сроки, а где приоритет отдается проверке. В Nginx, Apache или сервере приложений я настраиваю контроль кэша и активирую last-modified и ETags, причем для динамических конечных точек генерацию ETag я помещаю в приложение. При обработке входящих запросов я оцениваю If-None-Match и If-Modified-Since и отвечаю 304, если условие совпадает. Для операций записи я использую If-Match и возвращаю 412 в случае отклонений, чтобы предотвратить перезапись. Это создает последовательное поведение, которое эффективно использует кэш и в то же время Корректность обеспечивает.
Разумно используйте метрики, тесты и мониторинг
Я проверяю Сеть-вкладка DevTools, чтобы проверить, поступают ли ресурсы из кэша, проверяются ли они или только что загружены. Я отслеживаю статус, возраст, ETags и размер переданного ответа. Под нагрузкой я измеряю задержку, объем передачи и процессор сервера, чтобы увидеть реальный эффект от 304 ответов. Журналы обратного прокси показывают, справляются ли общие кэши со своей задачей и сколько проверок прошло успешно. Я использую эти данные для корректировки max-age, директив управления кэшем и стратегии ETag до тех пор, пока время ответа и Скорость попадания голосовать.
Производительность хостинга: почему условные запросы экономят деньги
Любой 304-Ответ на общий кэш экономит полосу пропускания, снижает накладные расходы на TLS и сокращает время отклика, что особенно важно для множества однотипных запросов. В хостингах с обратными прокси, балансировщиками нагрузки и CDN я добиваюсь наибольшего эффекта, когда четко разрешаю или специально исключаю общий кэш. Меньшая передача часто означает также меньшую стоимость трафика в евро и больший резерв для реальных пиков нагрузки. Пользовательский опыт также улучшается, поскольку повторные просмотры страниц и опросы API отвечают быстрее. Таким образом, я реализую потенциал производительности, который не может обеспечить только модернизация оборудования, и использую существующие Инфраструктура лучше.
Распространенные ошибки и прагматичные решения
Противоречие Заголовок Например, no-cache в паре с expires далеко в будущем запутывают кэши; я устанавливаю четкие правила без дублирования. Отсутствие ETags для динамических конечных точек приводит к ненужной полной загрузке; я добавляю надежный идентификатор и оцениваю, если он не совпадает. Слишком короткие значения max-age растрачивают потенциал редко изменяемых файлов; я растягиваю сроки и все равно защищаю их валидацией. Агрессивное кэширование HTML задерживает видимые изменения; я сочетаю no-cache с ETag и поддерживаю контент в актуальном состоянии. Приняв четкие решения по свежести, валидации и достоверности, я решаю эти проблемы и укрепляю Планируемость.
Используйте Vary в чистом виде и контролируйте представления
Чтобы обеспечить безопасную работу условных запросов в общих кэшах, я обязательно использую правильный Vary. Заголовок определяет, какие заголовки запроса влияют на представление. Типичными примерами являются Принять кодирование (gzip, br), Accept-Language и Принять. Если я предоставляю контент на разных языках, я устанавливаю Vary: Accept-Language, чтобы прокси не передавал немецкую версию в ответ на французский запрос. Для персонализированного контента я намеренно обхожусь без Vary: Cookie и вместо этого использую Контроль кэша: частный, чтобы избежать неконтролируемого взрыва ключей кэша. Для ресурсов, которые предоставляются только при наличии действительной авторизации, я либо использую private, либо обеспечиваю четкое разделение с помощью Vary: Authorisation или Vary в соответствующих заголовках. Последовательность очень важна: выбранный набор параметров Vary должен оставаться стабильным, иначе показатель попадания в кэш и преимущества проверки будут снижаться из-за постоянного создания новых вариантов.
Сильные и слабые ETags, сжатие и равенство байтов
Сильные ETags характеризуют байт за байтом идентичные представления и позволяют проводить точную проверку, в том числе в сочетании с запросами диапазона. Слабые ETags (W/...) сигнализируют только о равенстве содержимого, но не обязательно об идентичности байтов. На практике я использую сильные ETag, если могу сгенерировать уникальный идентификатор для каждого представления (включая сжатие). Как только обратный прокси использует gzip или brotli на лету, я адаптирую генерацию ETag или переключаюсь на слабые ETag, чтобы сервер и клиент по ошибке не считали разные байты одинаковыми. Надежный вариант - создавать ETag из последних байтов доставленного ответа и одновременно использовать Vary: Accept-Encoding должны быть установлены. Это гарантирует, что „gzip“ и „br“ получат каждый свой правильный ETag. Если я не могу обеспечить равенство байтов (например, разные временные метки в HTML), я выбираю слабые ETags, которые все еще позволяют надежные ответы 304 при условии, что смысл страницы не изменился.
Контроль кэша при тонкой настройке: s-maxage, must-revalidate, stale-while-revalidate
Кроме того, max-age Я специально использую более тонкие директивы. s-maxage обращается исключительно Общие кэши (CDN, прокси) и позволяет мне кэшировать там более активно, чем в браузере. must-revalidate заставляет клиентов не использовать просроченный контент эвристически, а всегда проверять его - полезно для критически важных данных. прокси-перепроверка Это обязательство относится именно к общим кэшам. С stale-while-revalidate Я разрешаю временно доставлять немного устаревшую копию, пока проверка выполняется в фоновом режиме; пользователи сразу видят что-то, а при следующем запросе используются свежие метаданные. stale-if-error в качестве страховочной сетки: Если Origin не работает или выдает ошибки, кэшу разрешается доставлять последнюю известную копию в течение определенного времени. Для активов, подвергшихся хэшированию, я сочетаю длинный max-age с неизменяемый, так как имя файла меняется вместе с содержимым, и промежуточные проверки не нужны. Для HTML и API, no-cache плюс валидатор остаются золотым стандартом для обеспечения актуальности и экономии пропускной способности.
Дополнительные условия и методы: HEAD, диапазон и письменные конфликты
Условные запросы не ограничиваются GET. A HEAD-request предоставляет только заголовки и идеально подходит для быстрых проверок без тела. Для больших файлов я использую диапазон-запросы; с If-Range Я слежу за тем, чтобы частичные области отправлялись только в том случае, если ресурс все еще соответствует ожидаемой версии - в противном случае я отвечаю 200 и передаю полное тело. Для операций записи я обеспечиваю согласованность с Если совпало ab: PUT, PATCH или DELETE работают только в том случае, если ETag клиента совпадает с текущей версией; в противном случае я отвечаю 412 Precondition Failed. Там, где я хочу обеспечить соблюдение предварительных условий, например, при работе с ресурсами, подверженными конфликтам, я использую 428 Precondition Required, чтобы заставить клиентов использовать If-Match. Я намеренно выбираю между 409 Conflict и 412: 412 сигнализирует о нарушении предусловий, а 409 подчеркивает конфликты содержимого (например, правила бизнес-логики). Такая ясность облегчает реализацию клиента и позволяет избежать слепых переопределений.
Персонализация, файлы cookie и защита данных на практике
Для персонализированных страниц я отмечаю ответы частный или без магазина. Я избегаю кодирования пользовательских состояний в электронных метках, поскольку такие „индивидуальные“ электронные метки могут невольно превратиться в маркеры слежения. Вместо этого я провожу строгое различие между публичными и приватными представлениями. Я устанавливаю cookies в ключ кэша (Vary: Cookie) только в случае крайней необходимости, потому что они увеличивают количество вариантов и резко снижают процент попаданий. Для авторизованных ответов API я придерживаюсь Контроль кэша: частный и, при необходимости, Vary для формата заголовка Authorisation. Так я гарантирую, что общие кэши не будут случайно делиться конфиденциальными ответами. В приложениях со смешанным контентом (общедоступная базовая основа, персонализированные подразделы) я полагаюсь на фрагментарное кэширование или краевой ESI/SSI, в то время как критически важные части остаются приватными. В результате обеспечивается защита данных без снижения производительности.
Операции: CDN, суррогаты и недействительность
В настройках CDN я комбинирую s-maxage с четкими валидаторами и - если это возможно - используйте специфические для суррогатов директивы для управления краевыми кэшами отдельно от браузера. Повторная валидация снижает нагрузку на Origin, но иногда требуется жесткая валидация (например, исправление безопасности). Тогда я планирую два пути: Очистка кэша с помощью хэшей имен файлов для статических активов и Очистка/Invalidation для HTML и API. Это предотвращает „штормы очистки“ и сохраняет короткое время обновления. Также важно иметь согласованный ключ кэша в CDN (включая хост, путь, параметры запроса и соответствующие заголовки Vary). Для параметров запроса я сознательно различаю семантические (например, ?lang=) и чисто связанные с отслеживанием параметры; последние я игнорирую в ключе кэша, чтобы избежать фрагментации. Таким образом, цепочка из кэша браузера, промежуточного прокси и CDN остается прозрачной и предсказуемой.
304 в деталях: Корректное обновление заголовка и метаданных
Также 304-Ответ содержит важные метаданные. Я передаю Date, Cache-Control, ETag/Last-Modified и - если уместно - Expires и Vary еще раз, чтобы клиент мог обновить записи в своем кэше. Content-Type и Content-Encoding не обязательно должны быть повторены, но могут способствовать ясности. Важно, чтобы 304 не содержал полезной нагрузки body и чтобы я отправлял последовательные валидаторы: Изменение ETag в 304 без изменения представления приводит к путанице. Если скорректировать рекомендации (например, увеличить max-age), клиент сможет принять метаданные без необходимости перезагрузки тела - небольшой рычаг, оказывающий большое влияние на воспринимаемую производительность.
Стратегии тестирования и отладки для чистой проверки
Я специально проверяю следующие пункты в DevTools: из дискового кэша против. из кэш памяти против. перепроверено; Статус 200/304; заголовок Age в ответах из общего кэша; согласованность ETag/Last-Modified и влияние Vary. Для воспроизводимости тестов я временно отключаю кэш браузера или использую приватный режим. На стороне сервера я оцениваю журналы по соотношению 200/304, среднему размеру ответа и загрузке процессора. Предупреждающими сигналами являются, например, многочисленные ответы 200 на ресурсы с короткими интервалами изменения (отсутствующие валидаторы), циклы перепроверки (отклоняющееся время / дрейф часов) или необычно большое количество вариантов на URL (чрезмерное количество вариаций). Я использую нагрузочные тесты, чтобы проверить, как ведут себя s-maxage, stale-while-revalidate и if-none-match под давлением - и настраиваю директивы до тех пор, пока пропускная способность и задержка не сравняются.
Краевые случаи и надежные умолчания
Не на каждом ресурсе есть четкие правила изменения. Я устанавливаю осторожные правила по умолчанию для сгенерированных карт сайта, фидов или приборных панелей: no-cache плюс ETag/Last-Modified. При нестабильном времени между системами я избегаю жестких посекундных сравнений и предпочитаю ETag, не зависящие от временных меток. Если сжатие изменяется (разные уровни gzip), я включаю результат сжатия в генерацию ETag или переключаюсь на слабые ETag. А если клиенты запрашивают без валидаторов, я посылаю четкие сигналы: Либо четкая свежесть (max-age/immutable), либо четкая валидация (no-cache + ETag). Эти надежные настройки по умолчанию гарантируют, что даже неполноценные или неисправные клиенты не вызовут нежелательных пиков нагрузки.
Краткое содержание
Подключение условных запросов Скорость и своевременность за счет того, что клиенты получают полные ресурсы только после изменения содержимого. Я использую контроль кэша для обеспечения свежести, комбинирую last-modified и ETag для надежной проверки и последовательно отвечаю 304, если условия выполнены. Я изолирую персонализированный и конфиденциальный контент с помощью private или no-store, чтобы данные не попадали в общие кэши. Измерения в DevTools, журналы и метрики показывают мне, где я могу сократить сроки или ужесточить логику проверки. Если вы будете думать об этих элементах вместе, вы добьетесь ускорения работы страниц, снижения нагрузки на сервер и rounder Пользовательский опыт без лишней траты данных.
