Сетевой тюнинг Linux для веб‑нагрузки: somaxconn, tcp_fin_timeout и rmem_wmem

Инструкции
22 окт, 2025
Время на чтение: ~14 мин
Автор: AI (GPT 5)

Искусственный интеллект

Данная статья была создана с использованием искусственного интеллекта (GTP-5). Пожалуйста, имейте в виду, что текст может содержать неточности или ошибки.

Когда веб‑проект растёт, стандартные настройки сети в Linux быстро перестают быть оптимальными. Очередь прослушивания, таймауты завершения TCP и размеры буферов напрямую влияют на пропускную способность, задержки и устойчивость к всплескам. В этой статье разбираем три ключевых блока: somaxconn и связанный с ним backlog, таймаут tcp_fin_timeout и набор параметров rmem/wmem (включая tcp_rmem/tcp_wmem). Всё — с упором на практический тюнинг для веб‑нагрузки, воспроизводимые команды и критерии успешности.

Как Linux принимает входящие соединения: короткая модель

Чтобы правильно крутить somaxconn и backlog, важно понимать, что происходит, когда клиент стучится к вашему порту:

Half-open очередь (SYN backlog): хранит полуоткрытые соединения после получения SYN до завершения трёхстороннего рукопожатия. Её верхний предел регулируется net.ipv4.tcp_max_syn_backlog, а также эффективностью обработки прерываний и RTO.
Accept queue (listen backlog): очередь завершённых соединений, ожидающих, когда приложение вызовет accept(). Её верхний предел — минимум из значения, которое передал процесс в listen(backlog), и системного net.core.somaxconn.
Ingress backlog: если ядро не успевает разбирать пакеты с сетевой карты, используется net.core.netdev_max_backlog. Это уже более низкоуровневая часть стека, но при экстремальной нагрузке она тоже важна.

Если слушающая очередь переполнена, ядро начнёт отбрасывать входящие соединения. Клиенты увидят задержки с последующими таймаутами или мгновенные ошибки, а вы — рост метрик ListenDrops/ListenOverflows.

somaxconn и backlog: где узкое место

somaxconn — системный потолок для длины очереди уже установленных, но ещё не принятых приложением соединений. Даже если сервер (например, Nginx) попросит очень большой backlog в системном вызове listen(), ядро ограничит его до somaxconn. Поэтому всегда думайте о них как о связке.

Как посмотреть текущие значения и нагрузку

sysctl -n net.core.somaxconn
sysctl -n net.ipv4.tcp_max_syn_backlog
ss -lnt
ss -s
awk '/ListenOverflows|ListenDrops/ {print}' /proc/net/netstat

Полезная интерпретация:

ss -s покажет накопительную статистику по TCP, включая состояние очередей.
/proc/net/netstat содержит пары ключей и значений; особенно нас интересуют TcpExt: ListenOverflows и ListenDrops. Рост этих счётчиков под нагрузкой — сигнал, что backlog/somaxconn мало или приложение не успевает accept().

Практические значения

Исторически многие дистрибутивы имели низкие дефолты (порядка 128). Для веб‑нагрузки разумно поднимать somaxconn до тысяч или даже десятков тысяч в зависимости от профиля. Но просто «крутить до упора» бессмысленно — если приложение не успевает вычитывать соединения, очередь останется полной, а задержки вырастут.

# осторожный старт для активного фронтенда
sysctl -w net.core.somaxconn=4096
sysctl -w net.ipv4.tcp_max_syn_backlog=8192

Затем дайте реальную нагрузку и следите за ListenOverflows/ListenDrops, латентностью и 99‑й перцентилью TTFB. Если сбросы исчезли, а задержки не выросли — оставляйте значения. Если очередь всё ещё переполняется — повышайте ступенчато.

Связь с настройками приложения

Серверы умеют указывать желаемый backlog на уровне сокета. Например, в Nginx:

# фрагмент nginx.conf
# директива listen может принимать параметр backlog
# пример: увеличиваем очередь для порта 80
listen 0.0.0.0:80 backlog=65535;

Помните: фактический предел = min(backlog, somaxconn). То есть нет смысла ставить в приложении backlog=65535, если somaxconn — 4096. Про устойчивые keepalive‑соединения в апстримах — см. руководство Keepalive для upstream в Nginx.

Если вы разворачиваете сервис на собственном сервере, такие настройки доступны полностью. На общем хостинге системные sysctl обычно недоступны, поэтому для тонкого тюнинга выбирайте VDS.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

tcp_fin_timeout: ускоряем уборку без потерь

tcp_fin_timeout управляет тем, сколько времени ядро держит сокет в состоянии FIN‑WAIT‑2 для соединений, закрытых нашей стороной и не привязанных к пользовательскому процессу. Если значение слишком велико, при бурстовой нагрузке будут накапливаться «висящие» записи, расходуя память и таблицы. Слишком маленькое значение — риск разорвать соединение до того, как медленный клиент дочитает ответ.

Частые вопросы возникают из‑за путаницы с TIME_WAIT. На веб‑фронтендах TIME_WAIT — нормальное состояние, защищающее от старых дублей сегментов. Её укорачивание не должно идти вразрез со стандартами. В современном ядре лучше оставить управление TIME_WAIT по умолчанию и не трогать агрессивные и устаревшие опции (вроде давно удалённого tcp_tw_recycle).

rmem/wmem и TCP‑автотюнинг: когда и зачем увеличивать

Параметры net.core.rmem_* и net.core.wmem_* задают пределы для сокетных буферов (receive/send), а net.ipv4.tcp_rmem и net.ipv4.tcp_wmem содержат триплеты: минимальный, дефолтный и максимальный размер буфера для TCP. Современный стек Linux умеет динамически увеличивать окна, но не превысит ваши максимумы. Поэтому при высоком BDP (широкий канал с большим RTT) стоит поднять верхние лимиты, иначе загрузки «не разгоняются».

Проверка и аккуратное повышение

sysctl -n net.core.rmem_max
sysctl -n net.core.wmem_max
sysctl -n net.ipv4.tcp_rmem
sysctl -n net.ipv4.tcp_wmem

Умеренный старт для фронтендов и сценариев «много мелких ответов»:

sysctl -w net.core.rmem_max=262144
sysctl -w net.core.wmem_max=262144
sysctl -w net.ipv4.tcp_rmem="4096 87380 262144"
sysctl -w net.ipv4.tcp_wmem="4096 65536 262144"

Для раздачи крупных файлов на клиентов с высоким RTT (например, международный трафик):

sysctl -w net.core.rmem_max=8388608
sysctl -w net.core.wmem_max=8388608
sysctl -w net.ipv4.tcp_rmem="4096 2097152 8388608"
sysctl -w net.ipv4.tcp_wmem="4096 1048576 8388608"

Следите за общей памятью: агрессивные лимиты на больших RPS увеличивают суммарное потребление RAM на сокетные буферы. Тестируйте под реалистичным RPS и конкаренси. Для внешнего мониторинга задержек и успешности подключений посмотрите Blackbox‑пробы HTTP/TCP/ICMP.

План безопасного тюнинга и отката

Соберите базу: снимите текущие значения sysctl, зафиксируйте метрики RPS, p95/p99 латентности, ошибки и overflow/drops из /proc/net/netstat.
Подготовьте конфиг: сделайте отдельный файл, например /etc/sysctl.d/99-web-tuning.conf, и применяйте его траншем, а не точечно.
Применяйте по шагам: сначала somaxconn и tcp_max_syn_backlog, затем tcp_fin_timeout, и уже потом rmem/wmem. Между шагами — нагрузочное тестирование.
Фиксируйте эффект: исключения ListenOverflows/ListenDrops должны уйти, латентность — не вырасти, потребление памяти — остаться в разумных пределах.
План отката: храните прошлый конфиг рядом и в случае деградации верните его одной командой.

Шаблон файла настроек

# /etc/sysctl.d/99-web-tuning.conf
# Очереди входящих соединений
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 8192

# Таймаут FIN-WAIT-2 (осторожно с очень низкими значениями)
net.ipv4.tcp_fin_timeout = 20

# Буферы TCP: умеренные лимиты для веб-фронтенда
net.core.rmem_max = 262144
net.core.wmem_max = 262144
net.ipv4.tcp_rmem = 4096 87380 262144
net.ipv4.tcp_wmem = 4096 65536 262144

Применение и проверка:

sysctl --system
sysctl -a | grep -E "somaxconn|tcp_max_syn_backlog|tcp_fin_timeout|tcp_.*mem|rmem|wmem"

Чеклист и команды sysctl для тюнинга сети

Как понять, что именно упирается

Overflow/Drop растут, p99 TTFB скачет, CPU в норме — вероятно, не хватает somaxconn/backlog или приложение медлит с accept().
Много SYN‑RECV в ss -ant и медленный прогресс до ESTABLISHED — проверьте tcp_max_syn_backlog и задержки в сети.
Море FIN‑WAIT‑2 — пересмотрите tcp_fin_timeout и поведение приложения при закрытии сокетов.
Высокие RTT и недоиспользованный канал при скачиваниях — увеличьте верхние лимиты tcp_rmem/tcp_wmem и rmem_max/wmem_max.

Антипаттерны и мифы

«Поставлю backlog побольше — и всё починится». Нет. Если приложение не успевает accept(), то вы лишь растянете очередь и задержки. Смотрите профилирование воркеров и сетевые прерывания.
Агрессивное уменьшение таймаутов. Слишком низкий tcp_fin_timeout может резать медленных клиентов. Двигайтесь постепенно.
Отключение TCP timestamps. Это может мешать расчёту RTO и взаимодействию с расширениями. Дефолт обычно разумен.
Устаревшие твики. Опции вроде tcp_tw_recycle давно удалены. Не используйте рецепты из старых постов без проверки на актуальность ядра.

Мониторинг, который поможет

Срез TCP: ss -s и выборочные выборки по состояниям через ss -ant 'state ...'.
Переполнения очередей: читайте /proc/net/netstat, пары ListenOverflows и ListenDrops. Дополнительно полезны SynRetransmits и прочие поля TcpExt.
Буферы: следите за общей памятью и сокетной статистикой. При росте лимитов rmem/wmem проверяйте RSS процесса и свободную RAM.

Готовые профили (от них удобно отталкиваться)

Профиль «Стандартный фронтенд»

Подойдёт для большинства сайтов и API, если нет экстремальных RTT и больших скачиваний.

net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_fin_timeout = 20
net.core.rmem_max = 262144
net.core.wmem_max = 262144
net.ipv4.tcp_rmem = 4096 87380 262144
net.ipv4.tcp_wmem = 4096 65536 262144

Профиль «Раздача крупных файлов и высокий RTT»

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

net.core.somaxconn = 8192
net.ipv4.tcp_max_syn_backlog = 16384
net.ipv4.tcp_fin_timeout = 30
net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
net.ipv4.tcp_rmem = 4096 2097152 8388608
net.ipv4.tcp_wmem = 4096 1048576 8388608

Профиль «Шторм пиков»

Если трафик приходит волнами (например, флэш‑раскрутка), задача — не терять соединения в пики. Важно убедиться, что приложение и веб‑сервер масштабированы.

net.core.somaxconn = 16384
net.ipv4.tcp_max_syn_backlog = 32768
net.ipv4.tcp_fin_timeout = 20
net.core.rmem_max = 524288
net.core.wmem_max = 524288
net.ipv4.tcp_rmem = 4096 262144 524288
net.ipv4.tcp_wmem = 4096 131072 524288

Сопутствующие факторы, о которых часто забывают

Квоты дескрипторов: увеличьте fs.file-max и лимиты в systemd/ulimit, иначе вы упрётесь в открытые файлы раньше, чем в сеть.
Прерывания и очереди NIC: настройте распределение IRQ по CPU и RPS/XPS, иначе узким местом станет обработка пакетов.
Веб‑сервер: проверьте worker_processes, worker_connections и режимы accept, чтобы он успевал опустошать accept‑очередь.
Защита от SYN‑флуда: убедитесь, что net.ipv4.tcp_syncookies включен. Это не панацея, но полезный базовый уровень.

Чеклист перед продакшн‑включением

Снята база метрик и сделана нагрузочная репетиция.
Подключен файл /etc/sysctl.d/99-web-tuning.conf, применён через sysctl --system.
Параметры увеличивались ступенчато, за каждым шагом — измерения.
После изменения somaxconn/backlog фиксируем, что ListenOverflows/ListenDrops не растут.
После изменения tcp_fin_timeout нет жалоб на обрывы при медленных загрузках.
После изменения rmem/wmem память в пределах бюджета; латентность не ухудшилась.

Главная мысль: тюнинг сети — это не «магические числа», а управляемый процесс с измерениями до и после. Начинайте с очередей (somaxconn/backlog), затем корректируйте таймауты и буферы, оценивая эффекты на реальной нагрузке.

Двигаясь по этому плану, вы снимете внезапные потери соединений, стабилизируете tail‑латентность и подготовите фронтенд к всплескам трафика без лишних рисков.

Поделиться статьей