Centos максимальное количество соединений

Обновлено: 05.07.2024

Какие параметры ядра или другие параметры управляют максимальным количеством сокетов TCP, которые могут быть открыты на сервере Linux? Каковы компромиссы, позволяющие больше подключений?

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

Вот мой тестовый результат:

Вот команда netstat, которую я запускаю во время теста:

Следующим шагом было заставить ядро переработать все эти соединения в состоянии TIME_WAIT , а не удалять пакеты. Я мог бы добиться этого, включив tcp_tw_recycle или увеличив ip_conntrack_max , чтобы быть больше, чем количество локальных портов, доступных для подключений по ip_local_port_range , Я думаю, как только ядро выходит из локальных портов, он начинает перерабатывать соединения. Это использует больше соединений отслеживания памяти, но кажется лучшим решением, чем включение tcp_tw_recycle , поскольку документы подразумевают, что это опасно.

В этой конфигурации я могу запускать ab весь день и никогда не заканчивать соединения:

Значение tcp_max_orphans не повлияло на мои тесты, и я не знаю почему. Я думаю, что он будет закрывать соединения в состоянии TIME_WAIT , если их было 8192, но это не делает для меня.

Вы действительно хотите посмотреть, что файловая система /proc может предложить вам в этом отношении.

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

/proc /sys /net /ipv4 /tcp_max_orphans , который контролирует максимальное количество сокетов, удерживаемых система не привязана к чему-то. При подъеме это может потреблять до 64 кбайт незаменяемой памяти для сиротского сокета .
/proc /sys /net /ipv4 /tcp_orphan_retries , который контролирует количество попыток до того, как сокет будет осиротевших и закрытых. На этой странице есть отдельная заметка о веб-серверах, которые представляют для вас прямой интерес .

Я не думаю, что есть возможность настроить это напрямую. Это относится к категории настройки TCP /IP. Чтобы узнать, что вы можете настроить, попробуйте «man 7 tcp». Для их установки используется sysctl ('man 8 sysctl'). 'sysctl -a | grep tcp 'покажет вам большую часть того, что вы можете настроить, но я не уверен, покажет ли он все из них. Кроме того, если это не изменилось, открываются сокеты TCP /IP, как файловые дескрипторы. Итак это , а следующий раздел в этой ссылке может быть тем, что вы ищете .

Попробуйте установить следующее, а также установить tcp_fin_timeout. Это должно закрыть TIME_WAIT быстрее.

Пакет apache (1) используется для предопределения только для поддержки 250 одновременных подключений. Если вам нужно больше, был изменен один файл заголовка, чтобы разрешить больше параллельных сеансов. Я не знаю, верно ли это с Apache 2.

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

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

Вы можете сократить время, потраченное в состоянии TIME_WAIT (установить net.ipv4.tcp_fin_timeout). Вы можете заменить Apache на YAWS или nginx или что-то подобное.

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

Абсолютное число сокетов, которое может быть открыто на одном IP-адресе, равно 2 ^ 16 и определяется TCP /UDP, а не ядром.

net.ipv4.tcp_max_orphans = 65536

Параметр tcp_fin_timeout определяет время сохранения сокета в состоянии FIN-WAIT-2 после его закрытия локальной стороной. Партнер может не закрыть это соединение никогда, поэтому следует закрыть его по своей инициативе по истечении тайм-аута. По умолчанию тайм-аут составляет 60 секунд. В ядрах серии 2.2 обычно использовалось значение 180 секунд и вы можете сохранить это значение, но не следует забывать, что на загруженных WEB-серверах вы рискуете израсходовать много памяти на сохранение полуразорванных мертвых соединений. Сокеты в состоянии FIN-WAIT-2 менее опасны, нежели FIN-WAIT-1, поскольку поглощают не более 1,5 Кбайт памяти, но они могут существовать дольше.

net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_probes = 5

tcp_keepalive_time Переменная определяет как часто следует проверять соединение, если оно давно не используется. Значение переменной имеет смысл только для тех сокетов, которые были созданы с флагом SO_KEEPALIVE. Целочисленная переменная tcp_keepalive_intvl определяет интервал передачи проб. Произведение tcp_keepalive_probes * tcp_keepalive_intvl определяет время, по истечении которого соединение будет разорвано при отсутствии откликов. По умолчанию установлен интервал 75 секунд, т.е., время разрыва соединения при отсутствии откликов составит приблизительно 11 минут.

net.ipv4.tcp_max_syn_backlog = 4096

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

net.ipv4.tcp_synack_retries = 1

Целочисленное значение (1 байт) tcp_synack_retries определяет число попыток повтора передачи пакетов SYNACK для пассивных соединений TCP. Число попыток не должно превышать 255. Значение 5 соответствует приблизительно 180 секундам на выполнение попыток организации соединения.

Я программирую сервер, и кажется, что мое количество подключений ограничено, поскольку пропускная способность не насыщается, даже если я установил количество подключений как «неограниченное».

Как я могу увеличить или исключить максимальное количество соединений, которые может одновременно открывать мой Ubuntu Linux box? ОС ограничивает это, или это маршрутизатор или провайдер? Или что-то еще?

@Software Monkey: Я все равно ответил на это, потому что надеюсь, что это может пригодиться тому, кто на самом деле пишет сервер в будущем. @derobert: Я видел это +1. На самом деле, у меня была та же мысль после моего предыдущего комментария, но я решил оставить комментарий.

На максимальное количество соединений влияют определенные ограничения как на стороне клиента, так и на стороне сервера, хотя и немного по-разному.

На стороне клиента: увеличьте диапазон эфермального порта и уменьшите tcp_fin_timeout

Чтобы узнать значения по умолчанию:

Диапазон внешних портов определяет максимальное количество исходящих сокетов, которое хост может создать с определенного IP-адреса. fin_timeout Определяет минимальное время эти розетки будет находиться в TIME_WAIT состоянии (непригодным для использования после того , как используется один раз). Обычные системные настройки по умолчанию:

net.ipv4.ip_local_port_range = 32768 61000
net.ipv4.tcp_fin_timeout = 60

Это в основном означает, что ваша система не может постоянно гарантировать больше (61000 - 32768) / 60 = 470 сокетов в секунду. Если вас это не устраивает, вы можете начать с увеличения port_range . Установка диапазона 15000 61000 довольно распространена в наши дни. Вы можете еще больше увеличить доступность, уменьшив fin_timeout . Предположим, что вы делаете оба, вы должны видеть более 1500 исходящих подключений в секунду, с большей готовностью.

Чтобы изменить значения :

Вышесказанное не следует интерпретировать как факторы, влияющие на способность системы устанавливать исходящие соединения в секунду. Но скорее эти факторы влияют на способность системы обрабатывать параллельные соединения устойчивым образом в течение больших периодов «активности».

Значения Sysctl по умолчанию в стандартном окне Linux для tcp_tw_recycle & tcp_tw_reuse будут

Они не разрешают соединение из «используемого» сокета (в состоянии ожидания) и заставляют сокеты длиться полный time_wait цикл. Я рекомендую установить:

На стороне сервера: net.core.somaxconn значение играет важную роль. Это ограничивает максимальное количество запросов в очереди к сокету прослушивания. Если вы уверены в возможностях вашего серверного приложения, увеличьте его значение по умолчанию со 128 до 128 - 1024. Теперь вы можете воспользоваться этим увеличением, изменив переменную listen backlog в вызове listen вашего приложения на равное или большее целое число.

txqueuelen Параметр ваших карт Ethernet также играют свою роль. Значения по умолчанию - 1000, поэтому увеличьте их до 5000 или даже больше, если ваша система справится с этим.

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

Настройка ядра Linux для поддержки большего числа соединений, что обеспечит бесперебойную работу сервера и дополнительную защиту в случае DoS-атак.

Не принимать и не отправлять ICMP-пакеты перенаправления. ICMP-перенаправления могут быть использованы злоумышленником для изменения таблиц маршрутизации. Целесообразно выставить в «0». Единица имеет смысл только для хостов, использующихся в качестве маршрутизаторов.

Целочисленное значение параметра tcp_max_orphans определяет максимальное число допустимых в системе сокетов TCP, не связанных каким-либо идентификатором пользовательского файла (user file handle). При достижении порогового значения “осиротевшие” (orphan) соединения незамедлительно сбрасываются с выдачей предупреждения. Этот порог помогает предотвращать только простые атаки DoS. Не следует уменьшать пороговое значение (скорее увеличить его в соответствии с требованиями системы – например, после добавления памяти. Каждое orphan-соединение поглощает около 64 Кбайт несбрасываемой на диск (unswappable) памяти.

tcp_keepalive_time Переменная определяет как часто следует проверять соединение, если оно давно не используется. Значение переменной имеет смысл только для тех сокетов, которые были созданы с флагом SO_KEEPALIVE . Целочисленная переменная tcp_keepalive_intvl определяет интервал передачи проб. Произведение tcp_keepalive_probes * tcp_keepalive_intvl определяет время, по истечении которого соединение будет разорвано при отсутствии откликов. По умолчанию установлен интервал 75 секунд, т.е., время разрыва соединения при отсутствии откликов составит приблизительно 11 минут.

Векторная (минимум, режим нагрузки, максимум) переменная в файле tcp_mem содержит общие настройки потребления памяти для протокола TCP. Эта переменная измеряется в страницах (обычно 4Кб), а не байтах.

Минимум: пока общий размер памяти для структур протокола TCP менее этого количества страниц, операционная система ничего не делает.

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

Максимум: максимальное количество страниц памяти, разрешенное для всех TCP сокетов.

Векторная (минимум, по умолчанию, максимум) переменная в файле tcp_rmem содержит 3 целых числа, определяющих размер приемного буфера сокетов TCP.

Минимум: каждый сокет TCP имеет право использовать эту память по факту своего создания. Возможность использования такого буфера гарантируется даже при достижении порога ограничения (moderate memory pressure). Размер минимального буфера по умолчанию составляет 8 Кбайт (8192).

Значение по умолчанию: количество памяти, допустимое для буфера передачи сокета TCP по умолчанию. Это значение применяется взамен параметра /proc/sys/net/core/rmem_default , используемого другими протоколами. Значение используемого по умолчанию буфера обычно (по умолчанию) составляет 87830 байт. Это определяет размер окна 65535 с заданным по умолчанию значением tcp_adv_win_scale и tcp_app_win = 0 , несколько меньший, нежели определяет принятое по умолчанию значение tcp_app_win .

Максимум: максимальный размер буфера, который может быть автоматически выделен для приема сокету TCP. Это значение не отменяет максимума, заданного в файле /proc/sys/net/core/rmem_max . При “статическом” выделении памяти с помощью SO_RCVBUF этот параметр не имеет значения.

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

Минимум: каждый сокет TCP имеет право использовать эту память по факту своего создания. Размер минимального буфера по умолчанию составляет 4 Кбайт (4096)

Значение по умолчанию: количество памяти, допустимое для буфера передачи сокета TCP по умолчанию. Это значение применяется взамен параметра /proc/sys/net/core/wmem_default , используемого другими протоколами и обычно меньше, чем /proc/sys/net/core/wmem_default . Размер принятого по умолчанию буфера обычно (по умолчанию) составляет 16 Кбайт (16384)

Максимум: максимальное количество памяти, которое может быть автоматически выделено для буфера передачи сокета TCP. Это значение не отменяет максимум, заданный в файле /proc/sys/net/core/wmem_max . При “статическом” выделении памяти с помощью SO_SNDBUF этот параметр не имеет значения.

Целочисленной значение tcp_orphan_retries определяет число неудачных попыток, после которого уничтожается соединение TCP, закрытое на локальной стороне. По умолчанию используется значение 7, соответствующее приблизительно периоду от 50 секунд до 16 минут в зависимости от RTO. На сильно загруженных WEB-серверах имеет смысл уменьшить значение этого параметра, поскольку закрытые соединения могут поглощать достаточно много ресурсов.

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

Максимальное количество соединений для работы механизма connection tracking (используется, например, iptables). При слишком маленьких значениях ядро начинает отвергать входящие подключения с соответствующей записью в системном логе.

Разрешает временные метки протокола TCP. Их наличие позволяет управлять работой протокола в условиях серьезных нагрузок (см. tcp_congestion_control ).

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

Протокол, используемый для управления нагрузкой в сетях TCP. bic и cubic реализации, используемые по умолчанию, содержат баги в большинстве версий ядра RedHat и её клонов. Рекомендуется использовать htcp.

Не сохранять результаты измерений TCP соединения в кэше при его закрытии. В некоторых случаях помогает повысить производительность.

Актуально для ядер 2.4. По странной причине в ядрах 2.4, если в рамках TCP сессии произошел повтор передачи с уменьшенным размером окна, все соединения с данным хостом в следующие 10 минут будут иметь именно этот уменьшенный размер окна. Данная настройка позволяет этого избежать.

Активируем защиту от IP-спуфинга.

Запрещаем маршрутизацию от источника.

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

Разрешаем повторное использование TIME-WAIT сокетов в случаях, если протокол считает это безопасным.

Разрешаем динамическое изменение размера окна TCP стека

Защищаемся от TIME_WAIT атак.

Запрещаем переадресацию пакетов, поскольку мы не роутер.

Не отвечаем на ICMP ECHO запросы, переданные широковещательными пакетами.

Можно вообще не отвечать на ICMP ECHO запросы (сервер не будет пинговаться)

Максимальное число открытых сокетов, ждущих соединения. Имеет смысл увеличить значение по умолчанию, для высоко-нагруженных серверов советуют значения в районе 15000-20000.

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

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