Как открывать много TCP соединений и поддерживать их?

Question

[Eugene Usachev]

У меня есть некий кластер. Он может быть огромных размеров. Каждый компьютер должен открыть своё соединение с каждым другим компьютером в кластере. Более того, каждый компьютер также должен поддерживать соединения с клиентами. Сейчас я упираюсь не столько в производительность, сколько в порты.

Как обойти ограничение на количество портов? Не возникнут ли у меня проблемы с сокетами уже после установки их максимального количества за сотни тысяч? Достаточно ли использовать обычную асинхронность (например, от Tokio) для поддержки такого количества соединений? Есть ли ещё какие-нибудь "подводные камни" в этом вопросе?

Comments

[pfg21]

в кластере выделить один компьютер под обмен данными :)
неполносвязанная сеть. форму подбери по вкусу.
непонятна цель данной мудрености.

[Eugene Usachev]

pfg21, мне тяжело принять такое решение. Вариант с выделением дополнительно компьютера увеличивает задержки и уменьшает пропускную способность, причём очень сильно. С другой стороны, я не вижу способа обойти ограничения сейчас. Поэтому я обратился сюда, чтобы попробовать найти способ обойтись без столько медленного решения.

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

Eugene Usachev, то есть огромный кластер на несколько тысяч машин, где каждая общается с каждой - это сверх быстро?

[Eugene Usachev]

Сергей Соловьев, в идеале, конечно, поставить один суперкомпьютер с процессором на где-то миллион ядер и с где-то 70 ТБ оперативной памяти и шардировать приложение по одному потоку на каждое ядро, где каждый поток самодостаточен. Но в реальности приходится шардироваться на нескольких машинах. Мне очень интересно узнать, как реализовать кластер быстрее, чем через общение каждой машины с каждой. Но поддержание открытых соединений стоит мало, а использования дополнительных компьютеров в этой схеме порождает слишком много дополнительных IO операций, что дороже.

Если вы можете хотя бы дать намёк, как это сделать быстрее, я буду благодарен.

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

Eugene Usachev, чтобы понять как решать, надо сначала понять что решать

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

Eugene Usachev,
- Scatter/Gather паттерн - есть мастер машина, отдающая задачи другим узлам. Они эти задачи выполняют и отдают ответ мастеру, который эти ответы аккумулирует.
- мультиплексирование соединений
- выделить узлы в группы. в каждой группе есть мастер, через которого производится общение. древовидная структура может получиться
- можно выделить отдельный узел медиатр, к которому будут все подключаться, а он маршрутизировать запрос нужному узлу

[pfg21]

Eugene Usachev, весьма специфическая задача потребует создание такого сложного кластера.
собрание воедино 64512 (если привязывать один порт - один компьютер) отдельных вычислительных нод уже потребует огромной и сложной сетевой обвязки.
у меня мысль что указанную проблему, если она прикладная, можно решить не в лоб, а четко продумав структуру решаемой задачи. редко какие вычислительные системы требуют таких хитрожопых условий.

откуда к примеру именно желание TCP.
к примеру можно слать UDP пакеты. они быстрее и проще TCP.

кстати количество компьютеров в сети никак не связано с количеством портов :)
на один порт может подключиться огромное количество машин. соединения будут четко различаться по параметру source address.

[Wexter]

Eugene Usachev, если не секрет для чего вам отдельный порт для каждого сервера? что мешает к одному порту подключать всех остальных?

[Eugene Usachev]

Wexter, я где-то описался выше? Естественно, каждый сервер имеет один порт. Но проблема то с клиентской точки зрения. Каждый раз, когда я подключаюсь к другому серверу, я должен занять порт. Порты в этой схеме кончаются у клиента.

[Wexter]

Eugene Usachev, у клиента по ~65к портов на подключение к каждому IP адресу. т.е IP1:[1024-65535] - IP2:[1024-65535]. Вам этого мало?

[Eugene Usachev]

pfg21, я был бы рад реализовать сообщение через тот же QUIC, но я ограничен требованиями к проекту. Проект обязан гарантировать пользователю безопасность, и как бы я не пытался объяснить, что UDP тоже может гарантировать доставку сообщений, я не могу победить предубеждение.

[Eugene Usachev]

Wexter, перечитал 3 страницы Гугла. Так и не нашёл подтверждения вашим словам, хотя они звучат логично в контексте ADDR:PORT. Не могли бы вы написать ответ с ссылками (или ссылкой), подтверждающими ваши слова?

[Wexter]

Eugene Usachev, https://habr.com/ru/articles/123154/
https://habr.com/ru/articles/661169/

[Eugene Usachev]

Wexter, спасибо, что прояснили ситуацию. Я не зря попросил вас написать ответ, так как я не могу отметить решением комментарий. Есть ли ещё подводные камни в этом вопросе?

[Zerg89]

Eugene Usachev, есть мысль про ipv6 у которого два набора портов

В IPv6 применяются аналогичные порты. Поскольку в этом протоколе предусмотрено новое семейство адресов, число наборов портов увеличилось до четырех. Например, предусмотрено два порта TCP с номером 80, к которым могут подключаться приложения: один из них находится в AF_INET, а второй - в AF_INET6.

Либо один ip адрес из ipv4 второй из ipv6 и все это на одной сетевой карте

Answer 1

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

Порт задается 16-битным числом, значит максимальное кол-во портов - 65535.
Но нужно помнить, что некоторые порты зарезервированы (первые 1023), другие уже могут использоваться.

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

Тут есть несколько возможных решений:
- Создать древовидную структуру сети, т.е. есть узлы, которые объединяют в себе несколько других (группу) и для отправки ты используешь не порт, а ID узла. Т.е. маршрутизация на стороне приложения
- Если нужно отправлять пакет всем, то задумайся над броадкастом.
- Задать предел для размера кластера, либо кол-ва клиентов

UPD:
1. Асинхронность из rust тут вообще ни о чем - это фича языка. Главное здесь - возможности ОС
2. Такое большое кол-во соединений приведет не только к большому потреблению ресурсов, но и большому кол-ву прерываний. Производительность снизится. Рекомендую пересмотреть архитектуру огромного кластера с полносвязной топологией.

Comments

[Wexter]

Вот только 65535 портов это лимит на подключения между ДВУМЯ адресами (SRC IP - DST IP). Если у человека закончились 65к портов для связи между двумя хостами - проблема не в протоколе

Answer 2

[Дмитрий Беляев]

Как уже написали в соседнем ответе, лимит портов 65535 на 1 интерфейс.
Но это на один интерфейс, самое простое решение тут воткнуть несколько сетевых карт, да у них будут разные ip (по сути у одной машины будет пул ip), но для 100к коннектов хватит 2 карточек.
В Linux (насчет других ОС не уверен, но возможно тоже) есть способы поизвращаться и поднять 2+ виртуальных интерфейса на одной сетевой карте. При этом у машины так же будет 2 ip адреса и нужно будет распределять соединения между ними.

Хотя по хорошему я бы посмотрел здесь в сторону UDP с одним занятым портом на машине, а необходимые возможности TCP уже воспроизводить программно.

Comments

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

я тоже думал над вариантом с различными сетевыми интерфейсами, но меня остановил момент с тем, что в протоколе TCP нет поля указывающего на сетевой интерфейс/карту.
Т.е. как мне казалось порты принадлежат ОС, а не сетевым интерфейсам. Или я не прав и можно один и тот же порт, но на разных сетевых картах использовать?

[Станислав Макаров]

Сергей Соловьев

что в протоколе TCP нет поля указывающего на сетевой интерфейс/карту

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

[Дмитрий Беляев]

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

[Saboteur]

так можно же несколько апишников назначить одной сетевой карточке

[pfg21]

Сетевую карточку можно переключить в "прозрачный режим" и получать все пакеты на любой адрес которые к ней прилетят.
И самому разбирать поле source address

Answer 3

[rPman]

Назначают несколько ip адресов на один интерфейс, и при открытии слушающего сокета, указывают разные ip адреса (обычно указывают 0.0.0.0 - слушать все интерфейсы, но можно указать конкретный). ОС это переваривают корректно.

Подводные камни - большое количество слушающих сокетов тратят ресурсы (ram).

У тебя неправильная архитектура - не нужно делать подключение 'все со всеми', делай граф - 'каждый с некоторыми', уведомления передавай через соседей, а для передачи самих данных уже открывай прямое соединение на это время и отключайся. Таких сетей полно, например dht, bitcoin p2p,...

Answer 4

[Руслан]

При превышении числа в 65535 мой Микротик начинает кидать соединения в оперативную память а дальше все зависет от количества ОЗУ и мощности ЦП тестровал программой Rats on The Boat - BitTorrent search engine

Заметил что Роутеры на чипах Медиатек не умеют работать с большим количеством соединений ( зависают ) еще в некоторых чипах Медиатек есть аппаратный NAT который ужасен а вот на Микротиках все гуд там qualcomm