Проверка потери пакетов linux

Обновлено: 04.07.2024

Во многих случаях может понадобиться отследить нагрузку на сеть, посмотреть сколько данных передается и какие пользователи, программы или компьютеры занимают канал. Особенно часто такие задачи возникают перед системными администраторами, перед которыми стоит задача отслеживать работу сети целой компании. Но также это может быть полезно и обычным пользователям.

В этой статье мы рассмотрим как выполняется мониторинг сети Linux. Для этого можно использовать различные утилиты. Начиная от сетевых анализаторов, таких как Wireshark и tcpdump до более простых инструментов, таких как iptraf.

Как работает мониторинг сети?

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

Таким образом, очень просто можно узнать какая сейчас нагрузка на сеть, какие программы или сервисы создали пакеты, и даже что содержится в этих пакетах и что делает пользователь.

Мониторинг сети с помощью iptraf

iptraf - это одна из самых лучших программ для мониторинга сети в Linux. Она предоставляет очень удобный интерактивный интерфейс, с помощью которого можно наглядно увидеть всю необходимую информацию, причем достаточно подробно. Утилита не поставляется по умолчанию, но она достаточно популярна, поэтому вы можете установить ее из официальных репозиториев. Для этого в Ubuntu выполните команду:

sudo apt install iptraf

А в CentOS / Red Hat выполните:

sudo yum install iptraf

После установки утилиты для ее запуска просто наберите в терминале iptraf-ng:

Перед вами откроется интерактивный интерфейс на основе Ncurses, в котором необходимо выбрать нужное действие. Здесь доступны монитор пропускной способности сети, статистика по интерфейсу, статистика по сбоям и монитор локальной сети.

Обратите внимание на нижнюю часть окна, там отображается описание выбранного действия, а также находятся подсказки по горячим клавишам.Например, для просмотра сетевых соединений и статистики трафика для каждого из них выберите IP traffic moitor. Затем вам будет необходимо выбрать сетевой интерфейс, например, enp2s0:

Дальше вы увидите все IP адреса, с которыми сейчас выполняется взаимодействие. Здесь можно увидеть направление отправки пакетов, количество пакетов и общий объем переданных или полученных данных в байтах.

С помощью других пунктов меню можно посмотреть статистику по интерфейсу или статистику по работе локальной сети. Утилита даже может работать в неразборчивом режиме, чтобы собирать максимум данных про локальную сеть.

Также поддерживаются фильтры, которые позволяют отфильтровывать информацию только по определенному критерию. Например, чтобы создать фильтр откройте меню Filters, затем выберите IP. , а дальше Apply new filter:

Затем нужно указать имя фильтра:

На следующем этапе вы можете расписать нужные параметры фильтрации:

Чтобы применить фильтр нужно выбрать Apply filter и выбрать имя фильтра из списка:

Теперь в любом пункте статистики будет отображаться только та информация, которая подходит под созданный фильтр.

Мониторинг трафика Linux чаще всего выполняется администраторами именно с помощью этой утилиты. Видео про использование утилиты:

Мониторинг сети с помощью других утилит

Самая мощная программа для мониторинга сети - это iptraf. Она предоставляет всю необходимую для администраторов информацию. Но, кроме нее, существуют и другие продукты. Рассмотрим их более подробно.

1. iftop

Утилита имеет более простой интерфейс и отображает намного меньше информации. Она выводит ip адреса отправителя и получателя, а также количество переданных или полученных данных за несколько последних секунд:

Установить программу в Ubuntu можно командной:

sudo apt install iftop

Хотя здесь отображается информация по каждому соединению, программа не может идентифицировать программу, которая создает пакеты.

2. nload

nload - это очень простая утилита, которая отображает только скорость входящих и исходящих соединений. Это позволяет сделать примитивный анализ сети linux и определить нагрузку. Отображается текущая скорость, максимальная и минимальная скорость за период работы. Также данные о скорости выводятся в виде графика, поэтому вам будет достаточно беглого взгляда, чтобы понять что происходит.

Для установки программы в Ubuntu используйте команду:

sudo apt install nload

3. nethogs

Nethogs - это достаточно интересная утилита для мониторинга сетей, которая выделяется среди других. С помощью нее можно посмотреть какой процесс создает тот или иной трафик. Здесь отображаются PID процессов и имена пользователей, отсортированные по занимаемой пропускной способности сети:

Программа, как и другие доступна из официальных репозиториев, поэтому у вас не возникнет проблем с установкой:

sudo yum install nethogs

4. bmon

Утилита bmon позволяет отображать достаточно подробно статистику по каждому сетевому интерфейсу. Она работает похоже на nload и выводит график кроме текстовой информации:

Для установки программы выполните:

sudo apt install bmon

5. Vnstat

Vnstat отличается от всех инструментов, рассмотренных выше. Программа работает постоянно в фоновом режиме и собирает информацию об использовании сети в лог файл. Далее можно посмотреть какой была нагрузка за определенный период. Для установки утилиты выполните:

sudo apt install vnstat

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

sudo systemctl start vnstat

Далее необходимо немного подождать, пока утилита соберет данные и можно просматривать статистику:

Здесь будет отображаться информация о нагрузке на сеть с указанием дат и периодов. Также вы можете посмотреть доступную информацию в реальном времени. Для этого используйте опцию -l:

Видео про использование и настройку vnstat:

6. bwm-ng

Это еще одна утилита, очень простая в использовании, которая позволяет следить за сетевой нагрузкой в режиме реального времени. Отображаются все доступные сетевые интерфейсы в системе:

Для установки утилиты выполните такую команду:

sudo apt install bwm-ng

7. speedometer

Это еще один простой инструмент, который позволяет выполнить мониторинг сети и выводит данные в виде красивых графиков. Для установки программы выполните:

sudo pip install speedometer

Как видите, она есть в официальных репозиториев не всех дистрибутивов, зато вы можете установить программу из репозитория python.

speedometer -r enp2s0f0 -t enp2s0f0

Опция -r указывает интерфейс, с которого необходимо отображать количество полученных пакетов, а опция -t - отправленных.

8. netwatch

Netwatch - это небольшая утилита, которая входит в набор инструментов Netdiag и показывает сетевые соединения между локальной и удаленными системами, а также скорость, с которой будут передаваться данные. Для установки программы используйте:

sudo apt install netdiag

Затем для запуска:

9. ifstat

Утилита ifstat показывает пропускную способность сети, измеряя количество переданных и принятых пакетов. Вывод утилиты можно использовать и анализировать в других программах. Утилита не выводит информацию об ip адресах или других параметрах, а только скорость. Для установки используйте:

sudo apt install ifstat

10. trafshow

Это утилита, очень похожа на iftop, которая отображает не только скорость передачи, но и сами соединения. Здесь выводится информация по соединениях, размеры пакетов и протокол. Для установки программы наберите:

sudo apt install trafshow

Осталось запустить программу:

Выводы

В этой статье мы рассмотрели команду Iptraf, а также еще несколько полезных утилит, с помощью которых можно выполнять мониторинг сети linux на сервере или домашнем компьютере. Некоторые из этих инструментов можно использовать даже в корпоративной среде. В качестве альтернативы вы можете использовать инструменты с веб-интерфейсом. Некоторые из них перечислены в статье системы мониторинга Linux. А какие инструменты мониторинга используете вы? Напишите в комментариях!

Сетевой стек Linux по умолчанию замечательно работает на десктопах, но на серверах с нагрузкой чуть выше средней и настройками по умолчанию - уже не очень, в основном из-за неравномерного распределения нагрузки на процессор.

Как работает сетевой стек

Коротко

Материнские платы могут поддерживать одновременную работу нескольких процессоров, у которых может быть несколько ядер, у которых может быть несколько потоков.
Оперативная память, NUMA. При использовании нескольких процессоров, как правило, у каждого процессора есть “своя” и “чужая” память. Обе они доступны, но доступ в чужую - медленнее. Бывают архитектуры, в которых память не делится между процессорами на свою и чужую. Сочетание ядер процессора и памяти называется NUMA-нодой. Иногда сетевые карты тоже принадлежат к NUMA-ноде.

Сетевые карты можно поделить по поддержке RSS (аппаратное масштабирование захвата пакетов). Серверные поддерживают, бюджетные и десктопные нет. Зачастую, несмотря на диапазон, указанный в smp_affinity_list у обработчика прерываний, прерывания обрабатываются только одним ядром (как правило CPU0). Все сетевые карты работают следующим образом:

IRQ (top-half): сетевая карта пишет пакеты в свою внутреннюю память. В оперативной памяти той же NUMA-ноды, к которой привязана сетевая карта, под неё выделен кольцевой буфер. По прерыванию процессора сетевая карта копирует свою память в кольцевой буфер и делает пометку, что у неё есть пакеты, которые надо обработать. Кольцевых буферов может быть несколько и они могут обрабатываться параллельно.
Softirq (bottom half): сетевой стек периодически проверяет пометки от сетевых карт о необходимости обработать пакеты. Пакеты из кольцевых буферов обрабатываются, проходят, файрволы, наты, сессии, доходят до приложения при необходимости. На этом уровне есть программный аналог аппаратных очередей, который уместен в случае с сетевыми картами с одной очередью.
Cache locality. Если пакет обрабатывался на определённом CPU и попал в приложение, которое работает там же - это лучший случай, кэши работают максимально эффективно.

Подробнее - путь пакета из кабеля в приложение:

Сразу оговорю неточности: не прописано прохождение L2, который ethernet. С L1 как-то сразу в L3 прыгнул.

Выводы

Перед главной задачей, выполняется первостепенная задача - подбор аппаратной части, само собой с учётом того, какие задачи лежат на сервере, откуда и сколько приходит и уходит трафика и т.д.

Есть два способа распределить нагрузку по обработке пакетов между ядрами процессора:

RSS - назначить smp_affinity для каждой очереди сетевой карты.
RPS (можно считать его программным аналогом RSS) - назначить rps_cpus для каждой очереди сетевой карты.
Комбинирование RSS и RPS. Дополнительный буфер с одной стороны - снижает вероятность потери пакета при пиковой нагрузке, с другой стороны - увеличивает общее времени обработки и может за счёт этого увеличивать вероятность потерь. Для сетевых карт с несколькими очередями и равномерным распределением пакетов перенос пакета с ядра на ядро будет использовать драгоценный budget и снизит эффективность использования кэша процессора.

Как подбирать аппаратное обеспечение

Процессоры

Число процессоров:

Однопроцессорный сервер эффективен, если трафик приходит только на одну сетевую карту, в том числе в её порты, если их несколько.
Двухпроцессорный сервер эффективен, если есть больше двух источников трафика, с потоком более 2 Гбит/сек и они обрабатываются отдельными сетевыми картами (не портами).

Не нужно больше ядер, чем максимальное суммарное количество очередей всех сетевых карт.
Hyper-Threading: не помогает, если обработка пакетов - основной вид нагрузки на процессор. Оценивайте процессор по числу ядер, а не потоков.

Размер RX-буферов: чем он больше, тем лучше.
Максимальное число очередей: чем их больше, тем лучше. Некоторые (mellanox) сетевые карты поддерживают только число очередей равное степени двойки. Если у Вас 6-ядерный процессор - имеет смысл подобрать другую сетевую карту.
Бракованные сетевые карты - вероятность мала, но иногда случается. Заменяем одну сетевую карту на точно такую же и всё замечательно.
Драйвер: не рекомендую использовать десктопные карты (обычно D-Link, Realtek).

Мониторинг и тюнинг сетевого стека

Мониторинг можно условно поделить на

краткосрочный - посмотреть как чувствует себя система прямо сейчас;
долгосрочный - с алертами, вот это всё.

Заниматься тюнингом без краткосрочного мониторинга равноценно случайным действиям. Я разработал инструменты для такого мониторинга - netutils-linux, они протестированы и работают на версиях python 2.6, 2.7, 3.4, 3.6, 3.7 и, возможно на более новых. Изначально делал для технической поддержки, объяснять каждому такой объёмный материал - долго, сложно. Есть фраза “код - лучшая документация”, а моей целью было “инструменты вместо документации”.

При возникновении проблем - сообщайте о них на github, а лучше присылайте pull-request’ы.

Мониторинг

network-top

Эта утилита отображает полную картину процесса обработки пакетов. Вы увидите равномерность распределения нагрузки (прерывания, softirqs, число пакетов в секунду на ядро процессора и на сетевой интерфейс) на ресурсы сервера, ошибки обработки пакетов. Аномальные значения счётчиков подсвечиваются красным.

Вверху отображаются источники прерываний, чтобы всё влезало на экран редкие прерывания скрыты. Имена ядер подсвечиваются в зависимости от принадлежности к NUMA-ноде или к процессору.

Посередине находится самое важное - распределение обработки пакетов по CPU:

Interrupts. Суммарное число прерываний на ядро. Лучше держаться не более 10000 прерываний на 1GHz частоты ядра. В случае с hyperthreading - 5000. Настраивается утилитой rss-ladder .
NET_RX. Число softirq на приём пакетов. Настраивается утилитой autorps .
NET_TX. Число softirq на отправку пакетов. Настраивается утилитой autoxps .
Total. Число обработанных данным ядром пакетов.
Dropped. Число отброшенных в процессе обработки пакетов. Отбрасывание приводит медленной работе сети, хосты повторно отправляют пакеты, у них задержки, потери, люди жалуются в техподдержку.
Time squuezed. Число пакетов, которым не хватило времени для обработки и их обработку отложили на следующий виток цикла. Повод задуматься о дополнительном тюнинге.
CPU Collision. times that two cpus collided trying to get the device queue lock. Ни разу не видел на своей практике.

Внизу находится статистика по сетевым девайсам.

rx-errors - общее число ошибок, обычно суммирует остальные. В какой именно счётчик попадает пакет зависит от драйвера сетевой карты.
dropped , fifo , overrun - пакеты, не успевшие обработаться сетевым стеком
missed - пакеты, не успевшие попасть в сетевой стек
crc - прилетают битые пакеты. Часто бывает следствием высокой нагрузки на коммутатор.
length - слишком большие пакеты, которые не влезают в MTU на сетевой карте. Лечится его увеличением: ip link set eth1 mtu 1540 . Постоянное решение для RHEL-based систем - прописать строчку MTU=1540 в файле конфигурации сетевой карты, например /etc/sysconfig/network-scripts/ifcfg-eth1 .

Флаги утилиты

Задать список интересующих девайсов: --devices=eth1,eth2,eth3
Отсеять девайсы регуляркой: --device-regex='^eth'
Сделать вывод менее подробным, спрятав все специфичные ошибки: --simple
Убрать данные об отправке пакетов: --rx-only .
Представление данных об объёме трафика можно менять ключами: --bits , --bytes , --kbits , --mbits .
Показывать абсолютные значения: --no-delta-mode

Альтернативные способы получения этой информации:

Потери могут быть не только на Linux-сервере, но и на порту связанного с ним сетевого оборудования. О том, как это посмотреть можно узнать из документации производителя сетевого оборудования.

Стандартный top

server-info

Если приходится иметь дело с разношёрстными серверами, которые закупались разными людьми, полезно знать какое оборудование у них внутри и насколько оно подходит под текущие нагрузки. Утилита server-info именно для этого и предназначена. У неё два режима:

--show - показать оборудование;
--rate - оценить оборудование.

Вывод в YAML. Примеры:

и оценивать это железо по шкале от 1 до 10:

Вместо --server можно указать --subsystem , --device или вообще ничего, тогда оценка будет вестись по каждому параметру устройства в отдельности.

Тюнинг

maximize-cpu-freq

Плавающая частота процессора плохо сказывается для нагруженных сетевых серверов. Если процессор может работать на 3.5GHz - не надо экономить немного ватт ценой потерь пакетов. Утилита включает для cpu_freq_governour режим performance и устанавливает минимальную частоту всех ядер в значение максимально-доступной базовой. Узнать текущие значения можно командой:

Помимо плавающей частоты есть ещё одно но, которое может приводить к потерям: режим энергосбережения в UEFI/BIOS. Лучше его выключить, выбрав режим “производительность” (для этого потребуется перезагрузить сервер).

rss-ladder

Утилита автоматически распределяет прерывания “лесенкой” на ядрах локального процессора для сетевых карт с поддержкой нескольких очередей.

Если сетевых карт несколько, лучше выделить для каждой очереди каждой сетевой карты одно физическое ядро, ответственное только за неё. Если ядер не хватает - число очередей можно уменьшить с помощью ethtool, например: ethtool -L eth0 combined 2 или ethtool -L eth0 rx 2 в зависимости от типа очередей.

Для RSS по возможности используйте разные реальные ядра, допустим, дано:

1 процессор с гипертредингом
4 реальных ядра
8 виртуальных ядер
4 очереди сетевой карты, которые составляют 95% работы сервера

В зависимости от того как расположены ядра и потоки (узнать можно по выводу lscpu -e ), использовать 0, 2, 4 и 6 ядра будет эффективнее, чем 0, 1, 2 и 3.

rx-buffers-increase

Увеличивает RX-буфер сетевой карты. Чем больше буфер - тем больше пакетов за один тик сетевая карта сможет скопировать с помощью DMA в кольцевой буфер в RAM который уже будет обрабатываться процессором.

Для работы после перезагрузки в RHEL-based дистрибутивах (платформа Carbon, CentOS, Fedora итд) укажите в настройках интерфейса, например /etc/sysconfig/network-scripts/ifcfg-eth1 , строчку вида:

autorps

Утилита для распределения нагрузки на сетевых картах с одной очередью. Вычисляет и применяет маску процессоров для RPS, например:

Настройка драйверов сетевых карт для работы в FORWARD/Bridge-режимах

Опции General Receive Offload и Large Receive Offload в таких режимах могут приводить к паникам ядра Linux и их лучше отключать либо при компиляции драйвера, либо на ходу, если это поддерживается драйвером:

Примеры

1. Максимально простой

Параметр	Значение
Число процессоров	1
Ядер	4
Число карт	1
Число очередей	4
Тип очередей	combined
Режим сетевой карты	1 Гбит/сек
Объём входящего трафика	600 Мбит/сек
Объём входящего трафика	350000 пакетов/сек
Максимум прерываний на ядро в секунду	55000
Объём исходящего трафика	0 Мбит/сек
Потери	200 пакетов/сек
Детали	Все очереди висят на CPU0, остальные ядра простаивают

Решение: распределяем очереди между ядрами и увеличиваем буфер:

Параметр	Значение
Максимум прерываний на ядро в секунду	15000
Потери	0
Детали	Нагрузка равномерна

Пример 2. Чуть сложнее

Параметр	Значение
Число процессоров	2
Ядер у процессора	8
Число карт	2
Число портов у карт	2
Число очередей	16
Тип очередей	combined
Режим сетевых карт	10 Гбит/сек
Объём входящего трафика	3 Гбит/сек
Объём исходящего трафика	100 Мбит/сек
Детали	Все 4 порта привязаны к одному процессору

Одну из 10 Гбит/сек сетевых карт перемещаем в другой PCI-слот, привязанный к NUMA node1.

Уменьшаем число combined очередей на каждый порт до числа ядер одного физического процессора (временно, нужно делать это при перезагрузке) и распределить прерывания портов. Ядра будут выбраны автоматически, в зависимости от того к какой NUMA-ноде принадлежит сетевая карта. Увеличиваем сетевым картам RX-буферы:

Необычные примеры

Не всегда всё идёт идеально:

Проблема	Решение
Сетевая карта теряет пакеты при использовании RSS.	1 RX-очередь для захвата на CPU0, а обработка на остальных ядрах: autorps --cpus 1,2,3,4,5 eth0
У сетевой карты несколько очередей, но 99% пакетов обрабатывается одной очередью	Причина в том, что у 99% трафика одинаковый хэш, такое бывает при использовании QinQ, Vlan, PPPoE и во время DDoS атак. Решений несколько: от DDoS защититься ранним DROP трафика, перенести агрегацию VLAN на другое оборудование, сменить сетевую карту, которая учитывает Vlan при вычислении хэша для RSS, попробовать использовать RPS
Сетевые карты intel X710 начала работать без прерываний, вся нагрузка висела на CPU0.	Нормальная работа восстановилась после включения и выключения RPS. Почему началось и закончилось - неизвестно.
Некоторые SFP-модули для Intel 82599ES при обновлении драйвера (сборка ixgbe из исходников с sourceforge) “пропадают” из списка сетевых карт и даже флаг unsupported_sfp=1 не помогает. При этом в lspci этот порт отображается, второй аналогичный порт работает, а в dmesg на оба порта одинаковые warning’и.	Не нашлось.
Некоторые драйверы сетевых карт работают с числом очередей только равным степени двойки	Замена сетевой карты или процессора.

Блог Олега Стрижеченко

30% личного, 20% linux, 30% наблюдения за разработкой, 5% книги, 10% математика и статистика, 10% шуток

Эта заметка выросла из шпаргалки для самого себя. Мне по работе приходится отлавливать баги в сети. Как проверить скорость в VPN-туннеле? Почему сервер не пингуется? Или пингуется, но не доступен. Кто забил весь канал торрентами? Где пропадают пакеты? Почтовый клиент выдает непонятную ошибку, что произошло на самом деле? Эти и многие другие вопросы периодически возникают у любого пользователя. Под катом описание программ входящих во все современные дистрибутивы, начиная от пинга и до таких экзотических как ngrep. А так же картинками, если картинками можно назвать, копии дампа с консоли.

Ключ -n означает, что надо выводить IP адреса вместо доменных имен, это полезно если пингуете по IP, тогда не будет тратится время на разрешение доменого имя, а еще, если DNS сервер не доступен это приведет к паузе в несколько секунд. Ключ -i задает интервал между отправкой пакетов, а -s размер пакета. Размер не может быть больше, чем MTU интерфейса. При помощи комбинации ключей -i и -s можно загрузить канал на любую ширину. -I задает имя интерфейса, через который будет отправлен пакет, полезно, если надо обойти таблицу маршрутизации. Чтобы вывести статистику, как я сделал я после третьего пакета, надо послать пингу сигнал SIGQUIT, с клавиатуры это делается Cntr+\

traceroute

traceroute показывает маршрут до удаленного хоста. По умолчанию он работает довольно медленно, так как опрашивает каждый роутер на пути пакета, по очереди и по три раза. Вы видите три времени ответа рядом с каждым хостом или три звездочки, если он не отвечает. Но traceroute можно ускорить. Ключ -N показывает сколько шагов пути пакета, они называются хопами, найти за 1 цикл, а -q количество запросов, которые будут отправлены к хосту. Ключ -A показывает номер автономной системы. Автономная система — блок IP сетей, выделенных одному оператору.

tcpdump

Иногда полезно глубже заглянуть, что же происходит в сети. Какие пакеты приходят и уходят. Например, чтобы удостовериться, что пакеты все таки уходят, а не блокируются фаерволом.

Вот что происходит при команде

ngrep

Несмотря на всю мощь иногда возможностей tcpdump не хватает, например посмотреть, что происходит внутри пакетов, особенно это актуально для текстовых протоколов, таких как smtp, imap, SIP и тд. Тут на помощь приходит ngrep.
Например, чтобы отловить пакеты идущие с/или на порт 5060, в которых присутствует слово NOTIFY
rt94:

И несколько простых утилиток, про которые нужно знать, что они существуют.
Как узнать, через какую запись в таблице маршрутизации пойдет трафик на IP адрес.

Как посмотреть кто или что забивает канал?
Для этого есть утилита iptraf c интерфейсом основанным на ncurses. При запуске без параметров выводит меню.
Для того, чтобы посмотреть суммарную статистику по интерфейсу
iptraf -d eth0

Для статистики по соединениям
iptraf -i eth0

Например у вас есть VPN туннель. Как проверить его ширину? Самый простой способ это утилита iperf. На одном хосте запускаем ее с ключем -s это будет сервер, который повиснет по умолчанию на порт 5001. С другой стороны запускаем с единственным параметром — адресом нашего сервера.

mii-tool

За рамками обзора остались nmap и hping. Жду в камментах ссылки на другие полезные программы. Может имеет смысл перенести в какой-нибудь подходящий блог?

Недавно я столкнулся с потерей UDP-пакетов серверного приложения. В процессе расследования я проверил много информации и резюмировал эту статью для большего количества людей.

Перед тем как начать, давайте воспользуемся рисунком, чтобы объяснить процесс приема сетевых пакетов системой Linux.

Прикладная программа считывает пакеты из буфера сокета для обработки.

В процессе приема UDP-пакетов любой процесс на рисунке может активно или пассивно отбрасывать пакеты, поэтому потеря пакетов может произойти в сетевой карте и драйвере или в системе и приложении.

В этой статье предполагается, что на машине есть только один интерфейс с именем eth0. Если имеется несколько интерфейсов или имя интерфейса не eth0, проанализируйте его в соответствии с реальной ситуацией.

Подтвердите, что есть потеря пакетов UDP

Чтобы проверить, есть ли потеря пакетов на сетевой карте, вы можете использовать ethtool -S eth0 Посмотреть, найти в выводе bad Или drop Независимо от того, есть ли данные в соответствующих полях, при нормальных обстоятельствах все числа, соответствующие этим полям, должны быть равны 0. Если вы видите, что соответствующее число увеличивается, это означает, что сетевая карта потеряла пакеты.

Кроме того, система Linux также предоставляет информацию о потерях пакетов для каждого сетевого протокола, который можно использовать. netstat -s Командный вид, плюс --udp Вы можете просматривать только пакетные данные, относящиеся к UDP:

Для приведенного выше вывода обратите внимание на следующую информацию, чтобы проверить потерю пакетов UDP:

● Ошибки приема пакетов не пустые и продолжают увеличиваться, указывая на то, что в системе есть потеря пакетов UDP.
Полученные пакеты на неизвестный порт означают, что целевой порт UDP-пакета, полученного системой, не отслеживается приложением, что обычно вызвано тем, что служба не запущена, и не вызывает серьезных проблем.
Ошибки буфера приема указывают на количество пакетов, потерянных из-за слишком маленького буфера приема UDP.

NOTE: Дело не в том, что количество потерянных пакетов не равно нулю. Для UDP, если есть небольшое количество потерянных пакетов, это, вероятно, будет ожидаемым поведением. Например, коэффициент потери пакетов (количество потерянных пакетов / количество полученных пакетов) составляет 1 из 10 000 Еще ниже.

Сетевая карта или потеря пакетов драйвера

Как я уже сказал, если ethtool -S eth0 В rx_***_errors Тогда вполне вероятно, что существует проблема с сетевой картой, из-за которой система теряет пакеты, и вам необходимо связаться с сервером или поставщиком сетевой карты для обработки.

Если нет проблем с оборудованием или драйвером, общая потеря сетевой карты связана с тем, что кольцевой буфер слишком мал, вы можете его использовать. ethtool Команда для просмотра и установки кольцевого буфера сетевой карты.

ethtool -g Вы можете проверить кольцевой буфер определенной сетевой карты, например, в следующем примере

Pre-set представляет собой максимальное значение кольцевого буфера сетевой карты, которое можно использовать. ethtool -G eth0 rx 8192 Установите его значение.

Потеря пакетов в системе Linux

Ошибка пакета UDP

Если пакет UDP изменяется во время передачи, это вызовет ошибку контрольной суммы или неправильную длину. Linux проверит это при получении пакета UDP. После обнаружения ошибки пакет будет отброшен.

Если вы хотите, чтобы контрольная сумма UDP-пакета отправлялась прикладной программе при возникновении ошибок во времени, вы можете отключить проверку контрольной суммы UDP с помощью параметра сокета:

Если системный брандмауэр отбрасывает пакеты, обычно все UDP-пакеты не могут быть приняты нормально.Конечно, вероятность того, что брандмауэр отбрасывает только часть пакетов, не исключает.

Если вы столкнулись с очень большим коэффициентом потери пакетов, сначала проверьте правила брандмауэра, чтобы убедиться, что брандмауэр не отбрасывает пакеты UDP.

Размер буфера UDP недостаточен

На системном уровне linux устанавливает максимальный конфигурируемый буфер приема, который можно просмотреть в следующем файле: Как правило, linux устанавливает начальное значение в соответствии с размером памяти при запуске.

● / proc / sys / net / core / rmem_max: максимальное значение буфера приема, которое может быть установлено
/ Proc / sys / net / core / rmem_default: значение буфера приема, используемое по умолчанию
● / proc / sys / net / core / wmem_max: максимально допустимый буфер отправки
● / proc / sys / net / core / wmem_dafault: максимальный буфер отправки, используемый по умолчанию.

Однако эти начальные значения не предназначены для работы с UDP-пакетами с большим потоком. Если приложение получает и отправляет много UDP-пакетов, вам необходимо увеличить это значение. Вы можете использовать команду sysctl, чтобы она вступила в силу немедленно:

Также может быть изменен /etc/sysctl.conf Соответствующие параметры сохраняют параметры в силе при следующем запуске.

Еще один параметр, который можно настроить: netdev_max_backlog , Он представляет количество пакетов, которые ядро Linux может буферизовать после чтения пакетов из драйвера сетевой карты. По умолчанию - 1000. Это значение может быть увеличено, например, до 2000:

Высокая загрузка ЦП, памяти и ввода-вывода может вызвать потерю сетевых пакетов. Например, если загрузка ЦП слишком высока, система не успевает выполнить вычисление контрольной суммы пакета, копирование памяти и другие операции, что приведет к потере пакетов с сетевой карты или буфера сокета;

Если загрузка памяти слишком высока, прикладная программа будет обрабатывать слишком медленно и не сможет обрабатывать пакеты вовремя;

Нагрузка ввода-вывода слишком высока, ЦП используется для ответа на ожидание ввода-вывода, и нет времени для обработки пакетов UDP в кэше.

Сама система linux является взаимосвязанной системой, и любая проблема с одним компонентом может повлиять на нормальную работу других компонентов.

Поскольку загрузка системы слишком высока, либо проблема с приложением, либо система недостаточна. Для первых необходимо обнаруживать, отлаживать и исправлять вовремя; для вторых также необходимо обнаруживать и расширять во времени.

Потеря пакета приложения

Размер буфера UDP системы, упомянутой выше, скорректированный параметр sysctl - это только максимум, разрешенный системой, каждое приложение должно установить собственное значение размера буфера сокета при создании сокета.

Что касается первого вопроса, вы можете установить размер приемного буфера сокета, когда приложение инициализирует сокет. Например, следующий код устанавливает размер буфера сокета на 20 МБ:

setsockopt(socket_fd, SOL_SOCKET, SO_RCVBUF, &receive_buf_size, sizeof(receive_buf_size));

Если вы не пишете и не обслуживаете свою собственную программу, то изменять код приложения нецелесообразно или даже невозможно.

Многие приложения предоставляют параметры конфигурации для настройки этого значения; обратитесь к соответствующим официальным документам; при отсутствии доступных параметров конфигурации вы можете только сообщить о проблеме разработчику программы.

Очевидно, что увеличение буфера приема приложения снизит вероятность потери пакетов, но в то же время заставит приложение использовать больше памяти, поэтому используйте это с осторожностью.

Если вы хотите узнать больше о потере пакетов, когда система Linux выполняет какую функцию, вы можете использовать dropwatch Tool, он отслеживает информацию о потере пакетов в системе и распечатывает адрес функции, по которому произошла потеря пакета:

С помощью этой информации вы можете найти соответствующий код ядра, узнать, на каком шаге ядро отбросило пакет, и приблизительную причину потери пакета.

В Интернете есть много статей по использованию и интерпретации команды perf.

Когда приложение обрабатывает UDP-пакеты, оно должно работать в асинхронном режиме, и между получением пакетов не должно быть слишком много логики обработки.

Эта статья предоставлена партнерами сообщества Yunqi "Эффективная эксплуатация и обслуживание"можно обратить внимание на актуальную информацию" Эффективная эксплуатация и обслуживание ”。

Читайте также: