Модель OSI

Модель взаимодействия открытых систем (OSI) — это концептуальная структура, которая разделяет сетевую коммуникацию на семь отдельных уровней. Для QA-инженеров эта модель предоставляет системный способ диагностировать, где возникают сетевые проблемы — вместо «не работает» вы можете точно указать уровень, вызывающий сбой.

Представьте модель OSI как почтовую систему. Когда вы отправляете письмо, оно проходит несколько этапов: вы пишете содержание (Прикладной), кладёте в конверт с адресом (Представления/Сеансовый), почта маршрутизирует его (Транспортный/Сетевой), почтовый грузовик доставляет (Канальный), а физическая дорога несёт грузовик (Физический). У каждого уровня своя задача.

Уровень 7: Прикладной

Уровень, ближайший к пользователю. Протоколы HTTP, HTTPS, FTP, SMTP и DNS работают здесь. Когда вы получаете 404 Not Found или 500 Internal Server Error, вы имеете дело с проблемой прикладного уровня.

Значение для QA: API-тестирование, веб-тестирование и большинство функционального тестирования происходят на этом уровне.

Уровень 6: Представления

Отвечает за форматирование данных, шифрование и сжатие. SSL/TLS-шифрование работает на этом уровне. Проблемы с кодировкой символов (UTF-8 vs. ASCII) — это проблемы уровня представления.

Значение для QA: Баги кодировки, ошибки SSL-сертификатов, несовпадения форматов данных.

Уровень 5: Сеансовый

Управляет сессиями между приложениями — установка, поддержание и завершение соединений. Токены сессий и сессии аутентификации относятся к этому уровню.

Значение для QA: Тестирование таймаута сессии, сохранение сессии между балансировщиками нагрузки.

Уровень 4: Транспортный

Обеспечивает сквозную коммуникацию между процессами. TCP и UDP — основные протоколы. Номера портов находятся здесь. Ошибки «Connection refused» и «connection timeout» возникают на этом уровне.

Значение для QA: Проблемы с подключением, доступность портов, настройки таймаутов.

Уровень 3: Сетевой

Управляет логической адресацией (IP-адреса) и маршрутизацией. Ping и traceroute работают здесь. «Destination unreachable» и ошибки маршрутизации — проблемы сетевого уровня.

Значение для QA: IP-связность, разрешение DNS (частично), проблемы сетевой маршрутизации.

Уровень 2: Канальный

Управляет физической адресацией (MAC-адреса) и доставкой фреймов в локальной сети. Ethernet и WiFi работают здесь.

Значение для QA: Проблемы WiFi-связности при мобильном тестировании, проблемы сетевых коммутаторов.

Уровень 1: Физический

Реальное оборудование — кабели, беспроводные сигналы, сетевые карты. Сила сигнала и проблемы физического подключения находятся здесь.

Значение для QA: Редко напрямую актуально, но важно при тестировании в аппаратных средах или IoT.

Модель TCP/IP

Если модель OSI — теоретическая основа, то модель TCP/IP отражает реальную работу интернета. Она сокращает семь уровней OSI до четырёх практических:

Уровень TCP/IPУровни OSIКлючевые протоколы
Прикладной7, 6, 5HTTP, DNS, FTP, SMTP
Транспортный4TCP, UDP
Межсетевой3IP, ICMP
Доступа к сети2, 1Ethernet, WiFi

Модель TCP/IP — это то, что работает в каждой сети, с которой вы взаимодействуете. При отладке реальных проблем вы будете чаще встречать терминологию TCP/IP, чем OSI. Однако модель OSI обеспечивает более тонкую детализацию, полезную при объяснении проблем сетевым инженерам.

Ключевое различие: OSI — это справочная модель для понимания; TCP/IP — это реализация, которая приводит в действие интернет. Обе ценны для QA-инженеров — OSI для точной коммуникации о проблемах, TCP/IP для понимания того, что реально происходит в сети.

Сетевые уровни и QA

Как QA-инженеру, вам не нужна глубокая экспертиза по каждому уровню. Большая часть работы происходит на трёх уровнях:

Прикладной уровень (HTTP, API Testing)

Здесь происходит 80% сетевой отладки в QA. HTTP-коды состояния, тела API-ответов, значения заголовков и content types — всё это вопросы прикладного уровня. Инструменты Postman, curl и DevTools браузера инспектируют этот уровень.

Типичные симптомы: Неверные данные ответа, некорректные status codes, отсутствующие заголовки, сбои аутентификации.

Транспортный уровень (TCP/UDP, проблемы соединения)

Когда вы вообще не можете подключиться к сервису, проблема обычно на транспортном уровне. «Connection refused» означает, что порт не прослушивается. «Connection timed out» означает, что пакеты не проходят.

Типичные симптомы: Невозможно подключиться, обрывы соединений, медленная передача данных, конфликты портов.

Диагностические команды:

# Проверить, открыт ли порт
nc -zv hostname 8080

# Просмотреть активные соединения и прослушиваемые порты
ss -tlnp

# Проверить TCP-связность
telnet hostname 443

Сетевой уровень (IP-маршрутизация, DNS)

Когда хост полностью недоступен, проблема вероятно на сетевом уровне. Сбои ping, тупики traceroute и неудачное разрешение DNS указывают сюда.

Типичные симптомы: Хост недоступен, высокая задержка, пакеты теряются в пути.

Диагностические команды:

# Проверить базовую связность
ping hostname

# Отследить маршрут до хоста
traceroute hostname

# Проверить разрешение DNS
nslookup hostname
dig hostname
graph TB subgraph OSI["Модель OSI (7 уровней)"] L7[Уровень 7: Прикладной
HTTP, DNS, FTP] L6[Уровень 6: Представления
SSL/TLS, Кодировка] L5[Уровень 5: Сеансовый
Управление сессиями] L4[Уровень 4: Транспортный
TCP, UDP] L3[Уровень 3: Сетевой
IP, ICMP] L2[Уровень 2: Канальный
Ethernet, WiFi] L1[Уровень 1: Физический
Кабели, Сигналы] end subgraph TCPIP["Модель TCP/IP (4 уровня)"] T4[Прикладной
HTTP, DNS, FTP] T3[Транспортный
TCP, UDP] T2[Межсетевой
IP, ICMP] T1[Доступа к сети
Ethernet, WiFi] end L7 -.-> T4 L6 -.-> T4 L5 -.-> T4 L4 -.-> T3 L3 -.-> T2 L2 -.-> T1 L1 -.-> T1

Продвинутый анализ уровней

Понимание блоков данных протокола (PDU) на каждом уровне помогает QA-инженерам читать сетевые дампы и диагностировать сложные проблемы:

УровеньНазвание PDUСодержит
ПрикладнойДанныеПолезная нагрузка приложения (тело HTTP, JSON, HTML)
ТранспортныйСегмент (TCP) / Датаграмма (UDP)Порты источника/назначения, порядковые номера
СетевойПакетIP-адреса источника/назначения, TTL
КанальныйФреймMAC-адреса источника/назначения, проверка ошибок

Инкапсуляция и размер пакета

По мере прохождения данных вниз по уровням каждый уровень добавляет свой заголовок. Эта инкапсуляция увеличивает общий размер:

  • Данные приложения: переменный размер
  • Заголовок TCP: 20-60 байт
  • Заголовок IP: 20-60 байт
  • Заголовок Ethernet-фрейма: 14 байт + 4 байта трейлер

Максимальная единица передачи (MTU) — обычно 1500 байт для Ethernet — ограничивает размер одного фрейма. Когда пакет превышает MTU, он должен быть фрагментирован. Проблемы фрагментации вызывают загадочные частичные сбои, которые трудно диагностировать без понимания инкапсуляции.

Сценарий QA: Эндпоинт API работает для маленьких payload, но ломается для больших. Причина может быть в MTU-фрагментации, когда некоторые фрагменты отбрасываются файрволом, который не пересобирает фрагментированные пакеты.

Типичные баги по уровням, которые находит QA

Баги прикладного уровня:

  • API возвращает неверный заголовок Content-Type
  • Отсутствуют CORS-заголовки на определённых эндпоинтах
  • Заголовки кеширования вызывают устаревшие данные

Баги транспортного уровня:

  • Исчерпание пула соединений под нагрузкой
  • Несовпадение таймаута TCP keepalive между клиентом и сервером
  • Конфликты портов между сервисами в тестовых окружениях

Баги сетевого уровня:

  • DNS-кеш возвращает устаревший IP после деплоя
  • Таблицы маршрутизации не обновлены после изменения инфраструктуры
  • Слишком низкий TTL, из-за чего пакеты истекают в пути

Практическое упражнение

Для пяти следующих сценариев сетевых ошибок определите уровень OSI, на котором возникает каждая, и диагностический инструмент, который вы бы использовали:

  1. Сценарий: curl: (7) Failed to connect to api.example.com port 443: Connection refused
  2. Сценарий: ping: cannot resolve api.example.com: Unknown host
  3. Сценарий: curl: (60) SSL certificate problem: certificate has expired
  4. Сценарий: HTTP/1.1 502 Bad Gateway возвращает балансировщик нагрузки
  5. Сценарий: traceroute показывает таймаут пакетов после 5-го хопа
Решения

  1. Транспортный уровень (Уровень 4) — Порт 443 не прослушивается. Используйте ss -tlnp или netstat для проверки работы сервиса. Используйте telnet api.example.com 443 для проверки связности.

  2. Прикладной/сетевой уровень (DNS) — Разрешение DNS не удалось. Используйте dig api.example.com или nslookup для диагностики. Проверьте /etc/hosts и настройки DNS-сервера.

  3. Уровень представления (Уровень 6) — Проблема SSL/TLS-сертификата. Используйте openssl s_client -connect api.example.com:443 для проверки деталей сертификата и цепочки.

  4. Прикладной уровень (Уровень 7) — Балансировщик нагрузки получил невалидный ответ от upstream-сервера. Проверьте состояние бэкенд-сервера и логи. Используйте прокси-инструменты для инспекции реального ответа.

  5. Сетевой уровень (Уровень 3) — Проблема маршрутизации на 5-м хопе. Пакет не может достичь назначения. Свяжитесь с сетевой командой, предоставив вывод traceroute, показывающий, где именно теряются пакеты.

Советы профессионала

  • При отладке работайте снизу вверх: можете ли вы пропинговать хост? Можете ли подключиться к порту? Можете ли получить HTTP-ответ? Этот системный подход экономит время.
  • Большая часть работы QA происходит на уровнях 4 (транспортный) и 7 (прикладной), но понимание нижних уровней помогает точно общаться с сетевыми инженерами и DevOps.
  • «Connection refused» — это проблема транспортного уровня; «404 Not Found» — прикладного. Знание разницы сразу сужает область расследования.
  • Проблемы MTU вызывают загадочные частичные сбои — когда большие API-ответы ломаются, а маленькие работают, подумайте о фрагментации.
  • Используйте traceroute для определения, на каком сетевом хопе возникает задержка — вывод показывает точно, где пакеты замедляются или теряются.

Ключевые выводы

  1. Модели OSI/TCP-IP предоставляют основу для системной диагностики сетевых проблем при тестировании
  2. Большинство проблем, актуальных для QA, возникают на прикладном (ошибки HTTP) и транспортном (проблемы соединения) уровнях
  3. Диагностика снизу вверх (ping, затем подключение, затем запрос) — самый эффективный подход
  4. Понимание сетевых уровней помогает QA эффективно общаться с сетевыми инженерами и DevOps-командами