Как держать больше 65535 одновременных TCP соединений?

Question

[Сергей Соколов]

Хочется одним сервером держать около 150к одновременных WebSocket подключений.

Вдохновился постом про 600к одновременных подключений на Amazon EC2, и постом про нагрузочное тестирование WebSocket'ов Tsung'ом.

Читал, теоретический лимит 65535 – это с одного IP на один IP, порт. Тут подключаться будут с разных IP.

Пробую тестировать на DigitalOcean. Поднял сервер, запустил простейший WS сервер на Swoole, установил Tsung для нагрузочного тестирования.

Поднимаю ещё 3 VPS в качестве «рабочих» – будут бомбить сервер соединениями. Несколько – чтобы с нескольких разных IP.

Но во всех тестах наибольшее число одновременных было всего 65526 – это когда все рабочие были в этом же регионе DigitalOcean. Второй раз попробовал запускать каждого рабочего в отедльном регионе – стало только хуже: около 56к. В остальном отваливались с ошибкой EADDRINUSE.

Где тут узкое место? Сеть DO как-то ограничнивает число подключений к одной виртуалке?

Answer 1

[pfg21]

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

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

Comments

[Сергей Соколов]

общаюсь с их тех.поддержкой. Они сами по ходу дела разбираться пытаются)
Но ведь с Амазоновским EC2 боксом получилось же у кого-то 600к!

[pfg21]

Сергей Соколов, другая система, другие возможности/настройки/тарифы...

Answer 2

[Владимир Дубровин]

В случае входящих соединений, очевидного лимита в 65535 соединений нет, скорей всего вы упретесь в лимит на файловые дискрипторы (сокеты), для каждого соединения нужен сокет. При этом лимиты могут быть на уровне пользовательских лимитов (и надо учесть для сервисов запускаемых через systemd действуют отдельные лимиты, а не те, которые указываются в limits.conf). Обычно по умолчаню лимиты дискрипторов в районе 1024-4096, существенно ниже 65535. Для очень большого количества сокетов необходимо будет так же менять sysctl на максимальное число открытых файлов, а возможно и пересобирать ядро, чтобы обойти заложенные верхние ограничения.

В случае исходящих соединений, вы кроме сокетов упретесь в нехватку эфемерных портов, для каждого исходящего соединения требуется отдельный эфемерный порт. По умолчанию, их в районе 16k и можно расширить до 63k через соответствующие sysctl. Выше этого значения разрешить нехватку портов можно путем добавления дополнительных IP + в зависимости от системы, может потребоваться установка флагов SO_REUSEADDR/SO_REUSEPORT/SO_PORT_SCALABILITY). Как они действуют, и какие комбинации надо использовать зависит не только от системы,но и от версии ядра, попытка разобрать есть здесь:
https://stackoverflow.com/questions/14388706/socke...
Но в случае, если исходящий трафик идет через NAT (в случае виртуализации это почти всегда так), необходимо решать аналогичную проблему на уровне NAT.

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

Answer 3

[galaxy]

Поднимаю ещё несколько VPS'ок в качестве «рабочих»

Несколько - это сколько?
Есть такой sysctl параметер, как net.ipv4.ip_local_port_range - диапазон портов для клиентских соединений (из этого пула присваиваются порты при открытии нового соединение, в котором машина выступает как клиент). По умолчанию он выглядит как-то так: 32768 60999 (т.е. чуть больше 28к доступных портов). Т.е. два рабочих без настройки 150к коннектов никак не сделают (даже с настройкой, т.к. лимит исходящих соединений к одному IP - 65535).

Еще есть несколько параметров, которые влияют на очередь обработки исходящих и входящих соединений. Почитать про них и их настройку можно тут (англ) и тут (рус).
Ну и в статьях, на которые вы сами даете ссылки, есть рекомендации по настройке некоторых параметров (например, ограничения числа файловых дескрипторов).

Comments

[Сергей Соколов]

Пока запускал 3 рабочих. На каждом ставил, как и на сервере в /etc/sysctl.conf:

fs.file-max = 1000000
fs.nr_open = 1000000       
net.ipv4.netfilter.ip_conntrack_max = 1048576
net.nf_conntrack_max = 1048576

и в /etc/security/limits.d/custom.conf:

root soft nofile 1000000
root hard nofile 1000000
* soft nofile 1000000
* hard nofile 1000000

Спасибо, буду сейчас пробовать с увеличенным диапазоном портов.

Полученный лимит, не превышающий 65535 всё-таки заставляет подозревать, что в самом DigitalOcean сетевой "порт" VPS'ки не торчит честно наружу, а прячется за каким-то прокси, из-за чего все входящие в VPS попадают с одного IP адреса.

[galaxy]

все входящие в VPS попадают с одного IP адреса.

Ну это точно нет. Вы же видите на впске source адреса в пакетах, их никто не подменяет.

Почитайте тут, похожая проблема

Answer 4

[Владимир Коротенко]

4 ip в балансировку и держите себе.

Comments

[Сергей Соколов]

это пилить более сложную логику с обменом между нодами. В идеале на одном боксе всё.
Предыдущий похожий проект так и делал: 4 ip, балансировка, 4-5 нод.

[Владимир Коротенко]

Сергей Соколов, Сервер может слушать несколько IP расположенных на одном или нескольких интерфейсах.

Answer 5

[Руслан]

На количество коннектов ограничений нет Это Количество портов 1-65535 ограничения могут быть в роутере,у провайдера,и в операционной системе к примеру процессор и оперативная память роутера не всегда спровляются и с 5000 соединений

Answer 6

[Ярослав]

Вы говорите об ограничении в 64k портов. Оно проявляется, например, в том, что вы не сможете на сервере запустить (на одном IP) больше 64k сетевых сервисов. (ssh слушает порт 22, apache слушает 80, mysql слушает 3306) итд. Каждый слушающий сервис идентифицируется по сокету ( IP + порт), IP у вас один, портов 64k, значит, 64k слушающих сокетов.

А вот для установленных TCP соединений:

socket
An address which specifically includes a port identifier, that
is, the concatenation of an Internet Address with a TCP port.

connection
A logical communication path identified by a pair of sockets.

https://tools.ietf.org/html/rfc793

То есть, соединение идентифицируется по IP сервера, порт сервера, IP клиента, порт клиента.

Да и вы сами на любом более-менее активном веб-сервере видите через lsof множество соединений, и они все установлены с одним вашим сокетом (IP:80 или IP:443), но у них разный второй сокет. Если пользователь, например, качает какой-то файл в два потока, будет один коннект: server:80 - client:4444 и еще один коннект: server:80 - client:4445. Это разные TCP соединения.