Глубокая диагностика сетевых проблем в Linux: от `tcpdump` до eBPF и системных ограничений

Категория: Статьи • 12 July 2025 • 3 мин чтения

Введение
Современные распределённые приложения подвержены сетевым аномалиям. Простой ping или netstat не всегда дают достаточно контекста для диагностики сложных проблем. Настоящее понимание требует наблюдения за трафиком, анализа задержек и изучения поведения стека протоколов. Рассмотрим инструменты и методы, дающие инженерам полный контроль над сетевым взаимодействием.

Отлов сырых пакетов: tcpdump и его фильтры

Базовый инструмент для инспекции трафика — tcpdump. Его сила в фильтрации BPF (Berkeley Packet Filter). Пример мониторинга HTTPS-трафика с детализацией:

bash
sudo tcpdump -ni eth0 'tcp port 443 and (tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn)'

Разбор:

  • -ni eth0: Использование интерфейса eth0 без разрешения имён (-n)
  • Фильтр: Порт 443 + только SYN-пакеты (инициирование соединения)
  • tcp[tcpflags]: Прямой доступ к битовым флагам заголовка TCP

Для анализа уже захваченного файла:

bash
tcpdump -r capture.pcap -X 'ip host 192.168.1.5 and tcp'

Флаг -X выводит hex + ASCII дамп пакетов — критично для диагностики бинарных протоколов (gRPC, AMQP).

Эмуляция сетевых проблем: tc для Controlled Chaos

Как проверить поведение приложения при потере пакетов или высокой задержке? Утилита tc (Traffic Control) позволяет внедрять искусственные проблемы.

Пример — задержка + джиттер:

bash
sudo tc qdisc add dev eth0 root netem delay 100ms 20ms distribution normal loss 5%

Параметры:

  • delay 100ms: Базовая задержка
  • 20ms: Джиттер (вариация задержки)
  • distribution normal: Статистическое распределение
  • loss 5%: Потеря пакетов

Чтобы смоделировать низкую пропускную способность (имитация слабого канала):

bash
sudo tc qdisc add dev eth0 root tbf rate 1mbit burst 32kbit latency 400ms

Почему это важно: Тестирование в условиях реалистичных ограничений выявляет проблемы таймаутов и буферизации до продакшн-инцидентов.

Пробираясь в ядро: eBPF и bcc-tools

Традиционные утилиты (top, ss) показывают результат на момент вызова. eBPF позволяет наблюдать события сети/ядра в реальном времени без разрывов.

Установка bcc-tools (Ubuntu):

bash
sudo apt install bpfcc-tools linux-headers-$(uname -r)

Пример — отслеживание медленных TCP-соединений:

bash
sudo tcplife -T 100

Флаг -T 100 показывает соединения с временем жизни >100ms.

Трассировка случайных отбрасываний пакетов (dropwatch):

bash
sudo dropwatch -l kas

Ключ -l kas использует карту адресов ядра для детализации точек сброса.

Кастомный скрипт на bpftrace для подсёта TCP-Rетрансмиссий:

bpftrace
kprobe:tcp_retransmit_skb
{
    @retransmissions[pid, comm] = count();
}

Вывод покажет PID и имя процесса, чьи соединения страдают от ретрансмиссий — прямой индикатор проблем сети или приложения.

Системные ограничения: смотрим глубже

Проблемы часто возникают на уровне системных ресурсов.

1. Настройки сокетов:
Проверьте лимиты очередей:

bash
sysctl net.core.somaxconn net.ipv4.tcp_max_syn_backlog

Увеличение при ошибках listen queue full:

bash
sudo sysctl -w net.core.somaxconn=4096

2. Ошибки NIC и буферы:
Статистика интерфейса:

bash
ip -s link show eth0

Поля RX/TX errors, dropped, overrun требуют внимания. Увеличение буферов:

bash
sudo ethtool -G eth0 rx 4096

3. Firewall и conntrack:
При активном nf_conntrack проверяйте хэш-таблицу:

bash
dmesg | grep "nf_conntrack: table full"

Порог по умолчанию всего 65536 записей — катастрофически мало для шлюзов.

Заключение
Типизация сетевых проблем в Linux требует комбинации инструментов:

  1. Глубокий анализ пакетов (tcpdump, Wireshark)
  2. Эмуляция сложных условий (tc) для предупреждения инцидентов
  3. Мониторинг ядра в режиме реального времени (eBPF/bcc)
  4. Постоянная проверка ресурсов системы и параметров стека

Интегрируйте эти методы в циклы тестирования и мониторинга. Проблемы сети редко бывают изолированными — ищите корреляции между сетевыми метриками, хостом и приложением. Инвестиции в понимание сетевого стека Linux окупаются сокращением MTTR и надёжностью систем.