2010-02-28 5 views
19

Может быть максимальное количество одновременных клиентов (с использованием другого номера порта), которые могли бы связываться с сервером на одном и том же порту (один сокет)? Каковы факторы, которые могут повлиять на этот счет? Я ищу эту информацию w.r.t telnet в среде Linux.Максимальное количество одновременных подключений на одном порту (сокете) сервера

ответ

26

Это зависит частично от операционной системы.

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

Следует помнить, что TCP-соединение уникально, а соединение представляет собой пару конечных точек (локальный и удаленный IP-адрес и порт), поэтому не имеет значения, подключено ли 1000 подключений к одному и тому же порту на сервере потому что соединения все еще уникальны, потому что другой конец отличается.

Другой недостаток, который следует знать, заключается в том, что машина может производить только исходящие соединения в 64 КБ или ограничение ядра на соединениях, в зависимости от того, что меньше. Это потому, что порт представляет собой неподписанное 16-битное число (0-65535), и каждое исходящее соединение использует один из этих портов.

Вы можете расширить это, предоставив машине дополнительные IP-адреса. Каждый IP-адрес - это еще одно адресное пространство с адресами 64K.

+0

Еще одна вещь, которая стоит упомянуть - это диапазон эфемерного порта для клиентской стороны. –

+0

Продолжая мой поиск, я приземлился в приведенной ниже ссылке по BSD, которая дает некоторые полезные советы о kern.maxfiles, поскольку каждый открытый файл, сокет или fifo использует один файловый дескриптор, а крупномасштабный производственный сервер может легко потребовать много тысяч файловые дескрипторы, в зависимости от вида и количества одновременно работающих сервисов - http://www.freebsd.org/doc/handbook/configtuning-kernel-limits.html Не играет ли быстрая ссылка? Я думаю, это также играет здесь важную роль. –

+0

Итак, кажется, что файловые дескрипторы являются одним из основных факторов, определяющих количество параллельных подключений на конкретном порту на сервере в Linux. Ниже приведена ссылка на способ увеличения максимального количества файловых дескрипторов в Linux - http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/ http://www.cs.uwaterloo.ca/~brecht/servers/openfiles.html –

3

Больше, чем вы заботитесь. Или скорее.

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

Я могу гарантировать, что это больше, чем все из них. Существуют ограничения масштабируемости с большим количеством сокетов, с которыми можно работать (Google для проблемы c10k). На практике возможно иметь более 10 000 сокетов, полезных для одного процесса в Linux. Если на сервере имеется несколько процессов, вы можете увеличить это снова.

Нет необходимости использовать один порт, так как ваши выделенные балансировочные балансиры смогут объединять несколько портов, если это необходимо.

Если вы используете службу для многих 10-ти тысяч клиентских процессов, вероятно, довольно важно, чтобы она продолжала работать, поэтому вам понадобятся несколько серверов для резервирования ANYWAY. Поэтому у вас не будет проблем с развертыванием еще нескольких серверов.

+1

Интересно знать, что балансировочные нагрузки будут выполнять циклические серверные порты! –

+0

В одной системе (Linux) можно легко использовать сотни тысяч (были они доступны) сокетов. Определенно все доступные. Вы делаете неверные допущения. – lucian303

-2

Я провел тестирование в Windows, выполнив несколько соединений loopback на один сокет. Windows отказалась выделить что-либо после отметки 16372.

+6

Соединения с петлями имеют свои ограничения. Во-первых, клиентская ОС обычно использует только эфемерные порты в определенном диапазоне (и, следовательно, будет создавать только определенное количество из них). Для других соединений с 127.0.0.1 (обратный адрес) обычно используют один и тот же адрес источника (а именно 127.0.0.1) для всех из них. Вам придется явно привязать локальный конец к другому адресу, чтобы обойти эти ограничения. – cHao