Кеширование — одна из старейших функций прокси: вместо того чтобы снова и снова скачивать один и тот же контент, сохраняется его копия, и последующие запросы обслуживаются локально. С распространением HTTPS охват этой функции сузился, но она не исчезла полностью — и в вашем собственном конвейере сбора данных она по-прежнему серьёзный источник экономии.
Базовый поток
При попадании в кеш обращения к серверу-источнику не происходит вовсе. Это выигрыш и в скорости, и в полосе пропускания, и в нагрузке на целевой сервер.
Кто определяет, что будет сохранено?
Решение принимает сервер и сообщает об этом Cache-Control заголовком:
| Директива | Значение (смысл) | Поведение прокси |
|---|---|---|
public | Общий кеш может сохранять | Сохраняет |
private | Пусть сохраняет только браузер | Не сохраняет |
no-store | Не сохранять вовсе | Не сохраняет |
no-cache | Можно сохранять, но проверять при каждом использовании | Выполняет условный запрос |
max-age=3600 | Считается свежим 3600 секунд | В течение этого срока к источнику не обращается |
s-maxage=600 | Отдельный срок для общего кеша | Имеет приоритет над этим значением |
no-cache, не означает «не сохранять вовсе» — она означает «сохраняй, но перед использованием проверяй». Эквивалент «не сохранять вовсе» — no-store.
Условные запросы: 304 Not Modified
Когда копия в кеше устаревает, прокси не обязан скачивать содержимое заново. Он спрашивает сервер: «актуальна ли ещё имеющаяся у меня версия?»:
Ответ 304 не содержит тела; возвращаются только заголовки. Это означает сокращение страницы объёмом 500 КБ до 300 байт.
Использование этого механизма в вашем собственном конвейере сбора данных стоимость полосы пропускания заметно снижает.
Как HTTPS повлиял на кеширование?
Когда установлен туннель CONNECT, прокси не видит содержимого — а значит, и не может его кешировать. Поскольку практически весь веб перешёл на HTTPS, классическое кеширование на прокси во многом перестало работать.
Поэтому современное кеширование ушло с уровня прокси на уровень CDN и клиента.
Разворачиваем собственный кеш
Если кеширование на прокси недоступно, тот же выигрыш можно получить в собственном приложении. В конвейерах сбора данных это очень эффективно:
Этот простой слой избавляет вас от повторного скачивания редко меняющихся страниц. На ресурсах с тарификацией по GB, таких как резидентные прокси, экономия напрямую отражается на счёте.
Когда кеширование неуместно?
Кеш подходит
- Редко меняющиеся страницы товаров и категорий.
- Статические справочные данные.
- Задачи, где одна и та же страница забирается несколько раз в течение дня.
- Этап разработки и тестирования (бережёт квоту).
Кеш неуместен
- Отслеживание цен и наличия в реальном времени.
- Персонализированный контент.
- Страницы, требующие сессии.
- SEO-задачи, отслеживающие изменения позиций.
Работа с устаревшими кешированными данными может дать результаты хуже, чем полное отсутствие сбора данных. В чувствительных ко времени областях, таких как цены и наличие, задавайте очень короткий срок кеша или не используйте кеш вовсе.
Резюме
Кеширование на прокси в классическом понимании во многом утратило смысл с распространением HTTPS, поскольку в туннеле CONNECT прокси не видит содержимого. Тем не менее выстроить ту же логику на уровне собственного приложения по-прежнему возможно и очень полезно. Условные запросы на основе ETag убирают почти весь трафик на редко меняющемся контенте. А для чувствительных ко времени данных кеша следует избегать. Для расчёта потребления к нашей статье о полосе пропускания можно посмотреть.