Отладка транспорта: tcpdump, Wireshark, curl

«Сервис не работает». Это единственная информация от мониторинга. Без инструментов отладки - часы потраченные на гипотезы. С tcpdump: 30 секунд чтобы увидеть что firewall правило блокирует порт. С curl timing: 5 секунд чтобы понять что TTFB=3s - медленный SQL запрос. Инструменты превращают 'не работает' в 'вот конкретная причина'.

• **Cloudflare** публично описал инцидент где tcpdump выявил BGP routing loop: пакеты циркулировали между двумя DC. Без packet capture это было бы невозможно диагностировать по логам.
• **GitHub** использует Wireshark анализ для диагностики Git protocol проблем. Особенно полезно при проблемах с large pack files и smart HTTP protocol.
• **Netflix** включил SSLKEYLOGFILE в development окружениях для Wireshark анализа HTTPS трафика между сервисами - это ускорило отладку TLS-related проблем.

tcpdump: захват пакетов

tcpdump - command-line инструмент для захвата сетевых пакетов. Незаменим для диагностики: нет соединения? видно ли SYN? Высокая latency? видно где теряется время. Работает на любом Linux/Mac без GUI.

tcpdump требует root или CAP_NET_ADMIN. В production: создать capture и скачать для анализа локально в Wireshark. Никогда не анализировать production трафик с паролями и токенами без разрешения - это PII/security вопрос.

Wireshark: анализ пакетов

Wireshark - GUI для анализа захватов пакетов (.pcap файлы). Умеет декодировать сотни протоколов, реассемблировать TCP streams, дешифровать TLS (с ключами), вычислять round-trip time между пакетами.

Wireshark's TCP sequence analysis автоматически помечает проблемы: [TCP Retransmission], [TCP Out-of-Order], [TCP Zero Window], [TCP Dup ACK]. Это первое что нужно искать при нестабильном соединении.

curl для HTTP отладки

curl - незаменимый инструмент для тестирования HTTP API. Режим -v (verbose) показывает всё: DNS резолюцию, TLS handshake, заголовки запроса и ответа. --timing показывает разбивку времени по фазам.

TTFB (Time To First Byte) = время до получения первого байта ответа. Включает DNS + TCP + TLS + сервер обработка. Если TTFB высокий - проблема на сервере или в сети, не в передаче данных.

Мониторинг брокеров сообщений

Kafka, RabbitMQ, NATS имеют встроенные management UI и метрики для Prometheus. Consumer lag, queue depth, partition leader elections - ключевые сигналы проблем.

Kafka partition lag в одной partition, а не во всех - признак того что конкретный consumer hung или перегружен. Перебалансировка consumer group (rebalance) перераспределит partition. Но rebalance - это downtime: пока идёт, никто не читает.

Чеклист отладки транспорта

Систематический подход к отладке транспортных проблем: от симптома к причине. Divide and conquer: проверять каждый уровень по очереди вместо случайных гипотез.

nc -zv (netcat) - быстрая проверка TCP доступности без HTTP: `nc -zv db.internal 5432`. Если успешно - TCP работает, проблема на уровне PostgreSQL. Если нет - сетевая/firewall проблема.

Итоги

• **tcpdump** - первый инструмент при 'нет соединения': видно SYN/SYN-ACK, RST, Retransmissions - сетевые проблемы которые приложение не видит.
• **curl -v + timing** - HTTP диагностика: DNS, TCP, TLS, TTFB каждый в отдельности. TTFB - время обработки на сервере.
• **Kafka lag / RabbitMQ queue depth** - первые метрики при проблемах с очередями. Uneven lag по partitions = проблема конкретного consumer.

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

Инструменты отладки дополняют наблюдаемость на разных уровнях стека:

• Distributed Tracing — Трейсинг показывает application-level задержки; tcpdump/Wireshark - network-level. Вместе покрывают весь стек
• Безопасность: mTLS — TLS debugging через curl -v и Wireshark SSLKEYLOGFILE необходим при настройке mTLS и диагностике certificate errors

Вопросы для размышления

• Как безопасно захватить трафик в production без риска утечки PII данных?
• Когда tcpdump недостаточен и нужен Wireshark для анализа?
• Как автоматизировать сетевую диагностику как часть CI/CD или health checks?

Связанные уроки

• net-59-troubleshooting