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

количество сетевых соединений в Linux

Здравствуй, ЛОР. От чего зависит количество сетевых соединений в Linux, и каково его максимальное число. Объясни, ЛОРик. Пока мне кажется что это связано со значением в /proc/sys/fs/file-max.

/proc/sys/fs/file-max — это максимальное количество одновременно открытых файлов.

А за соедиения отвечает /proc/sys/net/ipv4/tcp_max_syn_backlog

Maximal number of remembered connection requests, which are still did not receive an acknowledgment from connecting client. Default value is 1024 for systems with more than 128Mb of memory, and 128 for low memory machines. If server suffers of overload, try to increase this number.

Гм, а разве сокеты это не теже файлы?

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

Короче, виноват, ответил не на тот вопрос, который был задан. А так да, максимальное количество установленных соединений упирается в fs/file-max.

Хорошо, тогда за что именно будет отвечать tcp_max_syn_backlog если у нас file-max есть? А может вообще суть моего вопроса упирается в параметры из ulimit -a?

Что-то совсем запутался, ЛОРик.

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

tcp_max_syn_backlog это количество запомненных запросов на соединение, которые ожидают хендшейка.

Иными словами, это лимит полуоткрытых соединений.

забей на /proc/sys/net/ipv4/tcp_max_syn_backlog. ты правильно понял чем лимитируется кол-во открытых сокетов, больше вроде-бы ничем. есть еще лимиты per-process, задаются через ulimit.

tcp_max_syn_backlog это количество запомненных запросов на соединение, которые ожидают хендшейка.

Насколько я понимаю, при использовании syncookies никакого baclog’а не будет.

Источник

Что ограничивает максимальное количество подключений на сервере Linux?

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

Я заметил, что при загрузке сервера Apache с ab , что довольно легко довести до максимума открытые соединения на сервере. Если вы оставите опцию -k ab, которая позволяет повторно использовать повторное использование и отправить более 10 000 запросов, Apache обслуживает первые 11 000 запросов, а затем останавливается на 60 секунд. Взгляд на вывод netstat показывает 11 000 соединений в состоянии TIME_WAIT. По-видимому, это нормально. Соединения остаются открытыми по умолчанию в течение 60 секунд даже после того, как клиент будет с ними связан для причин надежности TCP .

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

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

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

8 ответов

Наконец-то я нашел настройку, которая действительно ограничивала количество подключений: net.ipv4.netfilter.ip_conntrack_max . Это было настроено на 11 776, и все, что я установил, это количество запросов, которые я могу выполнить в своем тесте, прежде чем ждать tcp_fin_timeout секунд, чтобы увеличить количество подключений. Таблица conntrack — это то, что ядро ​​использует для отслеживания состояния соединений, поэтому, когда оно заполнено, ядро ​​начинает отбрасывать пакеты и печатать их в журнале:

Следующим шагом было заставить ядро ​​переработать все эти соединения в состоянии 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 быстрее.

Источник

Русские Блоги

Решить ограничение максимального числа одновременных соединений сокетов под Linux, TCP по умолчанию 1024 соединения

В последнее время при подключении к промежуточному программному обеспечению Memcached всегда возникает следующая ошибка:

[18-11-9 12:10:59:156 CST] 0000014b SystemOut O 2018-11-09 12:10:59 156 [ERROR][Heal-Session-Thread][com.google.code.yanf4j.core.impl.AbstractController] SessionMonitor connect error
java.net.SocketException: слишком много открытых файлов
at sun.nio.ch.Net.socket0(Native Method)
at sun.nio.ch.Net.socket(Net.java:529)
at sun.nio.ch.Net.socket(Net.java:512)
at sun.nio.ch.SocketChannelImpl. (SocketChannelImpl.java:122)
at sun.nio.ch.SelectorProviderImpl.openSocketChannel(SelectorProviderImpl.java:73)
at java.nio.channels.SocketChannel.open(SocketChannel.java:154)
at net.rubyeye.xmemcached.impl.MemcachedConnector.connect(MemcachedConnector.java:508)
at net.rubyeye.xmemcached.impl.MemcachedConnector$SessionMonitor.run(MemcachedConnector.java:127)

Позже было обнаружено, что допустимого количества сокетов, установленных на стороне сервера, было недостаточно. По умолчанию в Linux разрешено только 1024 запроса на подключение. Обратитесь к соответствующим документам в интернете, вам нужно установить это значение немного больше.

По умолчанию ulimit системы linux имеет доступ 1024. Максимальное количество программ, которые пользователи могут открыть. Как правило, самое высокое соединение порта от 2 до 16-го уровня 65535

С помощью этой команды ulimit -n вы можете увидеть значение по умолчанию 1024

• Первым шагом является изменение файла /etc/security/limits.conf, добавление в файл следующей строки (* относится к имени пользователя системы), изменение мягких и жестких ограничений на количество открытых файлов для пользователей в системе Linux:

soft nofile 65535

hard nofile 65535

• Второй шаг — изменить файл /etc/pam.d/login и добавить в него следующую строку:

session required /lib/security/pam_limits.so

Если это 64-битная система, она должна быть:

session required /lib64/security/pam_limits.so

• Третий шаг — изменение файла /etc/sysctl.conf. В этом файле (очистите исходное содержимое файла (или добавьте его на исходной основе, я сделал это)) добавьте следующую строку (измените ограничения ядра сети для соединений TCP ):

• Четвертый шаг — выполнить следующую команду (чтобы вышеуказанные настройки вступили в силу):

• Пятый шаг — выполнить следующую команду (после оптимизации системы Linux сеть должна увеличить количество открытых файлов для поддержки большого параллелизма, и по умолчанию 1024 недостаточно):

• Шестой шаг — перезагрузить компьютер (когда я поэкспериментирую, он вступит в силу без перезапуска, поэтому этого шага следует избегать).

Благодаря модификации tcp может достигать 65536 соединений без каких-либо проблем.

С помощью этой команды ulimit -n вы можете видеть, что значение изменено на 65536, что означает, что теперь поддерживается не более 65536 соединений через сокет TCP.

Посмотрите, сколько TCP-соединений в настоящее время подключено к текущей серверной команде:

Источник

Что ограничивает максимальное количество соединений на сервере Linux?

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

Во время нагрузочного тестирования сервера Apache с ab я заметил, что довольно просто максимально увеличить количество открытых соединений на сервере. Если вы отключите опцию ab’s -k, которая разрешает повторное использование соединения, и отправит более 10 000 запросов, то Apache будет обрабатывать первые 11 000 запросов или около того, а затем останавливается на 60 секунд. Просмотр вывода netstat показывает 11 000 соединений в состоянии TIME_WAIT. Видимо, это нормально. Соединения остаются открытыми по умолчанию в течение 60 секунд даже после того, как клиент покончит с ними по соображениям надежности TCP .

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

Вот мой тестовый вывод:

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

Я наконец -то нашел установку , которая была действительно ограничивающее количество соединений: net.ipv4.netfilter.ip_conntrack_max . Для этого было установлено значение 11 776, и все, что я установил, — это количество запросов, которые я могу обслуживать в своем тесте, прежде чем придется ждать tcp_fin_timeout несколько секунд, чтобы стало доступным больше подключений. conntrack Таблица является то , что ядро использует для отслеживания состояния соединения , так как только она полна, ядро начинает падать пакетов и печать этого в журнале:

Следующим шагом было заставить ядро ​​перерабатывать все эти соединения в 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 , который контролирует количество попыток, прежде чем сокет будет потерян и закрыт. На этой странице есть отдельная заметка о веб-серверах, которая вас непосредственно интересует .

Источник

Настройка Linux для высоконагруженных проектов и защиты от DDoS

// 16 декабря, 2013 | 83444 просмотров

В Интернете довольно много разных примеров конфигурации ядра Linux для поддержания большого количества соединений, высоконагруженных веб проектов и противодействия DDoS-атакам. Вот ещё один из примеров, что я уже смог попробовать на практике. Скажу сразу — мне более чем помогло. Попробуйте и вы.

Вот опции, что необходимо добавить в конец /etc/sysctl.conf

А теперь о каждой опции более детально.

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

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

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

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

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

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

Векторная (минимум, режим нагрузки, максимум) переменная в файле tcp_mem cодержит общие настройки потребления памяти для протокола 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 стека

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

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

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

Не отвечаем на ошибочно сформированные сообщения

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

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

Размер буфера приема данных по умолчанию для всех соединений.

Размер буфера передачи данных по умолчанию для всех соединений.

Максимальный размер буфера приема данных для всех соединений.

Максимальный размер буфера передачи данных для всех соединений.

Источник