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

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

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

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

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

И еще одна вещь в отношении этих сообщений keep-alive. Протокол Websocket имеет преимущество использования меньшего трафика, чем HTTP (S). Если мы отправляем сообщения keep-alive, похоже, что преимущество трафика исчезает. Или, может быть, нет?
Как я могу обрабатывать потерю Интернета в моем приложении, если я использую websockets? Я имею в виду реальную ситуацию, когда интернет-соединение внезапно теряется (я имею в виду, что событие "navigator.offline" не произошло). Должен ли я использовать какую-то функцию setTimeout для поиска сообщений keep-alive или есть лучший способ справиться с этой ситуацией?
REST дает нам четкое представление о том, как приложение должно работать и как должны выглядеть запросы. Каков наилучший способ сделать это в приложениях с сетевыми приложениями? Должен ли я просто иметь (скажем) JSON-кодированные сообщения с полем request.action? И как приложение должно выполнять PUT-запросы? В REST-модели есть URL-ресурсы, чтобы справиться с этим, поэтому я должен использовать комбинацию этих подходов или, может быть, там проще?

Ответ 1

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

С учетом этого позвольте мне прокомментировать ваши пункты:

Назначение периодических сообщений ping/pong для WebSockets выполняется в два раза: чтобы канал не закрывался таймаутом TCP и быстрее обнаруживал, когда канал закрыт (это исторически слабое TCP). Цель опроса HTTP/AJAX заключается в том, чтобы обойти тот факт, что HTTP не является двунаправленным (т.е. Опросы клиентов, чтобы дать серверу возможность отправить данные обратно). Рамки ping/pong WebSocket обычно имеют длину 2 байта. Для опроса HTTP/AJAX требуются полные заголовки, файлы cookie и т.д., Которые могут легко суммироваться за килобайт для каждого запроса/ответа. Даже если вы отправляете ping/pong 10 раз в секунду поверх WebSockets, вы все равно вряд ли сравните с накладными расходами HTTP/AJAX каждые 2 секунды. Однако обратите внимание, что приложения не имеют возможности отправлять сообщения ping/pong. Это между браузером и сервером.
Если вы потеряете подключение к Интернету, вы получите событие onclose. Если ваш браузер не делает для вас сообщения ping/pong, вы не можете получать onclose до тех пор, пока не попытаетесь отправить сообщение после того, как сетевое подключение будет отключено.
Я бы не заменил рабочую службу RESTful на WebSockets. Вы будете делать много картографических работ, возможно, очень мало пользы (опять же, WebSockets не предназначен для замены того, что уже хорошо работает). Я могу представить себе ситуации, когда у вас может быть комбинация обоих: REST для передачи состояния, WebSockets для уведомления о событиях. Например. сервер отправляет сообщение WebSocket, указывающее "что-то изменившееся", которое запускает клиент для выполнения запроса REST, чтобы узнать об изменениях.

Обновление

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

Ответ 2

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

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

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