СА

Серверная Админа | Компьютерные сети

IT и технологии · 29 октября 2026 г.

Открыть канал в MAX

👋 Привет, сетевой друг!

👋 Привет, сетевой друг! Сегодня про dropwatch - утилиту для случаев, когда пакеты до сервера доходят, а дальше будто испаряются. 🟣Вот клиент жалуется на потери, tcpdump видит входящие пакеты, на интерфейсе всё спокойно. Но приложение часть запросов так и не получает. Вполне возможно, пакеты отбрасывает само ядро Linux. Переполнилась очередь, закончились буферы или что-то пошло не так при обработке TCP. И вот здесь пригодится dropwatch. Он показывает, в каких местах сетевого стека происходят сбросы. 🟣Запускаем интерактивный режим: sudo dropwatch -l kas Внутри включаем сбор статистики: set alertmode summary start Получаем адреса точек сброса и счётчики событий. Если доступны символы ядра, можно выяснить, какие функции за ними стоят. Хотим посмотреть отдельные события вместо сводки? stop set alertmode packet start 🟣А теперь интереснее. На современных ядрах есть tracepoint skb:kfree_skb, через который можно получить причину освобождения пакета. С помощью bpftrace посчитаем события по причинам: sudo bpftrace -e ‘ tracepoint:skb:kfree_skb { @[args->reason] = count(); }’ Или посмотрим, из каких функций ядро приходит к сбросу: sudo bpftrace -e ‘ tracepoint:skb:kfree_skb { @[kstack(8)] = count(); }’ Например, если потери связаны с переполнением очереди сокета, стек вызовов поможет сузить поиск до конкретного участка TCP-обработки. Уже гораздо полезнее, чем просто видеть растущий счётчик dropped. 🟣Только не стоит считать каждый kfree_skb проблемой. Некоторые пакеты освобождаются штатно, а потери непосредственно на сетевой карте такая трассировка может вообще не увидеть. И ещё: поле reason зависит от версии ядра. Проверить его наличие можно так: sudo bpftrace -lv ‘tracepoint:skb:kfree_skb’ В общем, если tcpdump показывает, что пакет пришёл, но дальше его след теряется, dropwatch и bpftrace помогут разобраться, что с ним сделал Linux. 🤖Бесплатный ChatGPT