Что ограничивает максимальное количество подключений на сервере 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
Здравствуй, ЛОР. От чего зависит количество сетевых соединений в 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 VDS сервере можно в консоли при помощи системной утилиты netstat. Ниже представлены наиболее часто используемые варианты использования этой команды. Для получения полноценных результатов рекомендуется выполнять эти команды от имени пользователя root, либо от пользователя, который присутствует в списке sudoers на сервере.
Показать все активные сетевые соединения.
Показать и отсортировать все активные соединения на 80-м порту (порт http).
Показать число полуоткрытых соединений (которые в состоянии SYN RECEIVED). Нормальное количество соединений – до 5. Большие значения таких соединений на сервере могут предвещать наличие происходящей SYN-атаки.
Вывести отсортированный список IP-адресов, с которых пришли SYN-пакеты.
Вывести список уникальных IP-адресов, с которых пришли SYN-пакеты.
Вывести результат подсчета количества соединений к серверу с каждого IP-адреса.
Вывести результат подсчета количества соединений с сервером по TCP или UDP протоколам с каждого IP-адреса.
Вывести результат подсчета количества соединений c сервером с каждого IP-адреса, которые в статусе ESTABLISHED (установленные соединения).
Показать список IP-адресов и количество подключений с них к серверу через порт 80, который по умолчанию используется HTTP-протоколом.
Чтобы получить полную справку по использованию утилиты netstat, используйте в консоли команду:
Источник
Одминский блог
Блог о технологиях, технократии и методиках борьбы с граблями
Подсчет одновременных сетевых сессий в Linux
Поднял под клиентов сервер на выделенном гигабите с 40 тысячами IPv6 прокси, под парсинг инстаграмма. Клиент, не долго думая, выдал 100% утилизацию канала, т.ч стало интересно – каким образом можно посчитать количество конкурирующих сессий.
Основной инструментарий для получения сетевой статистики – это команда netstat
Например суммарная статистика по протоколам, доступна в выводе команды:
# netstat -e -s
Если мы хотим увидеть вообще всю статистику, то это можно сделать командой:
# netstat -a
и из неё уже производить выборку через grep по протоколам, установленным соединениям или портам. Например, вывести все установленные соединения:
# netstat -a | grep “ESTABLISHED”
или подсчитать их количество
# netstat -a | grep “ESTABLISHED” | wc -l
статистику по всем протоколам, можно получить командой:
# netstat -s -e
но основная проблема netstat в том, что он перебирает сессии одну за другой и в моем случае, вывода команды можно ждать 5-10 минут.
Поэтому для быстрого просмотра активных сессий, лучше воспользоваться более новой командой сетевой статистики, ss. Например для получения полного количества активных сессий, можно использовать:
# ss -s
Вывод будет практически мгновенным. Даже если подсчитывать число сессий в очереди на подключение, то перебор и вывод будет более шустрым.
# ss -t -a | wc -l
Если надо посмотреть общую статистику, то делается это командой
# ss -s
Источник
Что ограничивает максимальное количество соединений на сервере 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 , который контролирует количество попыток, прежде чем сокет будет потерян и закрыт. На этой странице есть отдельная заметка о веб-серверах, которая вас непосредственно интересует .
Источник
