Для push-уведомления является ли обязательным наличие веб-сокета?

Ответ 1

Если клиент является браузером, то ТОЛЬКО два способа, которым стандартный браузер может подключаться к серверу, - это запрос Ajax (например, http) или соединение с WebSocket. Итак, если вы хотите, чтобы клиент получил уведомление о чем-то из внешнего мира, он должен использовать один из этих двух механизмов.

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

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

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

Итак, если вы пытаетесь "нажимать сервер реального времени" в браузере, тогда у вас должен быть подключенный к нему сокет, что означает webSocket (или что-то построенное поверх webSocket, такого как socket.io).

Для телефонных приложений, в которых у вас есть доступ к SDK телефона, вы можете использовать систему "push", встроенную в ОС, для перемещения некоторых сообщений с сервера на клиент. Это не совсем то же самое, что и двухканальный канал webSocket, но поскольку вы спрашивали о "push-уведомлениях", службы push-push OS, доступные как в Android, так и в IOS, также могут быть возможностью для push-уведомлений с сервера на клиент. Здесь информация о уведомления iOS и Google Cloud Messaging

Начиная с 2016 года, во всех современных браузерах также можно использовать События, отправленные сервером, за исключением браузеров Microsoft (не поддерживается еще в Edge или IE) для передачи данных с сервера на клиент. Здесь таблица совместимости браузера. События, отправленные сервером, используют длительное HTTP-соединение, специальный тип MIME и поддерживающий клиент, чтобы иметь возможность отправлять события с сервера на клиент в любое время. В отличие от web-сокетов, события, отправленные сервером, являются только одним способом (от сервера к клиенту). Затем клиент будет использовать традиционный вызов Ajax, чтобы иметь возможность отправлять данные на сервер (в то время как данные webSocket могут быть отправлены любым способом через одно и то же соединение с WebSocket).

Вот хорошее описание того, как работают серверные события: Как действительно отправляются серверные события?

Ответ 2

Я бы предположил, что использование webSockets является более эффективным способом по сравнению с другими вариантами, почему это так? Когда клиент получает уведомление о том, что на сервере произошли изменения, нет необходимости создавать AJAX-вызов на сервер, чтобы получить это изменение, его можно отправить клиенту с тем же соединением webSocket проще, чем AJAX. Это означает эффективный код и более быстрое приложение!

Ответ 3

Является ли ваше клиентское приложение SPA? (Одностраничное приложение)? Это очень важно, потому что если нет, вы должны учитывать, что каждый раз, когда клиент меняет страницу, соединение с сервером веб-сокета будет потеряно. В этом случае вам нужно управлять очередью, потому что, если заинтересованная сторона отправляет многоадресный запрос, когда один клиент отключен, клиент ничего не получит. Опрос не решит и эту ситуацию, и это плохое решение, потому что мобильные клиенты (например) с типичным интернет-планом будут потреблять мегабайты за ненужный трафик "ping". Настоящим примером опроса является ребенок в машине, который каждую минуту спрашивает своего отца, прибыли ли они в пункт назначения! Итак, есть ли решение без использования спа? Да, использование "общего хранилища" между заинтересованными сторонами и клиентами и использование веб-сокета только для "просыпающихся" онлайн-клиентов, говорящих: "Эй, есть что-то новое, перейдите, чтобы проверить!

Каждый раз, когда клиент открывает страницу, он получает от бэкэнда также не прочитанные уведомления, взятые из хранилища. Когда заинтересованная сторона хочет что-то уведомить, она просто сохраняет уведомление в общем хранилище и отправляет "импульс" на сервер уведомлений. Сервер уведомлений перенаправит "пульс" онлайн-клиентам (на случай, если кто-то застрянет, читая страницу). Если "импульс" теряется из-за того, что клиент меняет страницу, проблем не возникает, поскольку клиент будет доставлять уведомления из хранилища. Каждая страница будет содержать эту логику: Получить номер или непрочитанные уведомления (на стороне сервера) Соединитесь с сервером уведомлений через 5 секунд (сторона JavaScript). Надеюсь, это поможет.