Урок 02 — HTTP-протокол. Ошибка 404. Модель TCP/IP. Методы HTTP

Название: Как работает интернет под капотом: HTTP, TCP/IP и методы запросов
Описание: Разбираем, как браузер общается с сервером, что такое HTTP-запрос и ответ, почему появляется ошибка 404, и зачем нужна модель TCP/IP. Изучаем методы HTTP: GET, POST, PUT, PATCH, DELETE.
Почему это важно для QA: HTTP — это язык, на котором разговаривают клиент и сервер. Без его понимания невозможно тестировать API, анализировать сетевые ошибки и писать осмысленные баг-репорты.

1. Что такое HTTP

HTTP (HyperText Transfer Protocol — протокол передачи гипертекста) — это набор правил, по которым клиент и сервер обмениваются сообщениями в интернете.

Представь, что HTTP — это официальный язык переговоров. Клиент и сервер «договорились» общаться именно на нём: в каком формате отправлять запросы, что писать в ответе, какие коды использовать.

HTTPS — это то же самое, но с шифрованием. Буква «S» означает «Secure» (безопасный). Все современные сайты используют HTTPS, потому что данные между клиентом и сервером передаются в зашифрованном виде.

HTTP  → данные передаются в открытом виде (небезопасно)
HTTPS → данные зашифрованы с помощью TLS (безопасно)

2. Модель TCP/IP — «слоёный пирог» интернета

Прежде чем разобраться в HTTP, нужно понять, как данные вообще передаются по сети. Для этого существует модель TCP/IP — набор протоколов, разделённых по уровням ответственности.

Представь слоёный пирог, где каждый слой делает свою работу и не лезет в чужую.

TCP vs UDP

TCP (Transmission Control Protocol) — надёжный протокол:

• Гарантирует доставку всех пакетов
• Пакеты доставляются в правильном порядке
• Если пакет потерялся — отправит снова
• Используется для HTTP, электронной почты, скачивания файлов

UDP (User Datagram Protocol) — быстрый протокол:

• Не гарантирует доставку
• Пакеты могут прийти не по порядку
• Быстрее, чем TCP
• Используется для видеозвонков, онлайн-игр, стриминга

Аналогия:

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

Что это значит для QA

HTTP работает поверх TCP. Это значит, что когда ты тестируешь веб-приложение, под капотом:

1. IP находит адрес сервера и прокладывает маршрут
2. TCP устанавливает соединение и гарантирует доставку данных
3. HTTP передаёт твой запрос и получает ответ

Если тест падает по таймауту — проблема может быть на уровне TCP (нет соединения) или HTTP (сервер не отвечает).

3. Анатомия HTTP-запроса

Когда браузер обращается к серверу, он отправляет HTTP-запрос. Запрос состоит из трёх частей.

1. Стартовая строка (Request Line)

GET /api/users HTTP/1.1

2. Заголовки (Headers)

Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1...
Content-Type: application/json
Accept: application/json

3. Тело запроса (Body) — только для POST/PUT

{
  "name": "Алина",
  "email": "alina@example.com"
}

Стартовая строка содержит три элемента

1. Метод — что мы хотим сделать (GET, POST, PUT, DELETE)
2. Путь — к какому ресурсу обращаемся (/api/users)
3. Версия протокола — HTTP/1.1 или HTTP/2

Важные заголовки запроса

4. Анатомия HTTP-ответа

После обработки запроса сервер отправляет HTTP-ответ:

1. Стартовая строка (Status Line)

HTTP/1.1 200 OK

2. Заголовки (Headers)

Content-Type: application/json
Content-Length: 254
Cache-Control: no-cache
Set-Cookie: session=abc; HttpOnly

3. Тело ответа (Body)

{
  "id": 42,
  "name": "Алина",
  "email": "alina@example.com"
}

5. Коды состояния HTTP — язык ответов сервера

Код состояния — это трёхзначное число в ответе сервера. Оно сразу говорит, что произошло.

Группы кодов

Самые важные коды для QA

2xx — Успешные ответы

3xx — Перенаправления

4xx — Ошибки клиента

5xx — Ошибки сервера

Почему ошибка 404 такая известная

404 Not Found — ресурс не найден. Это значит, что URL, который запросил клиент, не существует на сервере.

Пользователь вводит: https://example.com/page-that-does-not-exist
Сервер отвечает:     HTTP/1.1 404 Not Found
                     {"error": "Page not found"}

Почему именно 404 так знаменита? Потому что пользователи часто её видят: устаревшие ссылки, опечатки в URL, удалённые страницы.

Что проверяет QA:

• Приложение корректно обрабатывает 404: показывает понятную страницу ошибки
• Нет ли неожиданных 404 в рабочих сценариях
• Все ссылки в приложении ведут на существующие страницы

Разница между 401 и 403 (популярный вопрос на интервью)

401 Unauthorized — «Я не знаю, кто ты. Войди сначала.»
403 Forbidden    — «Я знаю, кто ты, но тебе сюда нельзя.»

Пример:

• Ты пытаешься открыть /admin/users без авторизации → 401
• Ты вошёл как обычный пользователь и пытаешься открыть /admin/users → 403

6. Методы HTTP — что мы хотим сделать

Метод HTTP говорит серверу, какое действие нужно выполнить с ресурсом.

Основные методы

GET — получить данные

Запрашивает данные. Не изменяет их на сервере.

GET /api/users          → получить список всех пользователей
GET /api/users/42       → получить пользователя с ID 42
GET /api/products?category=phones → получить товары из категории «телефоны»

Особенности:

• Параметры передаются в URL (?key=value)
• Тело запроса не используется
• Запрос можно повторять — результат одинаковый (идемпотентный)
• Браузер кэширует GET-запросы

POST — создать ресурс

Отправляет данные на сервер для создания нового ресурса.

POST /api/users
Content-Type: application/json

{
  "name": "Алина",
  "email": "alina@example.com",
  "password": "secret123"
}

Особенности:

• Данные передаются в теле запроса
• Создаёт новый ресурс
• Повторный запрос создаёт ещё один новый ресурс (НЕ идемпотентен)
• Сервер обычно возвращает 201 Created и данные нового объекта

PUT — заменить ресурс полностью

Заменяет ресурс целиком. Все поля нужно передать заново.

PUT /api/users/42
Content-Type: application/json

{
  "name": "Алина Иванова",
  "email": "alina.ivanova@example.com",
  "role": "admin"
}

Особенности:

• Заменяет весь ресурс (если поле не передал — оно обнулится)
• Идемпотентен: повторный запрос с теми же данными даст тот же результат

PATCH — обновить частично

Обновляет только указанные поля ресурса.

PATCH /api/users/42
Content-Type: application/json

{
  "name": "Алина Иванова"
}

Только имя обновится, остальные поля останутся без изменений.

DELETE — удалить ресурс

DELETE /api/users/42

Особенности:

• Тело запроса обычно не нужно
• Сервер возвращает 204 No Content или 200 OK
• Идемпотентен: повторный запрос вернёт 404 (уже удалено), но состояние системы не изменится

Сравнительная таблица методов

*PATCH идемпотентен, если сервер реализован правильно.

7. CRUD — универсальная модель операций с данными

В разработке часто используют аббревиатуру CRUD для описания четырёх базовых операций:

Пример: тестируем API пользователей

GET    /api/users        → Список всех пользователей
GET    /api/users/42     → Конкретный пользователь
POST   /api/users        → Создать нового пользователя
PUT    /api/users/42     → Полностью заменить пользователя 42
PATCH  /api/users/42     → Обновить отдельные поля пользователя 42
DELETE /api/users/42     → Удалить пользователя 42

Чеклист QA для CRUD-операций:

• GET возвращает корректные данные
• POST создаёт новый объект с правильными полями
• POST с дублирующимися данными возвращает 409
• POST с неполными данными возвращает 400 или 422
• PUT обновляет все поля
• PATCH обновляет только указанные поля
• DELETE удаляет объект
• GET после DELETE возвращает 404

8. Идемпотентность — важная концепция для тестирования

Идемпотентный запрос — это запрос, который можно повторить несколько раз с одинаковым результатом.

GET /api/users/42
  → Первый раз: {"id": 42, "name": "Алина"}
  → Второй раз: {"id": 42, "name": "Алина"}
  → Сотый раз:  {"id": 42, "name": "Алина"}
  Результат одинаковый — это идемпотентный запрос ✓

POST /api/orders
  → Первый раз:  создан заказ #1001
  → Второй раз:  создан заказ #1002 (новый!)
  → Третий раз:  создан заказ #1003 (ещё один!)
  Каждый раз новый результат — НЕ идемпотентен ✗

Почему это важно для QA:

При тестировании ошибок сети (таймауты, обрывы) клиент может повторить запрос. Если POST не идемпотентен, это может привести к дублированию заказов. Нужно проверять, как приложение обрабатывает повторные запросы.

9. Инструменты разработчика браузера — твой главный инструмент

Вкладка Network в DevTools (F12) позволяет видеть все HTTP-запросы и ответы прямо в браузере.

Что смотреть в Network

Кликни на любой запрос, чтобы увидеть:

• Headers — заголовки запроса и ответа
• Preview — форматированный ответ
• Response — сырой ответ
• Timing — сколько времени занял каждый этап

Пример: находим баг с помощью Network

Пользователь нажал кнопку «Сохранить» — ничего не произошло. Открываем Network:

POST /api/users/42  422 Unprocessable Entity
Response:
{
  "errors": {
    "phone": ["Неверный формат телефона"]
  }
}

Нашли проблему: поле phone не прошло валидацию на сервере, но интерфейс не показал ошибку пользователю. Баг — на стороне фронтенда.

Итоги урока

Практические задания

1. Network Analysis: Открой любой интернет-магазин (wildberries.ru, ozon.ru). Открой DevTools → Network. Добавь товар в корзину. Найди API-запрос, который при этом отправился. Что это за метод? Какой код ответа вернул сервер? Что в теле ответа?

2. Коды ошибок: Пройди квест: найди в браузере ресурс, который вернёт каждый из кодов: 200, 301, 404, 403. Подсказка: многие сайты имеют /admin (403), несуществующие страницы (404), перенаправления со старых URL (301).

3. CRUD-чеклист: Возьми любой публичный API (например, https://jsonplaceholder.typicode.com). Составь полный чеклист тестирования для эндпоинта /posts. Покрой все CRUD-операции. Добавь проверки граничных значений.

4. Идемпотентность: Открой Postman (или любой API-клиент). Сделай POST-запрос к https://jsonplaceholder.typicode.com/posts 3 раза с одинаковыми данными. Что возвращает сервер? Это идемпотентное поведение?

5. Баг-репорт с Network: Намеренно вызови ошибку в любом веб-приложении (отправь форму с неверными данными). Запиши данные из Network-вкладки: URL, метод, код ответа, тело ответа. Напиши баг-репорт, используя эту информацию.

Следующий урок: Урок 03 — URL. IP-адрес и маска подсети. DNS. Кэш и куки