Сеть и протоколы для тестировщика

Слои и порядок диагностики

Запрос проходит четыре слоя, и на каждом свой отказ. DNS: имя не превратилось в адрес - «такого хоста нет». TCP: адрес есть, но соединение не устанавливается - «отвергнуто» (никто не слушает) или «время вышло» (пакеты не доходят, обычно межсетевой экран). TLS: соединение есть, но не сошлись на шифровании или сертификат просрочен. HTTP: всё установилось, и приложение ответило кодом.

Разбирают снизу вверх, потому что верхний слой без нижнего не работает. Инструменты соответствуют слоям: команда резолва имени проверяет DNS, попытка подключиться на порт - TCP, а curl -v показывает всю цепочку разом: какой адрес выбран, как прошло шифрование, какие заголовки ушли и вернулись, каким кодом всё кончилось.

// Главная польза от curl -v в другом: он отделяет клиента от сервера. Если через него баг воспроизводится - проблема на сервере, и репорт идёт бэкендерам. Если не воспроизводится - дело в клиенте: в его заголовках, настройках или посреднике. Это экономит день переписки на каждом таком случае.

# видно выбранный адрес, шифрование,
# заголовки в обе стороны и код ответа
curl -v https://api.example.com/orders/42 \
  -H "Authorization: Bearer $TOKEN"

отвергнуто / время вышло

никто не слушает порт / пакеты не доходят или сервис завис

curl -v

показывает всю цепочку: адрес, шифрование, заголовки, код

Таймауты и почему приходит 504

Таймауты бывают двух видов, и путать их нельзя. Таймаут соединения - сколько ждём, пока установится связь. Таймаут ответа - сколько ждём ответ по уже установленной связи. В моём замере первый случай отработал за 21 миллисекунду (соединение отвергнуто сразу), второй съел всё отведённое время до последней миллисекунды.

А вот замер, объясняющий самую частую жалобу. Сервис честно считает три секунды и отвечает 200 - я обратился к нему напрямую и получил ответ через 3002 миллисекунды. Между клиентом и сервисом поставил посредника с таймаутом в одну секунду. Тот же запрос через посредника: 1003 миллисекунды и 504. Сервис исправен, запрос корректен, но посредник сдался раньше.

// Отсюда правило: таймауты в цепочке должны быть согласованы, и наружный обязан быть не меньше внутреннего. «Напрямую работает, через балансировщик 504» - это почти всегда не про сервис, а про рассинхрон настроек. Тестировщик, который это знает, приносит разработчикам диагноз, а не загадку.

таймаут соединения / ответа

ждём установления связи / ждём ответ по установленной связи

504

посредник не дождался ответа от сервиса за отведённое ему время

Посредники, имена и мобильная сеть

Посредник (обратный прокси или балансировщик) стоит перед сервисом и незаметно меняет картину: подставляет настоящий адрес клиента в отдельный заголовок, режет или добавляет заголовки, ограничивает размер тела, держит свои таймауты. Поэтому «работает напрямую, падает через него» - обычное дело, и разбирается сравнением того, что именно он поменял.

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

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

обратный прокси

посредник перед сервисом: свои таймауты, лимиты и заголовки

локальный файл имён

перебивает DNS на вашей машине; забытая строка = не та среда

Как отвечать: «Через Postman работает, из кода нет - как разбираешься?»

Не гадаю, а нахожу различие, потому что сервер-то один и тот же. Первым делом воспроизвожу оба варианта через curl с подробным выводом: он показывает всю цепочку - какой адрес выбран, как прошло шифрование, какие заголовки ушли и вернулись, каким кодом всё кончилось. Дальше сравниваю по порядку убывания вероятности. Заголовки: Postman сам добавляет тип содержимого, принимаемые форматы, своё имя клиента и куки из окружения, а в коде их легко забыть или послать другими. Посредник: Postman может ходить через системный прокси, а код напрямую или через другой - и тогда цепочка разная. Тело и кодировка: сериализация в коде отличается от того, что руками вставлено в Postman, вплоть до лишнего пробела или другой кодировки. Таймауты: у клиента в коде может стоять короткий по умолчанию, и он не дожидается. И проверяю имена: не ходят ли они на разные адреса из-за локального файла соответствий или кэша. Метод простой - подробный вывод на обоих, разница по заголовкам, посреднику и телу. Обычно всё сводится к одному забытому заголовку.

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

На чём валят

• −Репортить «API лежит», когда имя не резолвится на конкретной машине.
• −Забытая строка в локальном файле имён - неделя тестирования не той среды.
• −Считать 504 поломкой сервиса: сервис ответил за 3 секунды, а посредник ждал одну.
• −Не различать «соединение отвергнуто» и «время вышло» - это разные диагнозы.
• −Тестировать только на офисной сети - пользователь живёт на мобильном интернете с потерями.