Перейти к основному содержимому

Сеть для диагностики бэкенда

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Разработчику

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

База: сеть и интернет, HTTP.

Уровни, которые вас касаются​

На каждом hop добавляется задержка. Время ответа API = обработка на сервере + сеть туда-обратно + очередь на балансировщике.

Ключевые метрики​

МетрикаЧто означаетТипичный симптом
RTT (Round-Trip Time)Время туда-обратно до узлаВысокий RTT → долгий TTFB даже при лёгком коде
LatencyЗадержка доставки«Плавающее» время ответа
JitterРазброс задержкиНестабильный UX, таймауты на мобильных сетях
Packet lossПотеря пакетовРетрансмиссии TCP, «зависания»
BandwidthПропускная способностьДолгая загрузка больших тел, не коротких API

Важно: TCP при потерях снижает скорость (контроль перегрузки). UDP (DNS, QUIC/HTTP3) ведёт себя иначе — потери могут проявляться как ошибки без повторной доставки на уровне приложения.

TCP и HTTP в двух словах​

  • SYN → SYN-ACK → ACK — установление соединения (один RTT и больше).
  • Keep-Alive — повторное использование TCP для нескольких HTTP-запросов; без него каждый запрос платит handshake.
  • HTTP/2 — мультиплексирование потоков в одном TCP; меньше head-of-line blocking, чем в HTTP/1.1 с множеством соединений.
  • TLS — дополнительные RTT на handshake (смягчается session resumption).

Если API вызывается тысячи раз в секунду с коротким телом, оптимизация JSON может дать меньше, чем пул соединений к БД и keep-alive к upstream.

Симптом → гипотеза​

НаблюдениеВероятная причинаЧто проверить
Медленно только из одного регионаМаршрут, CDN, гео-репликаТрассировка, DNS на региональный IP
Медленно только на мобильномВысокий RTT/джиттерПерцентили p95/p99, размер ответа
Таймауты пачкамиПотери, перегрузка LB, исчерпание портовМетрики LB, ss, лимиты
Быстро с сервера, медленно снаружиFirewall, NAT, неверный DNScurl с хоста vs с ноутбука
Быстро без TLS, медленно с TLSСертификат, цепочка, CPUПрофиль TLS, HTTP/2

Инструменты разработчика​

ИнструментНазначение
DevTools → NetworkВодопад запросов, TTFB, размер
curl -w (см. пример ниже)Время DNS/connect/TTFB с сервера
dig, hostЗаписи DNS, TTL, неверный A/AAAA
ping, traceroute / tracertRTT по хопам (ICMP может быть заблокирован)
Логи прокси (Nginx)$request_time, upstream time

Глубокий разбор пакетов (tcpdump, анализ в GUI) — задача инженера по эксплуатации; разработчику достаточно уметь заказать такой анализ с воспроизводимым request_id.

С сервера (или из CI на staging):

curl -s -o /dev/null -w \
  "dns:%{time_namelookup}s connect:%{time_connect}s ttfb:%{time_starttransfer}s total:%{time_total}s code:%{http_code}\n" \
  https://api.example.com/health

TTFB (Time To First Byte) в DevTools — время до первого байта ответа. В логах Nginx поле $request_time ближе к полной обработке на upstream. Если TTFB высокий, а $request_time низкий — ищите сеть/CDN; если оба высокие — бэкенд или БД.

DNS — частый скрытый виновник​

Каждый новый хост в цепочке микросервисов → резолвинг имени. Проблемы:

  • слишком большой TTL (Time To Live) записи DNS — после смены IP клиенты ещё долго ходят на старый адрес;
  • нет кэша резолвера в приложении;
  • IPv6 AAAA есть, но маршрут до IPv6 сломан (fallback замедляет).

Файл /etc/hosts на staging — легитимный способ подменить маршрут для отладки.

Практические рекомендации для API​

  1. Таймауты на исходящие вызовы (connect + read) — всегда явные.
  2. Идемпотентность и retry только на безопасных операциях — иначе дубли при ретрансмиссии TCP не спасут бизнес-логику.
  3. Сжатие (gzip, brotli) для крупных JSON — экономит bandwidth, тратит CPU.
  4. CDN для статики; API — ближе к пользователю через edge только если есть смысл (часто API остаётся в одном регионе).
  5. Смотрите p95/p99, не среднее — сеть «длинным хвостом» портит UX.

Связанные темы​

См. также

Другие статьи этого же раздела в боковом меню (как на странице «О разделе»).

Освоение главы0%