Урок 03 — URL. IP-адрес и маска подсети. DNS. Кэш и куки

Название: Адреса в интернете: как браузер находит нужный сайт
Описание: Разбираем строение URL, что такое IP-адрес и маска подсети, как работает DNS-система, и зачем нужны кэш и куки. Изучаем практические аспекты тестирования этих механизмов.
Почему это важно для QA: URL, DNS, кэш и куки — это фундамент работы веба. Без их понимания невозможно тестировать редиректы, кэширование, сессии и авторизацию.

1. Анатомия URL

URL (Uniform Resource Locator — унифицированный локатор ресурса) — это адрес конкретного ресурса в интернете. Каждая часть URL несёт смысл.

Полная структура URL

https://api.example.com:8443/users/42/orders?status=active&page=2#section-3

  ^      ^              ^    ^              ^                  ^
  │      │              │    │              │                  │
Схема  Хост            Порт Путь       Параметры            Якорь
       (домен)                    (query string)         (фрагмент)

Разбираем каждый элемент

Схема (Protocol)

https://  →  HTTPS (зашифрованный HTTP)
http://   →  HTTP (незашифрованный)
ftp://    →  FTP (передача файлов)
ws://     →  WebSocket
wss://    →  WebSocket + шифрование

Хост (Host)

Доменное имя или IP-адрес сервера:

api.example.com     →  поддомен api, домен example.com
www.google.com      →  поддомен www, домен google.com
192.168.1.100       →  IP-адрес напрямую
localhost           →  твой локальный компьютер

Порт (Port)

Число, которое указывает, через «какую дверь» зайти на сервере.

https://example.com:443     →  HTTPS (443 — порт по умолчанию, обычно не пишется)
http://example.com:80       →  HTTP (80 — порт по умолчанию)
http://localhost:3000        →  локальный сервер разработки
http://localhost:8080        →  альтернативный порт

Аналогия: Если IP-адрес — это адрес здания, то порт — это номер офиса в этом здании.

Путь (Path)

Указывает на конкретный ресурс на сервере:

/                    →  главная страница
/about               →  страница «О нас»
/api/users           →  эндпоинт списка пользователей
/api/users/42        →  пользователь с ID 42
/files/report.pdf    →  конкретный файл

Query String (параметры запроса)

Передают дополнительные данные в запросе. Начинаются с ?, параметры разделены &:

?status=active              →  один параметр
?status=active&page=2       →  два параметра
?q=playwright+typescript    →  поиск по запросу
?from=2024-01-01&to=2024-12-31  →  диапазон дат

Fragment (якорь / фрагмент)

Ссылка на раздел внутри страницы. Начинается с #. Браузер прокручивает страницу до элемента с этим ID:

Важно: Фрагмент НЕ отправляется на сервер. Это только браузерная навигация.

Кодирование URL (URL Encoding)

URL может содержать только определённые символы. Специальные символы нужно кодировать:

Пробел   →  %20  или  +
&        →  %26
=        →  %3D
?        →  %3F
#        →  %23
/        →  %2F
Кириллица→  %D0%9F%D1%80 (каждый байт кодируется)

Пример:

Исходный запрос: /search?q=Алина Иванова
URL-encoded:     /search?q=%D0%90%D0%BB%D0%B8%D0%BD%D0%B0+%D0%98%D0%B2%D0%B0%D0%BD%D0%BE%D0%B2%D0%B0

Что тестировать в URL:

• Приложение корректно обрабатывает спецсимволы в параметрах
• SQL-инъекции в параметрах (?id=1 OR 1=1)
• Очень длинные URL (ограничение ~2000 символов в некоторых браузерах)
• Кириллические символы в URL

2. IP-адрес — числовой адрес устройства

IP-адрес (Internet Protocol Address) — это уникальный числовой идентификатор устройства в сети.

IPv4

Самый распространённый формат: четыре числа от 0 до 255, разделённые точками:

192.168.1.100   →  устройство в локальной сети
8.8.8.8         →  DNS-сервер Google
127.0.0.1       →  loopback (твой же компьютер, то же что localhost)
0.0.0.0         →  слушать на всех интерфейсах

Визуализация:

192  .  168  .  1  .  100

192 ─ октет (0–255)
168 ─ приватная сеть класса B (номер подсети)
  1 ─ номер подсети
100 ─ номер устройства в подсети

Публичные и приватные IP-адреса

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

• При тестировании на разных средах нужно знать IP-адрес сервера
• localhost и 127.0.0.1 — это одно и то же
• Если приложение работает на 0.0.0.0, к нему могут обращаться другие устройства в сети

Маска подсети

Маска подсети — это число, которое определяет, какая часть IP-адреса — это адрес сети, а какая — адрес устройства.

IP-адрес:      192.168.1.100
Маска:         255.255.255.0  (или /24 в CIDR-нотации)

Адрес сети:    192.168.1.0    (общая часть)
Диапазон:      192.168.1.1 – 192.168.1.254  (254 устройства)
Широковещание: 192.168.1.255

Аналогия:

IP:    192.168 .  1 . 100
Маска: ────────  ───  ───
         Улица    Дом  Квартира

Маска /24 означает: первые 24 бита — адрес сети. Устройства с 192.168.1.x находятся в одной подсети и могут общаться напрямую.

Что тестировать:

• Приложение корректно работает при обращении к разным IP-адресам
• Настройки CORS не блокируют запросы с нужных адресов
• Нет жёстко прописанных IP-адресов в коде вместо доменных имён

IPv6

Новый стандарт с огромным адресным пространством:

IPv4: 192.168.1.100          (4 млрд адресов — заканчиваются)
IPv6: 2001:db8::8a2e:370:7334  (340 ундециллионов адресов)

3. DNS — «телефонная книга» интернета

DNS (Domain Name System — система доменных имён) — это система, которая переводит доменные имена (например, google.com) в IP-адреса (например, 142.250.185.78).

Компьютеры общаются по IP-адресам, но люди запоминают имена. DNS — это посредник.

Как работает DNS-запрос шаг за шагом

Ты вводишь в браузере: https://github.com

Шаг 1: Браузер проверяет собственный кэш
        Был ли я уже на github.com? Знаю ли я его IP?
        → Нет, продолжаем

Шаг 2: Операционная система проверяет файл hosts
        /etc/hosts (Linux/Mac) или C:\Windows\System32\drivers\etc\hosts (Windows)
        → Нет записи, продолжаем

Шаг 3: Запрос к DNS-серверу (обычно выдаётся интернет-провайдером или это 8.8.8.8)
        «Какой IP у github.com?»

Шаг 4: DNS-сервер проверяет свой кэш
        → Нет, обращается к корневым DNS-серверам

Шаг 5: Корневые серверы → Серверы зоны .com → Серверы GitHub
        «github.com → 140.82.121.4»

Шаг 6: DNS-сервер возвращает IP браузеру и кэширует его

Шаг 7: Браузер подключается к 140.82.121.4

Типы DNS-записей

Практика: проверка DNS

# Windows PowerShell
nslookup github.com
Resolve-DnsName github.com

# Ответ:
# Server:  8.8.8.8
# Address: 140.82.121.4

DNS и тестирование

Ситуация 1: Тестирование на staging-окружении

Иногда нужно заставить браузер идти на staging-сервер вместо production. Для этого редактируют файл hosts:

# Файл C:\Windows\System32\drivers\etc\hosts
# Добавляем запись: staging IP → production домен
192.168.100.50   api.myapp.com

Теперь api.myapp.com будет резолвиться в staging IP-адрес только на этой машине.

Ситуация 2: DNS-кэш мешает тестированию

После смены IP-адреса сервера браузер может продолжать ходить на старый адрес из-за кэша. Решение:

# Очистить DNS-кэш в Windows
ipconfig /flushdns

# В Chrome: открыть chrome://net-internals/#dns → Clear host cache

4. Кэш — память для быстрой работы

Кэш (cache) — это временное хранилище данных, которое ускоряет повторные запросы. Вместо того чтобы каждый раз загружать одни и те же данные с сервера, браузер хранит их локально.

Зачем нужен кэш

Без кэша:
  Первый визит:   Браузер → скачал logo.png (50 КБ) → отобразил
  Второй визит:   Браузер → снова скачал logo.png (50 КБ) → отобразил

С кэшем:
  Первый визит:   Браузер → скачал logo.png → сохранил в кэш
  Второй визит:   Браузер → взял logo.png из кэша → отобразил мгновенно

Кэш экономит трафик и ускоряет загрузку страниц.

Уровни кэширования

1. Браузерный кэш
   └─ Хранит: HTML, CSS, JS, изображения, шрифты
   └─ Управляется заголовками HTTP

2. Кэш прокси-сервера
   └─ Промежуточный сервер между клиентом и сервером
   └─ Полезен для корпоративных сетей

3. CDN (Content Delivery Network)
   └─ Кэш на серверах по всему миру
   └─ Пример: Cloudflare, AWS CloudFront

4. Серверный кэш
   └─ Сервер кэширует результаты дорогих запросов к БД
   └─ Redis, Memcached

HTTP-заголовки управления кэшем

Cache-Control

Cache-Control: max-age=3600
  → Кэшировать на 1 час (3600 секунд)

Cache-Control: no-cache
  → Всегда проверять у сервера, не устарел ли кэш

Cache-Control: no-store
  → Никогда не кэшировать (для секретных данных)

Cache-Control: public
  → Можно кэшировать на прокси-серверах

Cache-Control: private
  → Кэшировать только в браузере (не на прокси)

ETag

Первый запрос:
GET /api/users/42
← 200 OK
← ETag: "abc123"
← {"id": 42, "name": "Алина"}

Второй запрос (браузер спрашивает: «данные изменились?»):
GET /api/users/42
→ If-None-Match: "abc123"

← 304 Not Modified  (данные не изменились, тело пустое)
← Браузер использует кэш

Проблемы кэша при тестировании

Проблема 1: Старая версия после деплоя

Ты задеплоил новую версию приложения, но пользователи видят старую. Причина — браузер закэшировал старые JS/CSS файлы.

Решение (для разработчиков):

<!-- Cache busting: добавляем версию к имени файла -->
<script src="/app.js?v=2.1.0"></script>
<!-- или -->
<script src="/app.a3f9c12.js"></script>

Что тестирует QA:

• Новые функции доступны после деплоя без очистки кэша
• Хард-рефреш (Ctrl+Shift+R) показывает актуальную версию

Проблема 2: Кэш мешает воспроизвести баг

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

Решение: Тестируй в режиме инкогнито или с очисткой кэша перед каждым прогоном.

Как отключить кэш в DevTools:

• F12 → Network → поставь галку «Disable cache» (работает только пока DevTools открыты)

5. Куки — персональная «записная книжка» браузера

Куки (cookies) — это небольшие фрагменты данных, которые сервер просит браузер сохранить и передавать при каждом последующем запросе к этому серверу.

Зачем нужны куки

HTTP — это stateless (без состояния) протокол. Каждый запрос независим, сервер «не помнит» предыдущих запросов.

Запрос 1: "Дай мне список товаров"
Ответ 1:  Список товаров

Запрос 2: "Добавь товар в корзину"
Ответ 2:  "Хорошо... но кому? Я не знаю, кто ты!"

Куки решают эту проблему:

Шаг 1: Пользователь входит в аккаунт
  → POST /login
  ← Set-Cookie: session=eyJhbGciOiJIUzI1NiJ9...; HttpOnly; Secure

Шаг 2: Браузер сохраняет куку и отправляет при каждом запросе
  → GET /profile
  → Cookie: session=eyJhbGciOiJIUzI1NiJ9...

Шаг 3: Сервер видит сессионную куку, понимает кто пользователь
  ← 200 OK — персональный профиль

Атрибуты куки

Set-Cookie: name=value; атрибуты

Expires=Thu, 01 Jan 2026 00:00:00 GMT  →  Срок действия (дата)
Max-Age=3600                           →  Срок жизни (в секундах)
Domain=example.com                     →  Для какого домена
Path=/api                              →  Для какого пути на сервере
Secure                                 →  Только по HTTPS
HttpOnly                               →  Недоступна из JavaScript
SameSite=Strict                        →  Не отправлять с других сайтов
SameSite=Lax                           →  Отправлять только при прямом переходе
SameSite=None; Secure                  →  Отправлять всегда (для cross-site)

Почему HttpOnly важен для безопасности

// Без HttpOnly: JavaScript может прочитать куку
document.cookie  // → "session=abc123; user_id=42"

// С HttpOnly: JavaScript не видит куку
document.cookie  // → "" (пусто)

Если злоумышленник внедрил вредоносный JS-код (XSS), он не сможет украсть сессионную куку с флагом HttpOnly.

Что тестирует QA:

• Сессионные куки имеют флаг HttpOnly
• Сессионные куки имеют флаг Secure (только HTTPS)
• После выхода из аккаунта сессионная кука удаляется
• Куки с персональными данными не хранятся дольше необходимого
• Флаг SameSite защищает от CSRF-атак

Типы куки

Куки vs localStorage vs sessionStorage

Что тестировать:

• Данные авторизации: всегда в куках с HttpOnly (не в localStorage!)
• Несекретные настройки: можно в localStorage
• Временные данные формы: sessionStorage

6. Сессии и авторизация — как это работает вместе

Сессионная аутентификация (классический подход)

JWT (JSON Web Token) — современный подход

Структура JWT:

eyJhbGciOiJIUzI1NiJ9 . eyJ1c2VySWQiOjQyfQ . SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
      Header                  Payload                    Signature
   (алгоритм)            (данные: userId)          (подпись для проверки)

Отличие от сессий: сервер не хранит токен — он просто проверяет подпись. Данные находятся в самом токене.

Что тестировать при работе с токенами:

• Просроченный токен не даёт доступа (обычно срок 15-60 минут)
• Неверный токен возвращает 401
• Чужой токен не даёт доступа к чужим данным
• После logout токен становится невалидным (или это невозможно — тогда это баг)

7. Тестирование кэша и куки на практике

Как просматривать куки в DevTools

1. Открой DevTools (F12)
2. Перейди на вкладку Application (Приложение)
3. В левом меню: Storage → Cookies → выбери домен

Здесь видны все куки, их значения, атрибуты и срок действия.

Типичные баги, связанные с куками и кэшем

Баг 1: Пользователь не выходит из аккаунта

Шаги: Войти → Нажать «Выйти» → Нажать «Назад» в браузере
Ожидаемый результат: Перенаправление на страницу входа
Фактический результат: Пользователь остался авторизованным
Причина: Кука сессии не удалена при logout

Баг 2: Кэшированная страница показывает старые данные

Шаги: Обновить профиль → Перейти на другую страницу → Вернуться назад
Ожидаемый результат: Профиль с новыми данными
Фактический результат: Старые данные (из кэша)
Причина: Заголовок Cache-Control не настроен для динамических страниц

Баг 3: Данные одного пользователя видны другому

Шаги: User A входит → User B входит на том же компьютере
Ожидаемый результат: User B видит свои данные
Фактический результат: User B видит данные User A
Причина: Кэш или localStorage не очищены при смене пользователя

Итоги урока

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

1. Разбор URL: Возьми 5 URL из реальных сайтов и разбери каждый по составным частям: схема, хост, порт (если есть), путь, query-параметры, фрагмент.

2. Инспекция куки: Открой любой сайт с авторизацией (например, github.com). Войди в аккаунт. Открой DevTools → Application → Cookies. Найди сессионную куку. Какие у неё атрибуты? Есть ли HttpOnly и Secure?

3. DNS-исследование: Узнай IP-адреса трёх сайтов: google.com, github.com, yandex.ru. Используй команду nslookup в терминале. Затем очисти DNS-кэш и проверь снова.

4. Тест кэша: Открой любой сайт в обычном режиме и в инкогнито. Засеки время загрузки. В DevTools → Network посмотри на столбец «Size» — для закэшированных ресурсов там будет написано «disk cache» или «memory cache». Сколько запросов идёт с кэша?

5. Чеклист безопасности куки: Напиши чеклист для тестирования куки в приложении с авторизацией. Включи проверки: атрибуты безопасности, поведение при logout, истечении срока, смене пользователя.

6. Файл hosts: (Выполнять осторожно) В файл hosts добавь запись 127.0.0.1 test.local. Открой http://test.local в браузере. Что произошло? Теперь удали эту запись. Как это можно использовать при тестировании?

Следующий урок: Урок 04 — Тестирование веб-сервисов. SOAP и XML, REST и JSON