Сколько соединений сокетов может обрабатывать веб-сервер?

Ответ 1

Вкратце: Вы должны иметь возможность достичь порядка миллионов одновременных активных TCP-соединений и HTTP-запросов расширения.

Сегодня я был обеспокоен тем, поддерживает ли IIS с ASP.NET порядка 100 одновременных подключений. Когда я увидел этот вопрос/ответы, я не мог устоять перед ответом, многие ответы на этот вопрос совершенно неверны.

Лучший случай

Ответ на этот вопрос должен касаться только простейшей конфигурации сервера, чтобы отделить от бесчисленных переменных и конфигураций, доступных ниже по течению.

Итак, рассмотрим следующий сценарий для моего ответа:

• Нет трафика на сеансах TCP, за исключением пакетов keep-alive (в противном случае вам, очевидно, потребуется соответствующее количество полосы пропускания сети и других ресурсов компьютера).
• Программное обеспечение, предназначенное для использования асинхронных сокетов и программирования, а не аппаратного потока для каждого запроса из пула. (т.е. IIS, Node.js, Nginx... webserver [но не Apache] с асинхронным программным обеспечением)
• Хорошая производительность/доллар CPU/Ram. Сегодня произвольно, скажем, i7 (4 ядра) с 8 ГБ оперативной памяти.
• Хороший межсетевой экран/маршрутизатор для соответствия.
• Нет виртуального предела/регулятора - т.е. Linux somaxconn, IIS web.config...
• Никакая зависимость от других более медленных аппаратных средств - отсутствие чтения из жесткого диска, поскольку это будет самый низкий общий знаменатель и узкое место, а не сетевой IO.

Подробный ответ

Синхронные проекты, связанные с нитями, как правило, хуже всего относятся к асинхронным реализациям ввода-вывода.

WhatsApp получает миллион С трафика на одной операционной системе Unix с ароматизированной ОС - https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/.

И, наконец, этот http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html вникает в детали, изучая, как можно было бы достичь даже 10 миллионов. Серверы часто имеют аппаратные устройства разгрузки TCP, ASIC, предназначенные для этой конкретной роли, более эффективно, чем CPU общего назначения.

Хороший выбор дизайна программного обеспечения

Асинхронная конфигурация ввода-вывода будет различаться на платформах операционных систем и программирования. Node.js был разработан с асинхронным учетом. Вы должны использовать Promises по крайней мере, и когда ECMAScript 7 появится, async/await. С#/.NET уже имеет полную асинхронную поддержку, например Node.js. Независимо от ОС и платформы, ожидается, что асинхронный режим будет работать очень хорошо. И какой бы язык вы ни выбрали, ищите ключевое слово "асинхронный", большинство современных языков будут иметь некоторую поддержку, даже если это надстройка какого-то рода.

В WebFarm?

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

Разрушение мифа - порты 64K

Чтобы решить вопрос о компоненте "64 000", это неправильное представление.

Поле TCP Port - 2x байта, которое может содержать 65536, но это не ограничивает количество клиентов до ~ 64k. Каждый TCP-пакет имеет два поля портов один для адресата и один для источника (а также два IP-адреса).

С TCP:

• сервер прослушивает порт, например 80 для Web (порт назначения)
• Предположим, что сервер прослушивает только один IP-адрес этого единственного порта
• Каждый клиент, который подключается, сопоставляется в соответствии с исходным IP + портом для состояния соединения (и обратно).
• Каждый раз, когда сервер получает другой пакет из одного и того же IP + порта, он знает (игнорируя поддельные пакеты), что он с той же конечной точки клиента.

Это означает, что существует только предел количества серверов, к которым клиент может подключаться (на каждый IP-адрес клиента), а не наоборот (не сколько клиентов подключается сервер).

Кстати, Http.sys в Windows позволяет нескольким приложениям совместно использовать один и тот же порт сервера в схеме URL-адреса HTTP. Каждый из них регистрирует отдельную привязку домена, и все еще существует одно серверное приложение, которое проксирует запросы к правильным приложениям.

Ответ 2

Этот вопрос довольно сложный. Нет никакого реального ограничения программного обеспечения на количество активных соединений, которые может иметь машина, хотя некоторые ОС более ограничены, чем другие. Проблема становится одним из ресурсов. Например, допустим, что одна машина хочет поддерживать 64 000 одновременных подключений. Если сервер использует 1 МБ ОЗУ для каждого соединения, ему потребуется 64 ГБ ОЗУ. Если каждому клиенту необходимо прочитать файл, загрузка доступа к массиву дисков или хранилища становится намного больше, чем могут обрабатывать эти устройства. Если серверу необходимо разветвлять один процесс на одно соединение, то ОС будет тратить большую часть времени на переключение времени или процессы голодания для процессорного времени.

Страница C10K problem имеет очень хорошее обсуждение этой проблемы.

Ответ 3

Чтобы добавить мои два цента в разговор, процесс может одновременно открыть несколько сокетов, связанных с этим номером (в системах типа Linux)/proc/sys/net/core/somaxconn

cat/proc/sys/net/core/somaxconn

Этот номер может быть изменен "на лету" (конечно, конечно, конечно, root)

echo 1024 > /proc/sys/net/core/somaxconn

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

Ответ 4

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

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

Ответ 5

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

(Вам нужно запустить несколько клиентов, так как в противном случае вы попадаете в предел 64K для номеров портов)

Когда дело доходит до этого, это классический пример остроты, что "разница между теорией и практикой на практике гораздо больше, чем в теории" - на практике достижение более высоких чисел представляется циклом a. предложить конкретные изменения конфигурации/архитектуры/кода, b. испытайте его, пока не достигнете предела, c. Я закончил? Если нет, то d. выяснить, что является ограничивающим фактором, например. вернитесь к шагу a (полоскание и повторение).

Вот пример с 2 миллионами TCP-соединений на жестком поле (128 ГБ оперативной памяти и 40 ядер), работающих под управлением Phoenix http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections - они закончились требующих 50 или около того достаточно значительных серверов, чтобы обеспечить загрузку клиента (их первоначальные более мелкие клиенты были превышены до раннего времени, например "maxed our 4core/15gb box @450k clients" ).

Вот еще одна ссылка для этого времени на 10 миллионов: http://goroutines.com/10m.

Это похоже на java based и 12 миллионов соединений: https://mrotaru.wordpress.com/2013/06/20/12-million-concurrent-connections-with-migratorydata-websocket-server/

Ответ 6

Здесь два разных обсуждения: один - сколько людей может подключиться к вашему серверу. Этому ответили адекватно другие, поэтому я не буду вдаваться в это.

Другое - сколько портов ваш сервер может прослушивать? Я считаю, что это то, откуда пришел номер 64K. Фактически, протокол TCP использует 16-разрядный идентификатор для порта, что соответствует 65536 (бит более 64 КБ). Это означает, что на вашем IP-адресе может быть много разных "слушателей".

Ответ 7

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

Чтобы проиллюстрировать, если каждое соединение сокета, потребляемое 1 МБ ресурса сервера, и на сервере имеется 16 ГБ ОЗУ (теоретически), это будет означать, что он сможет обрабатывать одновременные соединения (16 ГБ /1 МБ). Я думаю, это так просто... ДЕЙСТВИТЕЛЬНО!

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