WebSockets. Потеря интернета, сообщений поддержки, архитектуры приложений и т. Д.

Question

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

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

"... в идеале будущая версия WebSocket будет поддерживать обнаружение тайм-аута, поэтому она может сообщать приложению период для сообщений поддержки активности ..."

1. Это похоже на дежа вю. Ранее нам приходилось опрашивать сервер один раз в% period_time%, чтобы получить необходимую обновленную информацию. С помощью веб-сокетов мы должны опрашивать сервер веб-сокетов один раз в% period_time% с сообщениями keep-alive , чтобы убедиться, что интернет-соединение все еще живо / сервер веб-сокетов все еще работает. Какая прибыль?

   И еще одна вещь, касающаяся этих сообщений поддержки активности. Протокол Websocket имеет преимущество использования меньшего количества трафика, чем HTTP (S). Если мы отправляем сообщения поддержки активности, кажется, что преимущество трафика исчезает. А может и нет?

2. Как мне справиться с потерей интернета в моем приложении, если я использую веб-сокеты? Я имею в виду реальную ситуацию, когда интернет-соединение внезапно теряется (я имею в виду, что событие "navigator.offline" не произошло) Должен ли я использовать какую-то функцию setTimeout для поиска сообщений поддержки активности или есть лучший способ справиться с этой ситуацией?

3. REST дает нам четкое представление о том, как должно работать приложение и как должны выглядеть запросы. Каков наилучший способ сделать это в приложениях на базе веб-сокетов? Должен ли я просто иметь (скажем) JSON-кодированные сообщения с полем request.action? А как приложение должно выполнять PUT-запросы? В модели REST есть URL-ресурсы для решения этой проблемы, поэтому я должен использовать комбинацию этих подходов или, может быть, есть что-то проще?

Answer 1

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

Имея это в виду, позвольте мне прокомментировать ваши пункты пули:

1. Цель периодических пинг / понг-сообщений WebSockets имеет двойную цель: предотвратить закрытие канала из-за тайм-аута TCP и более быстро определить, когда канал закрыт (это исторически слабость TCP). Цель опроса HTTP / AJAX состоит в том, чтобы обойти тот факт, что HTTP не является двунаправленным (то есть клиент опрашивает, чтобы дать серверу возможность отправлять данные обратно). Пинг / понг-фреймы WebSocket обычно имеют длину 2 байта. Для опроса HTTP / AJAX требуются полные заголовки, файлы cookie и т. Д., Которые могут легко составлять более килобайта для каждого запроса / ответа. Даже если вы отправляете пинг / понг 10 раз в секунду через WebSockets, вы все равно вряд ли сможете даже сравнивать с издержками HTTP / AJAX-опроса каждые 2 секунды. Однако обратите внимание, что приложения не имеют возможности отправлять сообщения пинг / понг. Это между браузером и сервером.

2. Если вы потеряете подключение к Интернету, вы получите событие onclose. Если ваш браузер не отправляет вам сообщения ping / pong, вы можете не получить сообщение onclose, пока не попытаетесь отправить сообщение после обрыва сетевого соединения.

3. Я бы не заменил работающий сервис RESTful на WebSockets. Вы будете выполнять большую часть картографической работы, возможно, с очень небольшой пользой (опять же, WebSockets не предназначен для замены того, что уже работает хорошо). Я могу представить себе ситуации, когда у вас может быть комбинация обоих: REST для передачи состояния, WebSockets для уведомления о событии. Например. сервер отправляет сообщение WebSocket, указывающее «что-то изменилось», что заставляет клиента выполнить запрос REST, чтобы выяснить это изменение.

Обновление

Разъяснение: вы можете сделать REST поверх WebSockets, но это не соответствует философии. REST - это архитектурный стиль, который не учитывает основную транспортную систему. Это ограниченная архитектура: «клиент-сервер», «без сохранения состояния», «кешируемый», «многоуровневая система», «код по требованию» и «унифицированный интерфейс». WebSockets не ограничен ни одним из них; это общая система транспортировки сообщений. Вы можете ограничить использование WebSockets как RESTful, но не делайте этого, пока не разберетесь в REST и WebSockets и не сможете определить, когда это правильно.

Answer 2

"Пожалуйста, перестаньте говорить обычные слова и расскажите, сколько реальных практических случаев использования веб-сокетов в готовых приложениях вы знаете, кроме чатов и приложений для фондовых бирж?"

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

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