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’а не будет.

Источник

Увеличение максимального количества соединений TCP / IP в Linux

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

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

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

На стороне клиента: увеличьте диапазон эфермального порта и уменьшите 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 цикл. Я рекомендую установить:

Это позволяет быстро переключать сокеты в time_wait состояние и повторно использовать их. Но перед тем, как вы сделаете это изменение, убедитесь, что оно не конфликтует с протоколами, которые вы используете для приложения, которому нужны эти сокеты. Обязательно прочитайте пост «Как справиться с TCP-TIME-WAIT» от Винсента Берната, чтобы понять последствия. Эта net.ipv4.tcp_tw_recycle опция довольно проблематична для общедоступных серверов, поскольку она не будет обрабатывать соединения от двух разных компьютеров за одним и тем же устройством NAT , что является проблемой, которую трудно обнаружить и которая ждет вас. Обратите внимание, что net.ipv4.tcp_tw_recycle было удалено из Linux 4.12.

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

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

Аналогичным образом увеличьте значения для net.core.netdev_max_backlog и net.ipv4.tcp_max_syn_backlog . Их значения по умолчанию 1000 и 1024 соответственно.

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

Помимо вышесказанного, еще одна популярная техника, используемая программистами, заключается в сокращении количества вызовов tcp-записи . Я предпочитаю использовать буфер, в который я помещаю данные, которые я хочу отправить клиенту, а затем в соответствующих точках записываю буферизованные данные в реальный сокет. Этот метод позволяет мне использовать большие пакеты данных, уменьшить фрагментацию, уменьшить загрузку процессора как на уровне пользователя, так и на уровне ядра.

Источник

Одминский блог

Блог о технологиях, технократии и методиках борьбы с граблями

Подсчет одновременных сетевых сессий в 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

Источник

Сколько TCP соединений можно поднять на линуксе ?

Интерисует максимальный предел.
Соединений имеется в виду конешно одновременно.
и можно ли этот лимит, если он есть, как-то изменить,
в практической задаче необходимо около 100-200 тысяч соединений

Re: Сколько TCP соединений можно поднять на линуксе ?

listen() — для этого и предназначена почитай про нее man а что касается настроек сокета, то это если не ошибаюсь getsockopt() в man тоже она есть

Re: Сколько TCP соединений можно поднять на линуксе ?

>Сколько TCP соединений можно поднять на линуксе ? >Интерисует максимальный предел. >Соединений имеется в виду конешно одновременно.

на сколько хватит файловых дескрипторов

>и можно ли этот лимит, если он есть, как-то изменить,

в 2.4 ето жёсткий лимит. В 2.6 возможно можна

>в практической задаче необходимо около 100-200 тысяч соединений

По моему на один процесс — никак. На несколько процессов — не знаю.

Re: Сколько TCP соединений можно поднять на линуксе ?

меня интерисуют системные лимиты
listen(SO_MAXCONN)
и setrlimit(RLIMIT_NOFILE)
это известно и понятно

Re: Сколько TCP соединений можно поднять на линуксе ?

Я в свое время столкнулся с ограничением, что 1024 сокетов могут быть открыты одновременно одним процессом. Это лечится, используя fork, т.е. accept порождает сокет — этот сокет предается функции, которая fork’ом запускается, как отдельный процесс. Сама функция должна только читать или писать в из сокета, и после завершения этих операций нужно закрыть сокет, созданный accept и завершать exit() и можно return. Но необходимо перед завершением передать данные с помощью IPC другой функции. Если операция с данными не критичны по времени, то можно обработку этих данных производить в этой функции, тогда использовать IPC не понадобится.

В этом случае, необходимо, как-то различать данные кому они предназначены.

Re: Сколько TCP соединений можно поднять на линуксе ?

Простите, я может быть чего-то не понимаю, но как мне видится TCP-соединение подразумевает захват процессом конкретного порта, а их всего 65535, т.к. порт занимает ровно 2 байта. Далее, одновременно с каждым портом может быть связан только 1 процесс, к тому определенное кол-во портов уже зарезервировано для стандартных служб и сервисов. Итого, свободными остаются уж ни как не 100 тыс. и тем более не 200 тыс., а ★★★★★ ( 24.01.05 21:47:41 )

Re: Сколько TCP соединений можно поднять на линуксе ?

Из расчета на 1 сетевой интерфейс естественно.

Источник

Что ограничивает максимальное количество подключений на сервере 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 быстрее.

Источник