Поддерживают ли HTML WebSockets открытое соединение для каждого клиента?Это масштаб?

Question

Мне любопытно, есть ли у кого-нибудь информация о масштабируемости HTML WebSockets.Из всего, что я прочитал, похоже, что каждый клиент будет поддерживать открытую линию связи с сервером.Мне просто интересно, как это масштабируется и сколько открытых соединений WebSocket может обрабатывать сервер.Может быть, оставить эти связи открытыми на самом деле не проблема, но кажется, что это так.

Answer 1

В большинстве случаев WebSockets, вероятно, будет масштабироваться лучше, чем запросы AJAX / HTML.Однако это не означает, что WebSockets заменяет все виды использования AJAX / HTML.

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

Вы когда-нибудь пытались настроить веб-сервер для поддержки десятков тысяч одновременных клиентов AJAX?Измените эти клиенты на клиенты WebSockets, и это просто возможно.

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

• Каждое HTTP-соединение несет много багажа, который не используется большую часть времени: файлы cookie, тип контента, длина контента, пользовательский агент, идентификатор сервера, дата, последнее изменение,и т. д. Как только соединение WebSockets установлено, только данные, требуемые приложением, должны отправляться туда и обратно.

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

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

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

Основным преимуществом WebSockets будут соединения с меньшей задержкой для интерактивных веб-приложений.Он будет масштабироваться лучше и потреблять меньше ресурсов сервера, чем HTTP AJAX / long-poll (при условии, что приложение / сервер спроектирован правильно), но более низкая задержка IMO является основным преимуществом WebSockets, потому что это позволит создавать новые классы веб-приложений, которые невозможныс текущими издержками и задержкой AJAX / long-poll.

Как только стандарт WebSockets станет более завершенным и получит более широкую поддержку, будет целесообразно использовать его для большинства новых интерактивных веб-приложений, которым необходимо часто общаться ссервер.Для существующих интерактивных веб-приложений это будет зависеть от того, насколько хорошо работает текущая модель AJAX / long-poll.Усилия по конвертации будут нетривиальными, поэтому во многих случаях стоимость просто не будет стоить выгоды.

Обновление :

Полезная ссылка: 600k одновременных подключений к веб-сокету в AWS с использованием Node.js

Answer 2

Просто пояснение: количество клиентских подключений, которые может поддерживать сервер, не имеет никакого отношения к портам в этом сценарии, поскольку сервер [обычно] только ожидает подключения WS / WSS к одному порту. Я думаю, что другие комментаторы хотели ссылаться на дескрипторы файлов. Вы можете установить максимальное количество дескрипторов файлов достаточно большим, но тогда вам нужно следить за размерами буфера сокетов, складывающимися для каждого открытого сокета TCP / IP. Вот дополнительная информация: https://serverfault.com/questions/48717/practical-maximum-open-file-descriptors-ulimit-n-for-a-high-volume-system

Что касается уменьшения задержки через WS по сравнению с HTTP, то это правда, поскольку больше нет синтаксического анализа заголовков HTTP после первоначального рукопожатия WS. Кроме того, по мере того, как все больше и больше пакетов успешно отправляются, окно перегрузки TCP расширяется, эффективно снижая RTT.

Answer 3

Любой современный отдельный сервер способен обслуживать тысячи клиентов одновременно .Его программное обеспечение HTTP-сервера просто ориентировано на Event-Driven (IOCP) (мы больше не находимся в старом соединении Apache одно соединение = одно уравнение потока / процесса).Даже встроенный в Windows HTTP-сервер (http.sys) ориентирован на IOCP и очень эффективен (работает в режиме ядра).С этой точки зрения, не будет большой разницы при масштабировании между WebSockets и обычным HTTP-соединением.Одно соединение TCP / IP использует небольшой ресурс (намного меньше, чем поток), и современные ОС оптимизированы для обработки большого количества одновременных соединений: WebSockets и HTTP - это просто протоколы уровня приложений OSI 7, унаследованные от этих спецификаций TCP / IP.

Но из эксперимента я обнаружил две основные проблемы с WebSockets:

1. Они не поддерживают CDN;
2. У них есть потенциальные проблемы безопасности.

Поэтому я бы порекомендовал следующее для любого проекта:

• Использовать WebSockets только для клиентских уведомлений (с механизмом возврата к длинному опросу - существует множество библиотек).вокруг);
• Используйте RESTful / JSON для всех остальных данных, используя CDN или прокси для кеша.

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

О потенциальных проблемах использования WebSockets:

1.Рассмотрите возможность использования CDN

. Сегодня (почти через 4 года) масштабирование веб-сайтов включает использование Content Delivery Network (CDN), не только для статического контента (html, css,js) но также данные вашего (JSON) приложения .

Конечно, вы не будете помещать все свои данные в кэш CDN, но на практике много общего контента выиграет 'часто меняются.Я подозреваю, что 80% ваших ресурсов REST могут быть кэшированы ... Даже одна минута (или 30 секунд) истечения срока действия CDN может быть достаточной, чтобы дать вашему центральному серверу новую работу и повысить отзывчивость приложенияочень много, так как CDN может быть географически настроен ...

Насколько мне известно, в CDN пока нет поддержки WebSockets, и я подозреваю, что это никогда не произойдет.WebSockets имеют полное состояние, тогда как HTTP не имеет состояния, поэтому его легко кэшировать.Фактически, чтобы сделать WebSockets CDN-дружественным, вам может потребоваться переключиться на подход RESTful без учета состояния ... который больше не будет WebSockets.

2.Проблемы безопасности

Возможны проблемы безопасности WebSockets, особенно в отношении атак DOS.Для иллюстрации новых уязвимостей безопасности см. этот набор слайдов и этот билет WebKit .

WebSockets исключает любую возможность проверки пакетов на уровне приложения OSI 7, чтов наше время становится довольно стандартным в любой бизнес-безопасности.Фактически, WebSockets делает передачу запутанной, поэтому может быть серьезным нарушением безопасности.

Answer 4

Подумайте об этом так: что дешевле, сохранять открытое соединение или открывать новое соединение для каждого запроса (с учетом накладных расходов, связанных с согласованием, помните, что это TCP.)

Конечно, это зависитв приложении, но для долгосрочных соединений в реальном времени (например, чата AJAX) гораздо лучше сохранять соединение открытым.

Максимальное количество соединений будет ограничено максимальным количеством свободных портов для сокетов..

Answer 5

Нет, он не масштабируется, дает огромную работу коммутаторам промежуточных маршрутов. Затем на стороне сервера ошибки страниц (вы должны сохранить все эти дескрипторы) достигают высоких значений, и время для ввода ресурса в рабочую область увеличивается. В основном это написанные на JAVA серверы, и может быть быстрее удержать эти gazilions сокетов, чем уничтожить / создать один. Когда вы запускаете такой сервер на машине, любой другой процесс больше не может двигаться.