Сервер отправил событие против веб-сокетов?

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

В этом сценарии, который будет лучшим выбором? А также, поскольку я хочу, чтобы это работало на как можно большем числе платформ и браузеров, у которых больше поддержки браузеров? Есть ли лучший вариант?

Ответы

Ответ 1

Некоторые вещи, которые следует учитывать при выборе этого варианта.

  • Попытка получить контент через соединение WebSocket - это плохой дизайнерское решение, потому что WebSockets - это другой протокол, вложенный внутри HTTP-соединения и не может использовать кеширование (ни браузеров и CDN).
  • Некоторые старшие прокси не передают соединение с Websocket, если оно не скрыто в защищенном соединении, пока сервер Отправленные события остаются HTTP-соединением и не будут это.
  • В среде Android не поддерживаются ни WebSockets, ни SSE браузера до 4.4 (когда они переключились на использование Chrome) - таким образом, если вы рассматриваете гибридное мобильное приложение, вам понадобится резерв как SocketIO, поскольку на момент написания этой статьи 4.4 составляет всего 20% рынка и гибридные приложения используют собственный браузер Android.
  • WebSockets - это самый эффективный протокол для мобильных устройств, поскольку все остальные параметры требуют много HTTP-соединений, и это повторяющиеся ведение переговоров с заголовками, которые будут обременять процессор и аккумулятор.

Другим вариантом могут быть уведомления. Все мобильные устройства теперь поддерживают уведомления, которые могут быть нацелены на приложение, а также на несколько браузеров. Во всех случаях соединение уже существует от клиента к центру обмена сообщениями (Apple, Google, Microsoft и т.д.), И все уведомления отправляются по этому каналу.

Вот хороший обзор WebSockets против SSE: http://www.html5rocks.com/en/tutorials/eventsource/basics/

Ответ 2

  • События, отправленные сервером: постоянный сервер соединения-2-клиент только для отправки текстовых сообщений и реализуется во всех основных браузерах, но Internet Explorer. Он может снова подключиться, если связь потеряна. http://caniuse.com/eventsource

  • WebSokets: полнодуплексное постоянное соединение, способное передавать текст и двоичные данные UTF8. http://caniuse.com/websockets

WebSocket лучше, и будущее.

Ответ 3

Из того, что я понимаю, SSE проще и проще реализовать, тогда как WebSockets предлагают двунаправленную передачу данных, но являются их собственным протоколом /API, которые вам нужно понять, чтобы воспользоваться преимуществами. Честно говоря, я никогда не беспокоился об SSE, Socket.IO делает все, что мне нужно, насколько общение в режиме реального времени в Интернете довольно легко и построенный для кросс-браузера.

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