intDataBlog
← ЖурналМаршруты обучения ↗

Путь запроса: от имени до ответа

Проследите DNS, соединение и HTTP; отделите сетевой сбой от ответа приложения.

Практика рассчитана на отдельную учебную среду и вымышленные данные.

DNS

DNS сообщает клиенту сведения об имени, но не проверяет работоспособность приложения. Сравнивайте имя, тип записи, резолвер и полученный ответ.

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

  • A/AAAA/CNAME
  • Рекурсивный и авторитетный ответ
  • TTL и кэш

Попробуйте

  1. Разберите ответ: api.example.test A 192.0.2.10, TTL 300.
  2. Объясните, почему смена записи не гарантирует мгновенного обновления у всех клиентов.
  3. Сравните NXDOMAIN, отсутствие ответа и успешное разрешение с последующим HTTP 500.

Три симптома относятся к разным этапам; успешный DNS не объявлен успешным запросом приложения.

Можно ли по NXDOMAIN делать вывод о firewall веб-сервера?

Нет. Это ответ о несуществующем имени в контексте DNS; соединение с веб-сервером ещё не проверялось.

Продолжить на русском и английском
  • Основы компьютерных сетей RU ↗

    Начните с топологий и первой практической задачи. Курс заявлен бесплатным, содержит веб-эмулятор Miminet; вход уточняется на Stepik.

  • Network Fundamentals EN ↗

    Смотрите путь пакета и роль маршрутизатора. Учебные материалы; не отдельный браузерный стенд.

  • An overview of HTTP EN ↗

    Trace one request in browser DevTools. Открытая документация.

TCP и HTTP

Сетевое соединение и прикладной ответ — разные этапы. Порт помогает попасть в нужный сервис, а метод и статус HTTP задают смысл обмена.

У запроса несколько независимых этапов: разрешение имени, установление транспорта, согласование защищённого соединения, обмен сообщениями HTTP и работа приложения. Ответ 404 означает, что HTTP-сервер ответил, хотя нужный ресурс не найден. Тайм-аут соединения не сообщает, какой статус вернуло бы приложение.

HTTP/1.1 и HTTP/2 обычно используют TCP; HTTP/3 работает поверх QUIC. Для первого разбора достаточно проследить один явно выбранный протокол. Не превращайте схему TCP в универсальное описание любого веб-трафика.

  • Адрес и порт
  • Метод и статус
  • Заголовки и тело

Попробуйте

  1. В DevTools браузера откройте Network для обычной публичной страницы без отправки форм.
  2. Найдите один GET: URL, статус, Content-Type и длительность.
  3. Разделите примеры: connection refused; TLS error; HTTP 404.

Каждый пример связан с уровнем; 404 не трактуется как отсутствие TCP-соединения.

Доказывает ли HTTP 500, что DNS не работает?

Нет. Клиент уже получил HTTP-ответ от компонента, но нужно выяснить, какой компонент его сформировал.

Продолжить на русском и английском
  • Обзор HTTP RU ↗

    Запрос, ответ, метод, статус и заголовки. Чтение открыто; собственные запросы выполняйте к учебному сервису.

  • An overview of HTTP EN ↗

    Trace one request in browser DevTools. Открытая документация.

  • Основы компьютерных сетей RU ↗

    Начните с топологий и первой практической задачи. Курс заявлен бесплатным, содержит веб-эмулятор Miminet; вход уточняется на Stepik.

TLS и сертификаты

TLS шифрует транспорт и позволяет проверить, с кем устанавливается соединение. Имя, срок, цепочка доверия и системное время — разные части проверки.

TLS защищает обмен и позволяет клиенту проверить сервер по цепочке доверия и имени. Успешное соединение с IP не доказывает корректность сертификата для домена. Отдельно проверьте срок, имя и цепочку. Пропуск проверки сертификата может скрыть причину ошибки, но не исправляет её.

  • Имя сертификата
  • Цепочка доверия
  • Срок и время

Попробуйте

  1. Разберите сертификат: SAN api.example.test, valid until 2030-01-01; запрос сделан к app.example.test.
  2. Укажите несоответствие имени независимо от срока.
  3. Объясните, почему отключение проверки не является исправлением.

Выявлено несовпадение SAN; предложено исправить имя/сертификат, сохранив проверку доверия.

Шифрование без проверки сертификата достаточно?

Нет. Оно не подтверждает личность сервера и допускает соединение с подменённым узлом.

Продолжить на русском и английском
  • Обзор HTTP RU ↗

    Запрос, ответ, метод, статус и заголовки. Чтение открыто; собственные запросы выполняйте к учебному сервису.

  • An overview of HTTP EN ↗

    Trace one request in browser DevTools. Открытая документация.

  • Основы компьютерных сетей RU ↗

    Начните с топологий и первой практической задачи. Курс заявлен бесплатным, содержит веб-эмулятор Miminet; вход уточняется на Stepik.

Маршрутизация, NAT и firewall

Маршрут выбирает следующий узел, NAT преобразует адрес, а firewall решает, разрешён ли поток. Для диагностики важно не смешивать эти три механизма.

Маршрут выбирает следующий путь пакета, NAT меняет адреса или порты, а фильтр принимает решение о пропуске. Это три разных роли. Для разбора нарисуйте исходный адрес, адрес назначения и точку преобразования; затем проверьте обратный путь. Одностороннее разрешение ещё не гарантирует ответ.

  • Префикс и шлюз
  • SNAT и DNAT
  • Направление правила

Попробуйте

  1. Нарисуйте две учебные подсети 192.0.2.0/24 и 198.51.100.0/24 со шлюзом.
  2. Проследите пакет до адресата и обратный ответ.
  3. Для правила allow TCP/443, deny TCP/5432 определите доступность HTTPS и базы.

На схеме есть обратный путь; правило объяснено через протокол, направление и порт.

Заменяет ли NAT политику доступа?

Нет. Преобразование адреса и решение разрешить поток выполняют разные функции.

Продолжить на русском и английском
  • Основы компьютерных сетей RU ↗

    Начните с топологий и первой практической задачи. Курс заявлен бесплатным, содержит веб-эмулятор Miminet; вход уточняется на Stepik.

  • Cisco Networking Basics EN ↗

    Сначала основы сетей и движение данных. Есть интерактивные задания; условия зачисления проверьте у Cisco.

  • Network Fundamentals EN ↗

    Смотрите путь пакета и роль маршрутизатора. Учебные материалы; не отдельный браузерный стенд.

Сетевая диагностика

Проверяйте самый ранний неуспешный этап: имя, маршрут, соединение, TLS, приложение. Один успешный ping не подтверждает исправность всего сервиса.

Проверяйте по слоям и сохраняйте наблюдение каждого шага. Отсутствие ответа ping может быть политикой ICMP, поэтому не заменяет проверку нужного TCP-порта или HTTP-адреса. Меняйте одну гипотезу за раз: иначе положительный результат не объяснит, какое из нескольких действий помогло.

  • DNS/TCP/TLS/HTTP
  • Контрольный запрос
  • Граница наблюдения

Попробуйте

  1. Разберите последовательность: DNS OK, TCP/443 OK, certificate hostname mismatch, HTTP не получен.
  2. Выберите следующую проверку имени сертификата и имени в URL.
  3. Составьте таблицу из пяти уровней с состояниями OK / ошибка / ещё не проверено.

HTTP помечен как не проверенный, а не «сломанный»; найден первый подтверждённый отказ TLS.

Почему ping не доказывает доступность HTTPS?

ICMP и TCP/443 с TLS — разные протоколы и проверки. Политика может разрешать один и блокировать другой.

Продолжить на русском и английском
  • Основы компьютерных сетей RU ↗

    Начните с топологий и первой практической задачи. Курс заявлен бесплатным, содержит веб-эмулятор Miminet; вход уточняется на Stepik.

  • Network Fundamentals EN ↗

    Смотрите путь пакета и роль маршрутизатора. Учебные материалы; не отдельный браузерный стенд.

  • An overview of HTTP EN ↗

    Trace one request in browser DevTools. Открытая документация.

Балансировка

Балансировщик скрывает несколько экземпляров за одной точкой входа. Работоспособность порта, готовность приложения и успешность пользовательского действия проверяются отдельно.

Балансировщик принимает запрос и выбирает один из нескольких экземпляров. Его собственная доступность и здоровье выбранного приложения — разные свойства. Проверяйте health каждого экземпляра и поведение реального пользовательского запроса. При изменении состава учитывайте активные соединения, а не только новые.

  • L4 и L7
  • Health checks
  • Готовность экземпляра

Попробуйте

  1. Нарисуйте proxy и два backend A/B.
  2. Для A health=200, B health=503 определите, куда направить следующий запрос.
  3. Разберите, что изменится при общих данных в БД и локальной сессии только на A.

Нездоровый B исключён; для состояния сессии назван дополнительный риск.

Достаточно ли открытого TCP-порта для готовности?

Не всегда: процесс может слушать порт, но не иметь зависимости или возможности обслужить запрос.

Продолжить на русском и английском
  • An overview of HTTP EN ↗

    Trace one request in browser DevTools. Открытая документация.

  • Cisco Networking Basics EN ↗

    Сначала основы сетей и движение данных. Есть интерактивные задания; условия зачисления проверьте у Cisco.

  • Site Reliability Engineering books EN ↗

    SLO, мониторинг и разбор инцидентов. Открытые онлайн-книги; материал для этапа после основ.

Надёжный сетевой обмен

Запрос может быть выполнен сервером, даже если клиент не получил ответ. Поэтому timeout и повтор требуют понимания операции и защиты от дубликатов.

Вызов внешнего API пересекает границу ответственности. Ограничьте время ожидания и размер ответа; различайте отказ соединения, ошибку HTTP и некорректный ответ. Повтор допустим только с понятной семантикой операции. Потерянный ответ на создание заказа не доказывает, что заказ не создался.

  • Timeout и backoff
  • Идемпотентность
  • Повтор и статус

Попробуйте

  1. Разберите POST /orders: клиент получил timeout, сервер успел создать order-17.
  2. Сравните повтор без ключа и повтор с тем же Idempotency-Key.
  3. Опишите запрос статуса операции и предел повторных попыток.

План не создаёт второй заказ; повтор ограничен и сохраняет идентификатор операции.

Гарантирует ли timeout отсутствие результата?

Нет. Он означает, что клиент не дождался ответа; состояние сервера нужно выяснить отдельно.

Продолжить на русском и английском
  • An overview of HTTP EN ↗

    Trace one request in browser DevTools. Открытая документация.

  • Enterprise Integration Patterns EN ↗

    Message Channel, Message Router и повторная доставка. Авторский каталог паттернов; чтение, не браузерный тренажёр.

  • Site Reliability Engineering books EN ↗

    SLO, мониторинг и разбор инцидентов. Открытые онлайн-книги; материал для этапа после основ.

Где обрывается запрос

Разделите имя, соединение, сертификат и ответ приложения. Это вымышленный учебный сценарий.

1. Имя

URL: https://api.example.test
DNS: NXDOMAIN
TCP/TLS/HTTP: не проверены

Какая проверка первая?

2. Сертификат

DNS: 192.0.2.10
TCP/443: connected
certificate SAN: old.example.test
URL host: api.example.test

Почему соединение не считается доверенным?

3. Приложение

DNS/TCP/TLS: OK
HTTP: 503
proxy: no healthy upstreams

Что проверить дальше?