Перевод инструкции для тюнинга сетевых интерфейсов
#### NIC Ring Buffers - число буферов для передачи и приёма.
Кольцевые буферы, совместно используются драйвером устройства и сетевой картой. TX – есть передача данных, а RX – получение данных в кольцевом буфере. Как следует из названия, переполнение буфера просто перезаписывает существующие данные. Есть два способа переместить данные от сетевой карты до ядра: аппаратные прерывания и программные прерывания, названные SoftIRQs.
Кольцевой буфер RX используется, чтобы сохранить входящие пакеты, пока они не могут быть обработаны драйвером устройства. Драйвер устройства опустошает буфер RX, обычно через SoftIRQs, который помещает входящие пакеты в структуру данных ядра, названную sk_buff или «skb», чтобы начать свой путь через ядро и до приложения, которому принадлежит соответствующий сокет. Кольцевой буфер TX используется для хранения исходящих пакетов, которые предназначенные для отправки по проводам.
Эти кольцевые буферы находятся у основания стека и являются критическим моментом, в который может произойти удаление (drop) пакетов, что негативно влияет на производительность сети.
```shell
ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 256
RX Mini: 0
RX Jumbo: 0
TX: 256
```
В ситуации когда трафик создается маленькими пакетами то требуется увеличить размеры буферов rx и tx:
```shell
ethtool -G eth0 rx tx 2048
```
#### Interrupts and Interrupt Handlers
Прерывания от аппаратных средств известны как прерывания «top-half».
Сетевые карты, как правило, работают с кольцевыми буферами (DMA ring buffer) организованными в памяти, разделяемой с процессором. Каждый входящий пакет размещается в следующем доступном буфере кольца. (DMA - Direct Memory Access (Прямой доступ к памяти) — режим обмена данными между устройствами или же между устройством и основной памятью, в котором центральный процессор (ЦП) не участвует). После этого требуется сообщить системе о появлении нового пакета и передать данные дальше, в специально выделенный буфер (Linux выделяет такие буферы для каждого пакета). Для этой цели в Linux используется механизм прерываний: прерывание генерируется всякий раз, когда новый пакет поступает в систему. Чаще используется отложенные прерывания (см. в статье Linux, принципы работы с сетевой подсистемой ). В ядро Linux начиная с версии ядра 2.6 был добавлен так называемый NAPI (New API), в котором метод прерываний сочетается с методом опроса. Сначала сетевая карта работает в режиме прерываний, но как только пакет поступает на сетевой интерфейс, она регистрирует себя в poll-списке и отключает прерывания. Система периодически проверяет список на наличие новых устройств и забирает пакеты для дальнейшей обработки. Как только пакеты обработаны, карта будет удалена из списка, а прерывания включатся снова.
Жесткие прерывания можно увидеть в /proc/interrupts, где у каждой очереди есть vector прерывания в 1-м столбце. Каждой очереди RX и TX присвоен уникальный vector, который сообщает обработчику прерываний, относительно какого NIC/queue пришло прерывание. Столбцы представляют количество входящих прерываний:
```shell
egrep "CPU0|eth0" /proc/interrupts
CPU0 CPU1 CPU2 CPU3
...
45: 0 0 0 0 PCI-MSI-edge eth0
46: 0 0 0 0 PCI-MSI-edge eth0-rx-0
47: 0 0 0 0 PCI-MSI-edge eth0-rx-1
48: 0 0 0 0 PCI-MSI-edge eth0-rx-2
49: 0 0 0 0 PCI-MSI-edge eth0-rx-3
50: 0 0 0 0 PCI-MSI-edge eth0-tx-0
51: 0 0 0 0 PCI-MSI-edge eth0-tx-1
52: 0 0 0 0 PCI-MSI-edge eth0-tx-2
53: 0 0 0 0 PCI-MSI-edge eth0-tx-3
```
- Первый столбец — номер прерывания
- CPU0 .. CPUx — счетчик обработанных прерываний
- PCI-MSI-edge — тип прерывания
- Последний столбец — название устройства
Чтобы назначить прерывание на определённое ядро необходимо прописать его номер в файле `/proc/irq/[Номер IRQ]/smp_affinity`:
```shell
echo [значение smp_affinity] >/proc/irq/[номер IRQ]/smp_affinity
```
#### Отложенные прерывания (softirq)
Известны как прерывания «bottom-half», запросы программного прерывания (SoftIRQs), являются подпрограммами ядра, которые планируется запустить в то время, когда другие задачи не должны быть прерваны. Цель SoftIRQ состоит в извлечении данных из кольцевых буферов. Эти подпрограммы, выполненные в форме процессов ksoftirqd/cpu-number и, вызывают специфичные для драйвера функции кода.
После перемещения данных от драйвера к ядру, трафик двигатется вверх к сокету приложения.
SoftIRQs можно контролировать следующим образом. Каждый столбец есть ЦП:
```shell
watch -n1 grep RX /proc/softirq
```
Обработчик аппаратного прерывания запрещает прерывания, выполняет необходимые действия и затем разрешает прерывания. Действия, выполняемые обработчиком, должны занимать как можно меньше процессорного времени. Например, обработчик аппаратного прерывания, являющийся частью драйвера сетевой платы сохраняет пришедший по сети пакет в буфере и завершает свою работу. Всю остальную работу по обработке сетевого пакета, берет на себя программное прерывание.
#### Networking Tools
- netstat
Команда netstat умеет показывать сетевые соединения (входящие/исходящие), таблицу маршрутизации, статистику по сетевым интерфейсам и т.д.
Она извлекает информацию о сетевой подсистеме из /proc/net/ файловой системы. Эти файлы включают в себя:
```shell
/etc/services -- файл трансляции служб
/proc -- Точка монтирования файловой системы proc, которая предоставляет доступ к информации о состоянии ядра через следующие файлы.
/proc/net/dev -- информация об устройствах
/proc/net/raw -- информация о необрабатываемых (raw) сокетах
/proc/net/tcp -- информация о сокетах TCP
/proc/net/udp -- информация о сокетах UDP
/proc/net/igmp -- информация о мультикаст IGMP
/proc/net/unix -- информация о сокетах домена Unix
/proc/net/ipx -- информация о сокетах IPX
/proc/net/ax25 -- информация о сокетах AX25
/proc/net/appletalk -- информация о сокетах DDP (appletalk)
/proc/net/nr -- информация о сокетах NET/ROM
/proc/net/route -- информация об IP-маршрутизации
/proc/net/ax25_route -- информация об AX25-маршрутизации
/proc/net/ipx_route -- информация об IPX-маршрутизации
/proc/net/nr_nodes -- список узлов NET/ROM
/proc/net/nr_neigh -- соседи NET/ROM
/proc/net/ip_masquerade -- NAT-соединения
/proc/net/snmp -- статистика
```
- dropwatch
Мониторинг операций отбрасывания сетевых пакетов данных на уровне ядра ОС
- ip
Позволяет выполнять настройку сетевой подсистемы и является заменой таких утилит, как ifconfig, route, arp.
- ethtool
Отображает или позволяет изменить настройки сетевой карты
- /proc/net/snmp
Файл, который отображает данные ASCII, необходимые для IP, ICMP, TCP, UDP и управления информацией базы для snmp агента. Он также отображает в режиме реального времени статистические данные UDP-lite
- sysctl
Rоманда, предназначенная для управления параметрами ядра на лету. Позволяет читать и изменять параметры ядра. Например - такие параметры как размер сегмента разделяемой памяти, ограничение на число запущенных процессов, а также включать функции наподобие маршрутизации.
```shell
sysctl net.ipv4.tcp_sack
net.ipv4.tcp_sack = 1
```
#### Определение узких мест в сети
Отбрасывание пакетов и переполнени границ (packet drops и overruns) обычно происходит, когда буфер RX сетевой карты не может достаточно быстро опустошиться ядром. Когда скорость, с которой данные поступают из сети превышает скорость, с которой ядро забирает на обработку пакеты, сетевая карта начинает отбрасывать входящие пакеты, т.к. буфер NIC (сетевой карты) полон, и увеличивает счетчик удаления.Соответствующий счетчик можно увидеть в ethtool статистике. Основные критерии здесь - прерывания и SoftIRQs.
Пакеты теряются, когда переполняется RX буффер. Для того чтобы смотреть статистику используйте `ethtool` поле `rx_*_errors`
```shell
ethtool -S eth1
```
Существуют различные инструменты, доступные для поиска проблемной области. Следует исследовать:
1. Уровень встроенного ПО адаптера
- Следим за статистикой ethtool -S ethX
2. Уровень драйвера адаптера
3. Ядро Linux, IRQs или SoftIRQs
- Проверяем /proc/interrupts и /proc/net/softnet_stat
4. Уровни протокола IP, TCP, UDP
- Используем netstat -s и смотрим счетчики ошибок
Примеры узких мест
- неверное распредление прерываний IRQs
Прерывания (IRQs) неправильно сбалансированы. В некоторых случаях служба irqbalance может работать неправильно или не работает вообще. Проверьте /proc/interrupts и удостоверьтесь, что прерывания распределены на разные ядра ЦП. Обратитесь к irqbalance руководству, или вручную сбалансируйте IRQs. В следующем примере прерывания становятся обработанными только одним процессором:
```shell
egrep "CPU0|eth2" /proc/interrupts
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
105: 1430000 0 0 0 0 0 IR-PCI-MSI-edge eth2-rx-0
106: 1200000 0 0 0 0 0 IR-PCI-MSI-edge eth2-rx-1
107: 1399999 0 0 0 0 0 IR-PCI-MSI-edge eth2-rx-2
108: 1350000 0 0 0 0 0 IR-PCI-MSI-edge eth2-rx-3
109: 80000 0 0 0 0 0 IR-PCI-MSI-edge eth2-t
```
- Посмотри, увеличивается ли какая-либо из колонок помимо 1-й колонки в /proc/net/softnet_stat. В следующем примере счетчик большой для CPU0, и budget должен быть увеличен:
```shell
cat /proc/net/softnet_stat
0073d76b 00000000 000049ae 00000000 00000000 00000000 00000000 00000000 00000000 00000000
000000d2 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0000015c 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
```
- SoftIRQs не может получать достаточное количество процессорного времени для опроса адаптера. Используйте инструменты, такие как sar, mpstat или top, чтобы определить, что отнимает много процессорного времени.
- Ипользуй ethtool -S ethX, чтобы проверить определенный адаптер
```shell
ethtool -S eth3
rx_over_errors: 399
rx_fifo_errors: 399
rx_missed_errors: 39
```
- Увеличение приемного буфера сокета приложения или использование буфера автоподстройки.
- ошибки приема UDP
```shell
netstat -su
IcmpMsg:
InType0: 218
InType3: 16704
InType5: 7
InType8: 2
OutType0: 2
OutType3: 3218
OutType8: 304
Udp:
1067183 packets received
2981 packets to unknown port received.
18 packet receive errors
992424 packets sent
InCsumErrors: 18
IgnoredMulti: 1530260
```
- Использование нескольких потоков TCP.
Использование большего числа потоков TCP является более эффективным. Для просмотра потоков, которые использует приложение:
```shell
netstat -neopa
```
- Использование большого/малого TCP или UDP размера пакетов.
Каждый сетевой пакет имеет overhead, такие как загаловки. Отправка данных в большими непрерывными блоками позволит снизить этот overhead.
- Могут быть изменения работы драйвера сетевого интрефейса, после перехода на новое ядро версия Red Hat Enterprise Linux.
#### Настройки производительности
Если выполнение программных прерываний не выполняются достаточно долго, то темп роста входящих данных может превысить возможность ядра опустошить буфер. В результате буферы NIC переполнятся, и трафик будет потерян. Иногда, необходимо увеличить длительность работы SoftIRQs (программных прерываний) с CPU. За это отвечает netdev_budget. Значение по умолчанию 300. Параметр заставит процесс SoftIRQ обработать 300 пакетов от NIC перед тем как отпустить CPU:
```shell
# sysctl net.core.netdev_budget
net.core.netdev_budget = 300
```
Это значение может быть удвоено, если 3-й столбец в /proc/net/softnet_stat увеличивается, что указывает, на то, что SoftIRQ не получил достаточно процессорного времени. Маленькие инкременты нормальны и не требуют настройки.
- tuned
Служба tuned отслеживает использование системных компонентов и динамически изменяет настройки системы, исходя из полученной информации о занятости компонентов в разное время. Так, например, нагрузка на жесткий диск увеличивается во время запуска компьютера и авторизации, но уменьшается в процессе использования приложений пользователя, таких как OpenOffice или почтовых программ. Аналогично может изменяться нагрузка процессора и сетевых устройств.
Установите пакет tuned и соответствующие сценарии systemtap:
```shell
yum install tuned
service tuned start
```
Чтобы запускать tuned каждый раз при загрузке системы, выполните
```shell
chkconfig tuned on
```
- IRQ Balance
Балансировщик прерываний - это сервис, который может автоматически сбалансировать прерывания между ядрами процессора, основанного на реальном времени состояния системы.
Прерывания также можно раскидать по ядрам вручную.
Чтобы это сделать нужно выполнить команду `echo N > /proc/irq/X/smp_affinity`, где N - маска процессора (определяет какому процессору достанется прерывание), а X - номер прерывания, виден в первом столбце вывода /proc/interrupts. Чтобы определить маску процессора, нужно возвести 2 в степень cpu_N (номер процессора) и перевести в шестнадцатиричную систему. При помощи bc вычисляется так: `echo "obase=16; $[2 ** $cpu_N]" | bc`. Например:
```shell
#CPU0
echo 1 > /proc/irq/57/smp_affinity
echo 1 > /proc/irq/66/smp_affinity
#CPU1
echo 2 > /proc/irq/58/smp_affinity
echo 2 > /proc/irq/67/smp_affinity
#CPU2
echo 4 > /proc/irq/59/smp_affinity
echo 4 > /proc/irq/68/smp_affinity
#CPU3
echo 8 > /proc/irq/60/smp_affinity
echo 8 > /proc/irq/69/smp_affinity
```
Пример распределения прерываний:
{% highlight shell linenos %}
#!/bin/bash
# nic_balance.sh
# usage nic_balance.sh <number of cpus>
cpu=0
grep $1 /proc/interrupts|awk '{print $1}'|sed 's/://'|while read a
do
echo $cpu > /proc/irq/$a/smp_affinity_list
echo "echo $cpu > /proc/irq/$a/smp_affinity_list"
if [ $cpu = $2 ]; then
cpu=0
fi
let cpu=cpu+1
done
{% endhighlight %}
- Ethernet flow control
Паузы фреймов - управление потоком уровня Ethernet между адаптером и портом коммутатора. Адаптер передаст "кадры паузы", когда RX или буферы TX станут полными. Коммутатор остановит поток данных в течение определенного промежутка времени в порядке миллисекунд. Этого времени обычно достаточно, чтобы позволить ядру опустошить интерфейсные буферы, таким образом предотвращая переполнение буфера и последующие пакетные отбрасывания или переполнения. В идеале, коммутатор буферизует входящие данные в течение такой паузы.
Однако, важно понимать, что этот уровень контроля потока только между коммутатором и адаптером. Если пакеты отброшены, более высокие уровни, такие как TCP или приложение в случае UDP и/или многоадресно переданы, должен инициировать восстановление.
Важно! Фреймы паузы и flow control (управление потоком) должны быть включены и на NIC и на порте коммутатора.
```shell
ethtool -a eth3
Pause parameters for eth3:
Autonegotiate: off
RX: off
TX: off
```
Для активации Flow Control:
```shell
ethtool -A eth3 rx on
ethtool -A eth3 tx on
```
- Interrupt Coalescence (отложенные прерывания)
Отложенные прерывания рассказывают нам о количестве трафика, который будет получать сетевой интерфейс, или времи, которое проходит после приема трафика, перед выдачей жесткого прерывания. Слишком ранние прерывания или слишком частые приводят к снижению производительности системы, так как ядро останавливается (или «перебивает») запущенное задание для обработки запроса прерывания от аппаратного обеспечения. Слишком поздее прерывание может привести к тому, что пакеты достаточно долго не будут обработаны ядром с сетевой карты. Большие объемы трафика могут переписать предыдущие пакеты трафика, т.е. потеря пакетов.
Самые современные NIC и драйверы поддерживают IC, и многие позволяют драйверу автоматически модерировать количество прерываний, сгенерированных аппаратными средствами. Настройки IC обычно включают два основных компонента, время и количество пакетов. Время в мкс - сколько NIC будет ожидать прежде, чем прервать ядро, а число пакетов – сколько пакетов будет ждать в приемном буфере прежде чем сработает прерывание. Отложенные прерывания NIC можно посмотреть, используя команду `ethtool -c ethX` и настроить через `ethtool -C ethX`. Адаптивный режим позволяет карте автомодерировать IC. В адаптивном режиме, драйвер инспектирует трафик и ядро настраивает прерывания на лету, предотвращая потерю пакетов.
```shell
ethtool -c eth3
Coalesce parameters for eth3:
Adaptive RX: on TX: off
stats-block-usecs: 0
sample-interval: 0
pkt-rate-low: 400000
pkt-rate-high: 450000
rx-usecs: 16
rx-frames: 44
rx-usecs-irq: 0
rx-frames-irq: 0
```
Следующая команда выключает адаптивный IC, и говорит адаптеру о прерывании ядра сразу после приема любого трафика:
```shell
ethtool -C eth3 adaptive-rx off rx-usecs 0 rx-frames 0
```
- Очередь адаптера (The Adapter Queue)
Netdev_max_backlog - очередь в ядре Linux, где трафик хранится после получения от сетевого адаптера, но перед обработкой с помощью стеков протоколов (IP, TCP, и т.д.). Для каждого ядра процессора существует одна очередь. Очередь может расти автоматически до максимального значения, указанного в netdev_max_backlog. Функция ядра netif_receive_skb () находит соответствующий ЦП для пакета и ставит пакеты в очереди того ЦП. Если очередь для этого процессора будет полна и уже в максимальном размере, пакеты будут отброшены. Для того, чтобы тюнить это место необходимо убедиться что оно реально нужно. В /proc/net/softnet_stat в втором столбце есть счетчик, который увеличивается когда очередь переполняется. Каждая строка файла softnet_stat представляет собой ядро процессора, начиная с CPU0.
Следующая система имеет 12-ти ядерный CPU
```shell
# wc -l /proc/net/softnet_stat
12
```
```shell
cat /proc/net/softnet_stat
098f22d5 00000000 00011445 00000000 00000000 00000000 00000000 00000000 00000000 00000000
```
В текущем выводе netdev_max_backlog не нуждается в тюнинге, т.к. очередь не переполняется и нет потерь соответственно. Если же наблюдаются приащения в второй колонке, тогде увеличиваем значение очереди и снова смотрим в этот файл. Если увеличения этого значения мы видим что скорость приращений в втором столбце уменьшается то можно еще увеличить значение backlog. Повторяем этот процесс пока перестанет расти цифры в столбце 2.
Backlog изменить можно такой командой:
```shell
#sysctl -w net.core.netdev_max_backlog=X
```
- Adapter RX and TX Buffer
Буфер адаптера по умолчанию обычно установлен в меньшем размере, чем максимальный. Часто, увеличить размер буфера приема RX вполне достаточно, чтобы предотвратить потери пакетов, так как это может приводит к тому, что у ядра будет немного больше времени, чтобы опустошить буфер. В результате, это может предотвратить возможные потери пакетов.
Буферы можно посмотреть так:
```shell
# ethtool -g eth1
Ring parameters for eth1:
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 256
RX Mini: 0
RX Jumbo: 0
TX: 256
```
- Очередь передачи (Adapter Transmit Queue Length)
Длина очереди передачи определяет количество пакетов, которые могут быть поставлены в очередь перед передачей. Значение по умолчанию 1000 - обычно достаточно для сегодняшней скорости до 10 Гбит/с или даже 40 Гбит/с сетей. Однако, если число ошибок передачи увеличиваются на адаптере, то значение можно удвоить. Используйте ip -slink, чтобы увидеть, если есть какие-то потери на очереди TX для адаптера.
Посмотреть длину очереди передачи:
```shell
# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 52:54:00:cb:f6:61 brd ff:ff:ff:ff:ff:ff
```
Увеличить длину очереди можно так:
```shell
ip link set dev em1 txqueuelen 2000
```
- TCP Window Scaling (масштабирование окна TCP)
Размер TCP окна (TCP Window Size) – количество октетов (начиная с номера подтверждения), которое принимающая сторона готова принять в настоящий момент без подтверждения. На стадии установления соединения рабочая станция и сервер обмениваются значениями максимального размера TCP окна (TCP Window Size), которые присутствуют в пакете. Например, если размер окна получателя равен 16384 байта, то отправитель может отправить 16384 байта без остановки. Принимая во внимание, что максимальная длина сегмента (MSS) может быть 1460 байт, то отправитель сможет передать данный объем в 12 фреймах, и затем будет ждать подтверждение доставки от получателя и информации по обновлению размера окна. Если процесс прошел без ошибок, то размер окна может быть увеличен. Таким образом, реализуется размер скользящего окна в стеке протокола TCP. В современных версиях операционных систем можно увеличить размер окна TCP Window Size и включить динамическое изменение окна в зависимости от состояния канала связи. Динамическое увеличение и уменьшение размера окна является непрерывным процессом в TCP и определяет оптимальный размер окна для каждого сеанса. В очень эффективных сетях размеры окна могут стать очень большими, потому что данные не теряются.
Масштабирование Окна TCP включено по умолчанию:
```shell
# sysctl net.ipv4.tcp_window_scaling net.ipv4.tcp_window_scaling = 1
```
- TCP буфер
После того, как сетевой трафик обрабатывается от сетевого адаптера, предпринимается попытка приема трафика непосредственно в приложение. Если это не представляется возможным, данные ставятся в очередь на буфер сокета приложения. Есть 3 структуры очереди в сокете:
```shell
sk_rmem_alloc = { counter = 121948 },
sk_wmem_alloc = { counter = 553 },
sk_omem_alloc = { counter = 0 },
```
где:
```shell
sk_rmem_alloc – очередь получения
sk_wmem_alloc – очередь передачи
sk_omem_alloc - out-of-order queue
```
Существует также sk_rcvbuf переменная, которая является пределом, измеренный в байтах, что сокет может получить. В этом случае sk_rcvbuf = 125336.
Из приведенного выше вывода можно вычислить, что очередь получения почти полна. Когда sk_rmem_alloc > sk_rcvbuf то буфер начинает рушится, т.е. наблюдаются потери пакетов. Выполните следующую команду, чтобы определить, происодит это или нет:
```shell
# netstat -sn | egrep "prune|collap"; sleep 30; netstat -sn | egrep "prune|collap"
17671 packets pruned from receive queue because of socket buffer overrun
18671 packets pruned from receive queue because of socket buffer overrun
```
Если счетчик обрезки пакетов растет, то требуется тюнинг.
tcp_rmem: У настраиваемой памяти сокета есть три значения, описывающих минимальное, значение по умолчанию и максимальное значения в байтах. Чтобы просмотреть эти настройки и увеличить:
```shell
# sysctl net.ipv4.tcp_rmem
4096 87380 4194304
# sysctl -w net.ipv4.tcp_rmem=“16384 349520 16777216”
# sysctl net.core.rmem_max 4194304
# sysctl -w net.core.rmem_max=16777216
```
TCP Listen Backlog: отвечает за размер очереди одновременно ожидающих подключений к сокету, то есть инициированных (SYN - SYN, ACK - ACK), но еще не принятых сервером (established).
Параметр ядра net.core.somaxconn - максимальное число открытых сокетов, ждущих соединения. Изменяем:
```shell
# sysctl net.core.somaxconn
net.core.somaxconn = 128
# sysctl -w net.core.somaxconn=2048
net.core.somaxconn = 2048
# sysctl net.core.somaxconn
net.core.somaxconn = 2048
```
UDP Buffer Tuning: UDP является гораздо менее сложным, чем протокол TCP. Поскольку UDP не содержит надежности сеанса, он не несет ответственности за повторную передачу потерянных пакетов. Там не существует понятия размера окна и потерянные данные не восстанавливается протоколом. Единственная доступная настройка включает в себя увеличение размера приемного буфера. Если netstat -us показывает “packet receive errors” , попробуйте увеличить число буферов для приема. Буферы UDP могут быть настроены таким образом:
```shell
# sysctl net.core.rmem_max
124928
# sysctl -w net.core.rmem_max=16777216
```