1. Клиент отправляет запросВеб‑страницы, которые вы видите в браузере, — результат диалога между клиентом (браузером) и сервером. Понимание этого диалога помогает лучше разбираться в производительности, безопасности и отладке сайтов. В этой статье мы пошагово разберём, что происходит, когда пользователь открывает страницу, какие типы ответов возвращает сервер и какие заголовки важны.
- Что такое запрос: это HTTP‑сообщение, которое браузер отправляет серверу. В нём указаны метод (GET, POST и т. п.), путь (например, /index.html), заголовки (User‑Agent, Accept, Cookie) и иногда тело (для POST).
- Когда отправляется: при вводе URL, клике по ссылке, отправке формы или срабатывании JavaScript (fetch, XHR).
- Разрешение домена: браузер сначала спрашивает DNS, какой IP‑адрес соответствует домену.
- Установка соединения: затем создаётся TCP‑соединение, часто поверх TLS (HTTPS). Если подключение по HTTPS — происходит рукопожатие TLS и проверка сертификата.
- Веб‑сервер (nginx, Apache, Caddy и т. п.) принимает запрос и либо отдаёт статический файл, либо проксирует запрос в приложение (Node.js, Django, PHP и т. п.).
- Логика приложения может читать базу данных, вызывать внешние сервисы, формировать HTML/JSON и т. д.
- Статусный код: короткая цифра, объясняющая результат:
- 2xx — успех (200 OK, 201 Created).
- 3xx — перенаправление (301, 302).
- 4xx — ошибка клиента (404 Not Found, 403 Forbidden).
- 5xx — ошибка сервера (500 Internal Server Error).
- Content-Type: указывает тип содержимого (text/html, application/json, image/png).
- Content-Length: размер тела.
- Cache-Control / Expires: правила кэширования.
- Set-Cookie: создание или изменение куки.
- Strict-Transport-Security: HSTS (пример: max-age=31536000).
- Permissions-Policy: управление доступом к браузерным фичам.
- CORS‑заголовки (Access-Control-Allow-Origin и т. п.): контролируют доступ с других доменов.
- Тело ответа: HTML, JSON, изображение или другое содержимое.
- Single Page Applications: фронтенд может запрашивать JSON (API) вместо полной HTML‑страницы. Сервер возвращает часто application/json с данными.
- REST и GraphQL: разные подходы к организации API‑запросов и ответов.
- Статусные коды и ошибки: API обычно возвращает 4xx/5xx и JSON с полем ошибки для удобства клиента.
- Клиентское кэширование: заголовки Cache‑Control и ETag помогают браузеру не запрашивать заново неизменившиеся ресурсы
- Прокси и CDN: между пользователем и сервером могут стоять CDN, которые отвечают быстрее и снижают нагрузку на основной сервер.
- Компрессия: gzip или brotli уменьшают размер ответа.
- HSTS (Strict-Transport-Security): заставляет браузер использовать HTTPS.
- Content-Security-Policy (CSP): ограничивает, откуда можно загружать скрипты, стилевые ресурсы и т. д.
- Permissions-Policy: разрешает или запрещает доступ к специфическим функциям браузера (камера, геолокация). Если в заголовке указана нераспознанная функция, браузер её игнорирует и может вывести предупреждение в консоли (пример: Unrecognized feature: 'private-state-token-redemption').
- CORS: правильно настроенные заголовки предотвращают нежелательные кросс‑доменные запросы.
- Просмотр заголовков: используйте DevTools → Network, либо curl -I для проверки.
- Логи сервера: ошибочные 500 коды обычно требуют просмотра логов приложения.
- Сообщения в консоли: браузер может показать предупреждения о заголовках или политике безопасности.
- 200 OK + Content‑Type: text/html — страница загружена.
- 301 Moved Permanently — перенаправление на новый URL.
- 404 Not Found — ресурс не найден.
- 401 Unauthorized / 403 Forbidden — авторизация/доступ запрещены.
- 500 Internal Server Error — ошибка на сервере.
- Всегда указывайте Content‑Type корректно, иначе браузер может неправильно отобразить содержимое.
- Для API используйте семантичные коды статуса и понятные сообщения об ошибках.
- Включите HSTS и CSP для повышения безопасности, но тестируйте осторожно.
- Минимизируйте лишние или экспериментальные директивы в заголовках, чтобы не засорять консоль предупреждениями.
- Для отладки ответов используйте curl, Postman и DevTools одновременно: они дают разный взгляд на проблему.
HTTP/2 200
- Используется протокол HTTP/2 — это современно, даёт мультиплексирование запросов и лучше производительность по сравнению с HTTP/1.1.
- Код 200 означает «OK»: запрос обработан успешно, сервер отдал страницу без ошибок.
date: Sat, 18 Jul 2026 11:02:10 GMT
- server: nginx сообщает, что в качестве веб‑сервера используется nginx.
Это нормальная практика, но иногда Server скрывают или минимизируют (например, Server: nginx без версии или вовсе убирают), чтобы меньше раскрывать информацию о стеке для атакующего.
- date — момент формирования ответа на стороне сервера в формате GMT.
Полезно для отладки, кэширования и логов.
vary: Accept-Encoding
content-type: text/html; charset=UTF-8 — страница отдается как HTML в кодировке UTF‑8.
Это правильно: браузер понимает, что нужно отображать как HTML и какую кодировку использовать.
vary: Accept-Encoding — говорит кэширующим прокси/браузерам, что ответ зависит от заголовка Accept-Encoding (gzip, br и т.д.).
Это важно, если сервер может отдавать сжатую и несжатую версии: кэш будет хранить отдельные варианты для разных значений Accept-Encoding.
cache-control: no-store, no-cache, must-revalidate
pragma: no-cache
Здесь явно настроено отсутствие кэширования:
expires в прошлом (1981 год) — старый способ сказать «эта страница уже давно просрочена, не кэшируй».
cache-control: no-store, no-cache, must-revalidate:
no-store — запрещает вообще хранить ответ в кэше (браузер и промежуточные прокси).
no-cache — при каждом обращении нужно валидировать ресурс у сервера.
must-revalidate — даже если кэш что-то хранит, перед использованием нужно подтвердить у сервера.
pragma: no-cache — устаревший (HTTP/1.0) заголовок, оставленный для совместимости со старыми клиентами.
Такой набор обычно используют для динамических страниц (личный кабинет, корзина и т.п.), где кэширование может привести к показу старых данных. Если это главная/обычная страница сайта, можно подумать об ослаблении этих настроек ради скорости (например, оставить кэширование статики и умный Cache-Control).
expires=Sat, 25 Jul 2026 11:02:10 GMT;
Max-Age=604800;
path=/;
HttpOnly
Разберём по параметрам:
PHPSESSID=... — стандартный идентификатор PHP‑сессии. Он связывает пользователя с его серверной сессией (корзина, авторизация и т.п.).
expires=Sat, 25 Jul 2026 11:02:10 GMT и Max-Age=604800 — срок жизни куки 7 дней (604800 секунд).
То есть сессия будет «долго живущей»: браузер хранит её неделю.
path=/ — кука доступна на всём сайте (для всех путей).
HttpOnly — защита от доступа через JavaScript (document.cookie), снижает риск XSS-атак красть эту куку.
Чего не хватает для безопасности:
Secure — чтобы кука отправлялась только по HTTPS. Сейчас Strict-Transport-Security намекает, что сайт должен быть только по HTTPS, но Secure всё равно желательно ставить.
SameSite — ограничивает отправку куки при кросс‑сайтовых запросах (борьба с CSRF).
Например: SameSite=Lax или SameSite=Strict для более жёсткой защиты.
Хороший вариант мог бы выглядеть так:
Set-Cookie: PHPSESSID=...; Max-Age=604800; path=/; HttpOnly; Secure; SameSite=Lax
strict-transport-security: max-age=31536000;Включён HSTS на 1 год (max-age=31536000 секунд ≈ 365 дней).
Это говорит браузеру: «в течение года этот домен нужно открывать только по HTTPS, любые попытки HTTP переводи на HTTPS автоматически».
Хорошо, что HSTS есть — это защита от атак типа downgrade и некоторых манипуляций с HTTP.
Можно усилить (если весь сайт и все поддомены действительно работают только по HTTPS) так:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Но перед includeSubDomains; preload нужно убедиться, что нет поддоменов, которые должны работать по HTTP, и осознать, что это long‑term обязательство (особенно preload, который заносит домен в списки браузеров).
