Как внедряются Websockets?

Как внедряются Websockets?
Каков алгоритм этой новой технологии (по сравнению с Long-Polling)?
Как они могут быть лучше Long-Polling с точки зрения производительности?

Я задаю эти вопросы, потому что здесь у нас есть пример кода реализации Jetty websocket (на стороне сервера).

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

И это определенно проблема, с которой я сталкиваюсь при использовании Long-poll. Он останавливает процесс, чтобы предотвратить перегрузку сервера, не так ли?

Ответ 1

Как реализованы веб-сокеты?

webSockets реализованы следующим образом:

Клиент делает HTTP-запрос к серверу с заголовком "upgrade" по запросу
Если сервер соглашается на обновление, то клиент и сервер обмениваются некоторыми учетными данными безопасности, и протокол в существующем сокете TCP переключается с HTTP на webSocket.
Теперь существует постоянный открытый сокет TCP, соединяющий клиента и сервер.
Любая из сторон может отправлять данные в этот открытый сокет в любое время.
Все данные должны быть отправлены в очень специфическом формате пакета webSocket.

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

Из-за того, как инициируются webSockets (начиная с HTTP-запроса и затем повторно используя этот сокет), они на 100% совместимы с существующей веб-инфраструктурой и могут даже работать на том же порту, что и ваши существующие веб-запросы (например, порт 80 или 443). Это упрощает межсайтовую безопасность и избавляет любого пользователя на клиентской или серверной инфраструктуре от необходимости изменять любую инфраструктуру для поддержки соединений webSocket.

Какой алгоритм стоит за этой новой технологией (по сравнению с Long-Polling)?

Здесь очень хорошая сводка того, как алгоритм соединения webSocket и формат данных webSocket работают здесь в этой статье: Написание серверов WebSocket.

Как они могут быть лучше, чем Long-Polling с точки зрения производительности?

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

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

Итак, хотя webSocket использует один долгоживущий сокет, через который клиент или сервер может отправлять данные другому, длительный опрос состоит из того, что клиент спрашивает сервер: "У вас есть еще данные для меня?" снова и снова и снова, каждый с новым запросом http.

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

Я хочу получить объяснение по этому поводу: тот факт, что Websockets поддерживает открытую связь между C/S, не совсем совпадает с процессом ожидания длинного опроса? Другими словами, почему веб-сокеты не перегружают сервер?

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

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

Вот несколько полезных ссылок на тему масштабирования:

Ответ 2

Очень хорошее объяснение о веб-сокетах, длительном опросе и других подходах:

В каких ситуациях предпочтительнее использовать длинный/короткий опрос AJAX над Web-сокетами HTML5?

Длительный опрос - запрос → ожидание → ответ. Создает соединение с сервером, например AJAX, но соединение keep-alive открыто в течение некоторого времени (хотя и недолго), во время открытия соединения клиент может получать данные с сервера. Клиент должен повторно подключаться после закрытия соединения из-за тайм-аутов или данных. На стороне сервера он по-прежнему обрабатывается как HTTP-запрос, такой же, как AJAX, за исключением того, что ответ по запросу произойдет сейчас или некоторое время в будущем, определяемое логикой приложения. Поддерживается во всех основных браузерах.

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

В целом, сокеты имеют гораздо лучшую производительность, чем длительный опрос, и вы должны использовать их вместо длительного опроса.