Скажем, если бы я получил общий, виртуальный или выделенный хостинг, я где-то читал, что сервер / машина может обрабатывать только 64000 TCP-соединений одновременно, это правда? Сколько может обрабатывать любой тип хостинга независимо от пропускной способности? Я предполагаю, что HTTP работает через TCP.
Означает ли это, что только 64 000 пользователей смогут подключиться к веб-сайту, и если бы я хотел обслуживать больше, мне пришлось бы перейти на веб-ферму?
Вкратце: вы сможете достичь порядка миллионов одновременных активных TCP-соединений и HTTP-запросов по расширению. Это говорит о максимальной производительности, которую вы можете ожидать от правильной платформы с правильной конфигурацией.
Сегодня меня беспокоило, будет ли IIS с ASP.NET поддерживать порядка 100 одновременных подключений (посмотрите мое обновление, ожидайте ~ 10 тыс. Ответов в секунду в более старых версиях ASP.Net Mono). Когда я увидел этот вопрос / ответы, я не смог удержаться от ответа сам, многие ответы на вопрос здесь совершенно неверны.
В лучшем случае
Ответ на этот вопрос должен касаться только простейшей конфигурации сервера, чтобы отделиться от бесчисленных переменных и конфигураций, возможных ниже по течению.
Итак, рассмотрим следующий сценарий моего ответа:
Подробный ответ
Синхронные схемы с привязкой к потоку, как правило, хуже всего работают по сравнению с реализациями асинхронного ввода-вывода.
WhatsApp может обрабатывать миллион С трафиком на одной машине с ОС Unix - https://web.archive.org/web/20120108184257/https://blog.whatsapp.com/index.php/2012/01/1-миллион-is-so-2011/.
И, наконец, этот, http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html, переходит в много деталей, исследуя, как можно достичь даже 10 миллионов. Серверы часто имеют аппаратные механизмы разгрузки TCP, ASIC, предназначенные для этой конкретной роли более эффективно, чем ЦП общего назначения.
Хороший выбор дизайна программного обеспечения
Дизайн асинхронного ввода-вывода будет отличаться для разных операционных систем и платформ программирования. Node.js был разработан с учетом асинхронности. По крайней мере, вы должны использовать Promises, а когда появится ECMAScript 7, _1 _ / _ 2_. C # /. Net уже имеет полную поддержку асинхронного режима, например node.js. Независимо от ОС и платформы, следует ожидать, что асинхронный режим будет работать очень хорошо. И какой бы язык вы ни выбрали, ищите ключевое слово asynchronous, большинство современных языков будут иметь некоторую поддержку, даже если это какое-то дополнение.
На веб-ферму?
Каким бы ни был предел для вашей конкретной ситуации, да, веб-ферма - хорошее решение для масштабирования. Для этого существует множество архитектур. Один из них использует балансировщик нагрузки (хостинг-провайдеры могут предлагать их, но даже у них есть ограничение вместе с потолком пропускной способности), но я не поддерживаю этот вариант. Для одностраничных приложений с длительными соединениями я предпочитаю вместо этого иметь открытый список серверов, которые клиентское приложение будет выбирать случайным образом при запуске и повторно использовать в течение всего жизненного цикла приложения. Это устраняет единую точку отказа (балансировщик нагрузки) и обеспечивает масштабирование через несколько центров обработки данных и, следовательно, гораздо большую пропускную способность.
Развенчание мифа - 64 КБ портов
Чтобы ответить на вопрос, касающийся 64 000, это заблуждение. Сервер может подключаться к более чем 65535 клиентам. См. https://networkengineering.stackexchange.com/questions/48283/is-a-tcp-server-limited-to-65535-clients/48284
Кстати, Http.sys в Windows позволяет нескольким приложениям использовать один и тот же порт сервера в соответствии со схемой URL-адреса HTTP. Каждый из них регистрирует отдельную привязку к домену, но в конечном итоге существует одно серверное приложение, проксирующее запросы к правильным приложениям.
Обновление 2019-05-30
Вот актуальное сравнение самых быстрых библиотек HTTP - https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext
Это довольно сложный вопрос. Нет никаких реальных программных ограничений на количество активных подключений, которые может иметь машина, хотя некоторые ОС более ограничены, чем другие. Проблема становится одним из ресурсов. Например, предположим, что одна машина хочет поддерживать 64 000 одновременных подключений. Если сервер использует 1 МБ ОЗУ на соединение, ему потребуется 64 ГБ ОЗУ. Если каждому клиенту необходимо прочитать файл, нагрузка доступа к диску или массиву хранения становится намного больше, чем могут обрабатывать эти устройства. Если серверу необходимо разветвить один процесс для каждого соединения, тогда ОС будет тратить большую часть своего времени на переключение контекста или нехватку процессорного времени для процессов.
На странице проблема C10K есть очень хорошее обсуждение этого вопроса.
Чтобы добавить мои два цента к разговору, процесс может одновременно открыть количество подключенных сокетов, равное этому количеству (в системах типа Linux) / proc / sys / net / core / somaxconn
cat / proc / sys / net / core / somaxconn
Этот номер может быть изменен на лету (конечно, только root-пользователем)
эхо 1024> / proc / sys / net / core / somaxconn
Но полностью зависит от серверного процесса, оборудования машины и сети, реального количества сокетов, которые могут быть подключены до сбоя системы.
listen(int socket, int backlog). Оно не связано с количеством сокетов, которые процесс может открыть.
- person Timmmm; 01.09.2015
Похоже, что ответ - минимум 12 миллионов, если у вас мощный сервер, ваше серверное программное обеспечение оптимизировано для него, у вас достаточно клиентов. Если вы тестируете от одного клиента к одному серверу, количество номеров портов на клиенте будет одним из очевидных ограничений ресурсов (каждое TCP-соединение определяется уникальной комбинацией IP-адреса и номера порта в источнике и месте назначения).
(Вам нужно запустить несколько клиентов, иначе вы сначала достигнете предела 64 КБ для номеров портов)
Когда доходит до этого, это классический пример остроумия о том, что «разница между теорией и практикой намного больше на практике, чем в теории» - на практике достижение более высоких чисел кажется циклом a. предложить конкретные изменения конфигурации / архитектуры / кода, b. протестируйте его, пока не достигнете предела, c. Я закончил? Если нет, то d. выяснить, что было ограничивающим фактором, e. вернитесь к шагу а (промойте и повторите).
Вот пример с 2 миллионами TCP-подключений к мощному компьютеру (128 ГБ ОЗУ и 40 ядер), на котором запущен Phoenix http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections - им потребовалось около 50 достаточно значительных серверов, просто чтобы обеспечить клиентскую нагрузку (их первоначальные меньшие клиенты были максимально ранены, например, «довели до максимума нашу 4-ядерную / 15-гигабайтную коробку @ 450 тыс. клиентов»).
Вот еще одна ссылка на go на этот раз в 10 миллионов: http://goroutines.com/10m.
Это похоже на Java и 12 миллионов подключений: https://mrotaru.wordpress.com/2013/06/20/12-million-concurrent-connections-with-migratorydata-websocket-server/
Обратите внимание, что HTTP обычно не поддерживает TCP-соединения открытыми дольше, чем требуется для передачи страницы клиенту; и обычно пользователю требуется гораздо больше времени для чтения веб-страницы, чем для загрузки страницы ... пока пользователь просматривает страницу, он не добавляет никакой нагрузки на сервер.
Таким образом, количество людей, которые могут одновременно просматривать ваш веб-сайт, намного больше, чем количество TCP-соединений, которые он может одновременно обслуживать.
в случае протокола IPv4 сервер с одним IP-адресом, который прослушивает только один порт, может обрабатывать 2 ^ 32 IP-адреса x 2 ^ 16 портов, то есть 2 ^ 48 уникальных сокетов. Если вы говорите о сервере как о физической машине, и вы можете использовать все 2 ^ 16 портов, тогда может быть максимум 2 ^ 48 x 2 ^ 16 = 2 ^ 64 уникальных сокета TCP / IP для одного IP-адреса. Обратите внимание, что некоторые порты зарезервированы для ОС, поэтому это число будет меньше. Подводить итоги:
1 IP и 1 порт -> 2 ^ 48 сокетов
1 IP и все порты -> 2 ^ 64 сокета
все уникальные сокеты IPv4 во вселенной -> 2 ^ 96 сокетов
Здесь есть два разных обсуждения: один - сколько людей может подключиться к вашему серверу. На этот вопрос адекватно ответили другие, поэтому я не буду вдаваться в подробности.
Другое - сколько портов может прослушивать ваш сервер? Думаю, отсюда и пришло число 64К. Фактически, протокол TCP использует 16-битный идентификатор порта, который преобразуется в 65536 (чуть больше 64 КБ). Это означает, что у вас может быть столько разных «слушателей» на сервере для каждого IP-адреса.
Я думаю, что количество одновременных подключений сокетов, которые может обрабатывать один веб-сервер, во многом зависит от количества ресурсов, потребляемых каждым подключением, и общего объема ресурсов, доступных на сервере, за исключением любой другой конфигурации ограничения ресурсов веб-сервера.
Чтобы проиллюстрировать это, если каждое соединение сокета потребляет 1 МБ ресурсов сервера, а на сервере доступно 16 ГБ ОЗУ (теоретически), это будет означать, что он сможет обрабатывать только (16 ГБ / 1 МБ) одновременные подключения. Я думаю, это так просто ... ДЕЙСТВИТЕЛЬНО!
Таким образом, независимо от того, как веб-сервер обрабатывает соединения, каждое соединение в конечном итоге потребляет некоторый ресурс.
