Сетевой стек Linux по умолчанию: какие пять параметров стоит трогать, а какие двадцать — нет

MAATRIX

Рано или поздно в поисках «как ускорить сервер на Linux» вы натыкаетесь на форумный пост десятилетней давности со списком из двадцати-тридцати sysctl-параметров net.*, которые предлагается скопировать в /etc/sysctl.conf целиком и применить sysctl -p. Логика заманчивая: один файл, одна команда — и сервер якобы «летит». На практике большинство параметров из таких списков не имеют отношения к вашей нагрузке, часть — карго-культ из эпохи ядра 2.6, а некоторые способны сделать хуже, потому что нынешние дефолты уже давно настроены под типичный случай тысячами инженеров по всему миру. Разберёмся, какая логика должна стоять за изменением сетевых параметров ядра, какие категории реально стоит рассматривать на большинстве серверов, а какие лучше не трогать вообще без ясного понимания конкретной проблемы.

Почему чек-листы sysctl обычно приносят вред

Дефолтные значения net.* — не случайный набор чисел, а результат многолетней настройки под общий случай. Автотюнинг буферов TCP появился в ядре ещё в середине 2000-х: ядро само расширяет окно приёма/отправки в зависимости от реальной пропускной способности и задержки соединения, без вашего участия. syncookies, разумные лимиты backlog, консервативный rp_filter — всё это годами проверялось сообществом на живом трафике в интернете, а не в лаборатории одного блогера.

Проблема копипасты в том, что список собирался для чужой ситуации. Условный пост про тюнинг 10-гигабитной карты под потоковое видео кочует из статьи в статью, обрастая чужими добавлениями «на всякий случай» — и к вам попадает набор, где часть строк относится к железу, которого у вас нет, часть — к параметрам, переименованным или выпиленным в новых ядрах (просто молча игнорируется), а часть реально меняет поведение, но непредсказуемо для вашей нагрузки.

Конкретные риски:

• Непроверенный эффект. Никто не измерял «до» и «после» — вы не знаете, какая строка помогла, какая навредила, а какая ни на что не повлияла.
• Ослабление защиты ради мнимой производительности. Отключение tcp_syncookies или ослабление rp_filter под предлогом «меньше накладных расходов» почти никогда не даёт измеримого выигрыша, зато объективно расширяет поверхность атаки.
• Память под чужое железо. Огромные значения буферов или таблицы conntrack, скопированные с 32-ядерного сервера со 128 ГБ RAM, на скромной VPS могут вытеснить полезные данные и привести к нехватке памяти под нагрузкой — тема того, как сетевые лимиты связаны с характеристиками виртуалки, разобрана отдельно.
• Конфликты параметров. Часть настроек логически связана (буферы и window scaling, backlog ядра и backlog приложения) — изменение одной без понимания другой может не дать эффекта или сдвинуть узкое место в другое место цепочки.

Сначала симптом, потом гипотеза, потом параметр

Правильный порядок обратный тому, что предлагают чек-листы: сначала измеримый симптом, потом гипотеза о причине, и только затем точечное изменение одного параметра с проверкой эффекта. «Хочу, чтобы сервер работал быстрее» — не симптом, это пожелание, под которое подгоняется любой список.

netstat -s | grep -iE 'retrans|overflow|drop|failed'   # ретрансмиссии, переполнения, отказы
ss -s                                                    # сводка по сокетам
ss -ltn                                                  # текущие очереди слушающих сокетов
dmesg -T | grep -iE 'tcp|drop|overflow'                  # события ядра

Карта «что видите → что изучать»:

Если ни один симптом не воспроизводится — лучшее действие с сетевым стеком по умолчанию это ничего не делать.

Буферы приёма и отправки: когда каналу правда не хватает окна

Это категория, где вмешательство оправдано чаще других — но при конкретном условии: длинный канал с большой задержкой и высокой пропускной способностью (long fat network). Классика — репликация базы между RU и US, резервное копирование в удалённое хранилище, синхронизация между нодами через дальний туннель.

Речь о net.core.rmem_max, net.core.wmem_max, net.ipv4.tcp_rmem, net.ipv4.tcp_wmem — они задают границы, в которых ядро автоматически подбирает размер окна под конкретное соединение. Автотюнинг работает хорошо, пока верхняя граница не становится узким местом: если произведение пропускной способности на задержку (bandwidth-delay product, BDP) превышает потолок буфера, окно физически не может раскрыться настолько, чтобы утилизировать канал — вне зависимости от мощности процессора и сетевой карты.

Как посчитать нужный потолок через задержку и пропускную способность конкретного маршрута — подробно в статье про TCP-окно и длинный толстый канал. Коротко: измеряете задержку (ping) и пропускную способность (iperf3 между вашими же серверами, не синтетика «в интернет»), считаете BDP и поднимаете потолок с небольшим запасом — а не берёте эталонное число из чужого поста, потому что у вас другой маршрут и другое число параллельных соединений.

Оговорка про побочный эффект: каждое соединение с раскрытым большим окном резервирует под себя больше памяти ядра. На сервере с тысячами одновременных соединений завышенный потолок, скопированный «для скорости», на пике может съесть заметный объём RAM — и вместо ускорения одного дальнего канала вы получите деградацию остальных из-за нехватки памяти.

Backlog: очередь новых соединений при высокой частоте подключений

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

Сюда относятся net.core.somaxconn (максимальная длина accept-очереди), net.ipv4.tcp_max_syn_backlog (очередь незавершённых по трёхстороннему рукопожатию соединений) и параллельно — backlog на уровне приложения (listen ... backlog=N у nginx, аналогичный параметр у systemd socket unit). Момент, который упускают чек-листы: поднимать somaxconn без синхронного поднятия backlog в конфиге приложения бессмысленно — эффективным будет минимум из двух значений.

Как устроены SYN- и accept-очереди, что означают счётчики netstat -s при переполнении и как читать ss -ltn — в статье про предел backlog и потерянные подключения.

На обычной VPS с невысокой частотой подключений дефолтный backlog почти никогда не становится узким местом — трогать его без диагностированного переполнения смысла нет. А вот сервер, открывающий тысячи новых соединений в секунду (за балансировщиком с большим числом бэкендов, на пике всплеска трафика), реально может упереться в очередь — клиент получает connection refused или соединение молча теряется, хотя CPU не загружен. Важно: увеличение backlog без ускорения обработки в приложении (accept()) не решает проблему, а лишь откладывает момент отказа — настоящая причина обычно в производительности самого приложения.

TIME_WAIT и повторное использование портов: полезно, но с оговоркой

Третья категория — для серверов с очень большим количеством коротких соединений, особенно исходящих. TIME_WAIT — не утечка, а защитный механизм: сокет держится некоторое время после закрытия, чтобы гарантированно отбросить запоздавшие дублирующиеся пакеты и не спутать их с новым соединением на той же паре адрес:порт. Побочный эффект — на сервере с массой коротких исходящих соединений (прокси, шлюз к внешнему API, микросервис с высокой частотой обращений к соседу) число сокетов в TIME_WAIT может вырасти настолько, что закончится диапазон эфемерных портов.

Сюда относятся net.ipv4.ip_local_port_range, net.ipv4.tcp_tw_reuse (разрешает повторно использовать TIME_WAIT-сокет для нового исходящего соединения при включённых TCP-таймстампах) и net.ipv4.tcp_fin_timeout. Разбор реального инцидента с исчерпанием портов, с конкретными счётчиками — в статье про 28 тысяч соединений в TIME_WAIT.

Здесь нужна прямая оговорка о риске — именно в этой категории чек-листы чаще советуют опасное. Параметр tcp_tw_recycle давно удалён из современных ядер: он ломал соединения клиентов за NAT, потому что несколько клиентов за одним внешним адресом путались друг с другом из-за проверки таймстампов. Если он всё ещё встречается в чек-листе — сигнал, что список не актуализировался годами, и доверять остальным его пунктам не стоит. tcp_tw_reuse безопаснее и годами используется в продакшене, но касается только исходящих соединений и предполагает включённые таймстампы — прежде чем включать, стоит понимать эту границу, а не переносить параметр вслепую с сервера, где он решал другую задачу. Если сервер преимущественно принимает соединения, а не открывает тысячи исходящих сам — эта группа параметров почти никогда не становится узким местом.

Congestion control: смена алгоритма — это эксперимент, а не твик

Алгоритм управления перегрузкой (net.ipv4.tcp_congestion_control) определяет, как быстро TCP наращивает скорость отправки и как реагирует на признаки перегрузки канала:

sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control

CUBIC — алгоритм по умолчанию в большинстве дистрибутивов — не случайный выбор: он проверен на огромном разнообразии реальных маршрутов интернета и хорошо сбалансирован между агрессивностью и справедливостью к другому трафику на том же канале. BBR регулярно преподносят как «универсальный апгрейд для скорости», но это не безусловное правило: поведение сильно зависит от конкретного маршрута, глубины буферов на промежуточных узлах и от того, конкурирует ли BBR-поток с CUBIC-потоками за один и тот же узкий канал — в такой смешанной конкуренции результат не всегда предсказуем в пользу BBR.

Разбор конкретных измерений на реальных маршрутах, с честным описанием, где BBR выигрывал, а где нет — в статье BBR против CUBIC на реальных маршрутах.

Практический вывод: эта категория — «трогать редко, только с измерением». Смена алгоритма без тестирования на вашем собственном трафике — это эксперимент со случайным исходом, а не гарантированное ускорение. Меняйте алгоритм только когда есть конкретная гипотеза (например, канал с известной высокой задержкой и потерями, где CUBIC заведомо слишком консервативен) и возможность сравнить метрики до и после на реальной нагрузке.

Что не стоит трогать вообще без явной причины

Защита от типовых сетевых атак. tcp_syncookies, net.ipv4.conf.all.rp_filter, accept_redirects/send_redirects, icmp_echo_ignore_broadcasts — результат многолетней проверки сообществом на реальных атаках в интернете. Отключение любого из них «ради производительности» почти никогда не даёт измеримого выигрыша, зато расширяет поверхность атаки. Законное исключение — rp_filter при асимметричной маршрутизации на многоинтерфейсном сервере, но это требует чёткого понимания конкретной топологии, а не слепого отключения строгого режима.

Экзотика под чужое железо и редкий edge-case. Многие параметры из чек-листов писались под конкретное оборудование или редкий сценарий: тюнинг под карты с множеством аппаратных очередей, обход проблем конкретных версий драйверов. На типичной VPS или выделенном сервере эти параметры либо не применимы физически, либо не дают эффекта, но создают у следующего инженера ложное ощущение «здесь уже всё настроено» — хотя часть строк мёртвый груз, а часть вовсе не существует в текущем ядре и молча пропускается sysctl -p с предупреждением.

Сводно, без претензии на исчерпывающий список — конкретный симптом всегда важнее любой таблицы:

Главный практический вывод один: меняйте один параметр за раз, измеряйте эффект на реальной нагрузке до и после, документируйте каждое изменение. Держите не безымянный /etc/sysctl.conf с двадцатью строками, а структурированный файл вроде /etc/sysctl.d/99-custom.conf, где на каждый параметр — комментарий с датой, причиной и ссылкой на замер:

# 2026-08: подняли потолок буфера под репликацию БД в US-регион,
# BDP посчитан по замеру ping+iperf3 между нашими нодами, тикет INFRA-142
net.ipv4.tcp_rmem = 4096 131072 8388608
net.ipv4.tcp_wmem = 4096 131072 8388608

Медленнее, чем скопировать чужой список за пять минут — но именно так результат можно объяснить, воспроизвести и осознанно откатить, а не гадать, какая из двадцати строк виновата.

Частые вопросы