Вопросы на собеседовании: Сети и протоколы

Приложение пишет Could not resolve host, но коллега уверяет, что DNS-запись есть. Как пройдёшь путь резолвинга и локализуешь сбой?

getent ahosts api.example.com
dig api.example.com A
dig api.example.com AAAA

как ответить Сначала повторяю запрос тем же системным resolver path, что и приложение, например через getent, а затем сравниваю его с прямым DNS-запросом через dig. Проверяю имя, тип записи, CNAME-цепочку, настроенные resolver-адреса и код ответа. Различаю NXDOMAIN, отсутствие нужного типа, SERVFAIL и timeout: у них разные причины и разные действия.

Нужно передавать логи или метрики по сети. Как объяснишь выбор между TCP и UDP без лозунга «TCP надёжный, UDP быстрый»?

как ответить TCP даёт приложению упорядоченный поток байтов, управляет потерями и перегрузкой, но не сохраняет границы сообщений. UDP передаёт отдельные datagram без встроенной гарантии доставки, порядка и устранения дублей. Выбор зависит от допустимой потери, требований к задержке и того, реализует ли прикладной протокол собственные подтверждения, повторы и контроль перегрузки.

Чем для диагностики отличаются connection refused и timeout при подключении к TCP-порту? Какие проверки сделаешь с клиента и с сервера?

как ответить Connection refused обычно означает быстрый отрицательный ответ: на адресе нет слушателя либо firewall активно отклонил запрос. Timeout означает, что ожидаемого ответа не получили: пакет или ответ мог быть отброшен, маршрут сломан или узел недоступен. Сверяю DNS и маршрут на клиенте, listener и bind address на сервере, затем firewall и пакетный захват на границе спорного участка.

Ты настраиваешь retry для идемпотентного GET к внешнему API: бывают 429, 500, 503, connect timeout и read timeout. Какие случаи повторишь, как ограничишь попытки и почему ретраи на нескольких слоях опасны?

как ответить Повторяю только ошибки, которые контракт сервиса считает временными: сам класс 5xx ещё не делает любой ответ повторяемым. Все попытки делят общий deadline, используют ограниченный exponential backoff с jitter и учитывают Retry-After; владельцем retry должен быть один согласованный слой. Даже безопасный по семантике GET создаёт нагрузку, поэтому retry budget и отмена после ухода исходного клиента обязательны.

После замены сертификата клиенты получают TLS verification error, хотя порт 443 открыт. Что именно проверяет клиент и как разберёшь цепочку без отключения проверки?

openssl s_client -connect api.example.com:443 -servername api.example.com -showcerts </dev/null
curl -v https://api.example.com/

как ответить Клиент проверяет доверенную цепочку, срок действия и соответствие имени сервиса идентификаторам сертификата. Смотрю сертификаты, которые реально отдаёт endpoint с нужным SNI, а не файл на диске одной машины. Проверяю SAN, промежуточные сертификаты, часы клиента и trust store; -k использую только как диагностический контраст, не как исправление.

У HTTP-клиента есть connect, read, write и общий timeout. Как задашь их для внешнего сервиса и почему один большой timeout — слабая защита?

как ответить Разные timeout ограничивают разные фазы: установление соединения, отправку, ожидание данных и всю операцию. Настраиваю их от end-to-end SLO и оставляю вызывающему слою время на обработку ошибки, а все retry делят один абсолютный deadline. Проверяю семантику конкретной библиотеки: read timeout часто измеряет бездействие между чтениями, а не полную длительность ответа.

Reverse proxy периодически отдаёт 502 и 504. Чем эти симптомы обычно отличаются и какие доказательства соберёшь на proxy и upstream?

location /api/ {
    proxy_pass http://app;
    proxy_connect_timeout 2s;
    proxy_read_timeout 30s;
}

как ответить Обычно 502 означает, что gateway не получил корректный ответ upstream: connect мог быть отклонён, соединение сброшено или ответ оказался невалидным. 504 означает, что gateway дождался своего timeout, ожидая upstream. Точный mapping зависит от proxy, поэтому связываю access/error log с upstream address, статусом, фазовыми таймингами и журналом приложения по request ID.

Сервис доступен через curl localhost:8080 на сервере, но недоступен снаружи. Как проверишь bind address, маршрут, firewall и NAT, не открывая порт всему интернету вслепую?

как ответить Сначала смотрю ss -lntp: listener на 127.0.0.1 принимает только локальный трафик, а wildcard или адрес интерфейса — внешний. Затем проверяю путь от клиента, правила firewall и счётчики, а при наличии NAT — преобразование назначения и обратный маршрут. Разрешение делаю для нужного источника и порта, после чего подтверждаю пакетами и логами.

Балансировщик считает все экземпляры healthy, но пользователи получают ошибки только на части запросов. Что проверишь в health check, алгоритме распределения и жизненном цикле экземпляра?

как ответить Проверяю, что health endpoint отражает способность обслужить реальный запрос, а не только наличие процесса. Сопоставляю ошибки с конкретным backend, его весом, версией и зоной, затем смотрю readiness при старте и drain при остановке. Алгоритм и sticky sessions могут концентрировать проблему, но не заменяют исправление неисправного экземпляра.

Клиент открывает новое TCP/TLS-соединение на каждый HTTP-запрос, latency растёт, а на хосте заканчиваются локальные порты. Как исправишь это через connection pool и какие новые риски появятся?

как ответить Переиспользую соединения через bounded pool: это убирает повторные handshakes и снижает churn локальных портов. Ограничиваю размер, очередь ожидания и idle lifetime, согласуя их с timeout сервера и балансировщика. Учитываю stale connections, обновление DNS и то, что один большой pool без backpressure способен перегрузить downstream.

Для аварийного переключения поменяли A-запись и снизили TTL прямо перед изменением, но часть клиентов часами ходит на старый адрес. Почему DNS failover не мгновенный и как строить его надёжнее?

как ответить Новый TTL действует только на ответы, полученные после его публикации; старые кэши имеют прежний оставшийся TTL. Кроме recursive resolver есть кэши ОС, приложения и negative caching, а уже открытые TCP-соединения DNS вообще не переоценивают. Снижаю TTL заранее, измеряю обе площадки и использую управляемый traffic switch или балансировщик, не считая DNS единственным механизмом здоровья.

Под нагрузкой новые TCP-подключения начинают timeout-иться, хотя CPU приложения ещё не насыщен. Как отличишь заполненный backlog, медленный accept, лимит descriptor и проблему conntrack?

как ответить Разбираю путь нового соединения до кода приложения: SYN processing, очередь завершённых handshakes, accept, создание descriptor и stateful middleboxes. Снимаю ss, сетевые счётчики, лимиты процесса и conntrack одновременно с packet capture. Настройки backlog увеличиваю только после доказательства, иначе они маскируют медленный accept loop или исчерпанную зависимость.