HTTP простыми словами: как браузер разговаривает с сервером

Каждое нажатие на кнопку в браузере превращается в текстовое сообщение серверу. Понимание его устройства превращает «сайт не работает» в точный диагноз.

Клиент и сервер

В вебе всё построено на диалоге двух сторон. Клиент (браузер, мобильное приложение) задаёт вопрос, сервер отвечает. Инициатива всегда у клиента: сервер сам ничего не присылает, пока его не спросили.

HTTP — это правила, по которым составляются вопрос и ответ. Обычный текст с чёткой структурой: что делаем, с чем, какие подробности, какие данные.

Из этого сразу следует практический вывод для тестировщика: всё, что делает интерфейс, можно повторить запросом. И наоборот — то, что запрещено в интерфейсе, может быть разрешено на сервере. Именно там живут самые дорогие дефекты.

Из чего состоит запрос

Часть	Что это	Пример
Метод	Что делаем	GET, POST, PUT, DELETE
Адрес	С чем делаем	/api/orders/10432
Заголовки	Подробности о запросе	Authorization, Content-Type
Тело	Данные	{"qty": 2}

Ответ устроен зеркально: код состояния, заголовки, тело. Всё это целиком видно в DevTools — см. разбор вкладки Network.

Методы и почему это важно

• GET — прочитать. Не меняет состояние, параметры в адресе, кэшируется браузером.
• POST — создать. Данные в теле, не кэшируется, не идемпотентен.
• PUT — заменить целиком. PATCH — изменить часть.
• DELETE — удалить.

Слово «идемпотентность» звучит страшно, а означает простое: повторный одинаковый запрос не меняет результат. GET, PUT и DELETE идемпотентны — можно звать сколько угодно. POST не идемпотентен, и отсюда растёт классический дефект: двойной клик создаёт два заказа.

Заголовки, которые встречаются каждый день

Заголовок	Зачем
Authorization	Токен или логин с паролем
Content-Type	В каком формате тело: JSON, форма, файл
Accept	В каком формате клиент хочет ответ
Cookie	Куки, отправляются автоматически
User-Agent	Кто обращается: браузер, приложение, робот
Cache-Control	Можно ли кэшировать и как долго

Самая частая ошибка при ручной отправке запроса — забыть Content-Type: application/json. Сервер в ответ выдаёт 400 или 415, и кажется, что «Postman не работает».

Коды ответов: первая цифра решает

Группа	Смысл	Кто виноват
2xx	Успех	—
3xx	Перенаправление	—
4xx	Ошибка в запросе	Клиент
5xx	Ошибка на сервере	Сервер

Для быстрой диагностики этого достаточно: увидели 4xx — смотрим, что отправили; увидели 5xx — это дефект на стороне сервера, и его надо заводить всегда. Полный разбор конкретных кодов — в шпаргалке по HTTP.

HTTPS: что меняется

HTTPS — тот же HTTP, но внутри шифрованного канала. Меняется одно: содержимое запросов и ответов нельзя прочитать по пути. Структура, методы и коды остаются прежними.

Что проверять тестировщику: сертификат действителен и не просрочен, весь сайт работает по HTTPS, нет смешанного содержимого (картинки и скрипты по http внутри https-страницы), переход с http на https происходит автоматически.

Что происходит при открытии страницы

Полезно один раз проследить весь путь — дальше многие дефекты становятся объяснимыми.

1. Браузер узнаёт адрес сервера по доменному имени через DNS.
2. Устанавливает соединение и, если это HTTPS, договаривается о шифровании и проверяет сертификат.
3. Отправляет запрос GET / с заголовками.
4. Получает HTML и начинает его разбирать.
5. По ходу разбора шлёт десятки новых запросов: стили, скрипты, шрифты, картинки.
6. Скрипты запускаются и обращаются к API за данными — это и есть те запросы, которые вы фильтруете по Fetch/XHR.

Отсюда понятно, почему страница может «показаться, но не работать»: HTML пришёл, а запрос за данными упал. И почему дефект «долго грузится» бывает не про сервер: сто картинок в полном разрешении грузятся долго при любом бэкенде.

Почему сервер не помнит, кто вы

HTTP не хранит состояние между запросами: каждый запрос для сервера — как первый. Поэтому авторизация передаётся заново каждый раз — в cookie или в заголовке с токеном.

Отсюда целый класс проверок: что происходит, когда токен истёк посреди работы; переживает ли приложение отсутствие cookie; не остаётся ли сессия живой после выхода. Подробнее про хранение — в статье про cookie и localStorage.

Что смотреть в первую очередь при разборе

Когда пользователь говорит «не работает», порядок действий один и тот же и занимает пару минут.

1. Открыть Network и повторить действие — найти запрос, который отвечает за операцию.
2. Посмотреть код: 4xx — смотрим, что отправили; 5xx — дефект сервера, заводим сразу.
3. Открыть Payload: то ли ушло, что показано в интерфейсе.
4. Открыть Response: нет ли ошибки в теле при коде 200.
5. Скопировать как cURL и повторить без интерфейса — так становится понятно, чья это ошибка.

После этих пяти шагов вместо «сайт не работает» у вас готовая формулировка для репорта с методом, адресом, кодом и телом ответа.