Различия между Socket.IO и WebSockets
Вопрос: Каковы различия между socket.io и WebSockets в Node.js?
Я хотел бы разобраться в следующих моментах:
- Являются ли они обеими технологиями "Push" с сервера?
- Какие основные отличия между ними?
На данный момент я заметил несколько отличий:
- В socket.io я могу отправлять/возвращать сообщения, указывая имя события.
- В случае socket.io сообщение от сервера достигает всех клиентов, тогда как в WebSockets мне пришлось бы поддерживать массив всех соединений и проходить по нему, чтобы отправить сообщения всем клиентам.
Кроме того, меня интересует, почему веб-инспекторы (такие как Chrome, Firebug, Fiddler) не могут отлавливать эти сообщения (от socket.io/WebSocket) от сервера?
Прошу разъяснить эти моменты.
5 ответ(ов)
Преимущества использования Socket.IO заключаются в том, что он упрощает работу с WebSocket, как вы описали в пункте #2, и, вероятно, более важно, предоставляет возможность переключения на другие протоколы в случае, если WebSocket не поддерживается в браузере или на сервере. Я бы рекомендовал избегать прямого использования WebSocket, если вы не обладаете достаточными знаниями о средах, в которых они могут не работать, и не умеете обойти эти ограничения.
Также рекомендую прочитать эту статью о WebSocket и Socket.IO:
tl;dr;
Сравнивать SocketIO и Websockets — это как сравнивать еду в ресторане с домашней едой. Если вам нужно только скушать яблоко, лучше выбрать домашнюю еду. Но для сложных блюд готовить самому не всегда стоит усилий.
SocketIO:
- Автоподключение
- Нэймспейсы и комнаты
- Служба подписок
- Предопределённый протокол
- Поддержка логирования
- Интеграция с Redis
- Запасной вариант, если WebSocket не поддерживается
- Библиотека - меньше работы для вас, можете сосредоточиться на бизнес-логике
- Сообщество поддержки
Websockets:
- Полный контроль, что может быть как плюсом, так и минусом
- Легковесный
- Нужно самому разрабатывать архитектуру и протокол
- Нет автоподключения, службы подписок, логирования, и т.д.
- Требуется значительное время на проектирование и отладку
Очевидно, что я склоняюсь к SocketIO. Если вы хотите законченный продукт без лишних усилий, выбирайте его — если только вам не нужна простота в функциональности.
Я хотел бы представить аргументы против использования socket.io.
Считаю, что использовать socket.io только из-за наличия резервных вариантов — не лучший подход. Давайте оставим IE8 в покое.
В прошлом были случаи, когда новые версии Node.js ломали socket.io. Вы можете посмотреть эти списки для примеров... https://github.com/socketio/socket.io/issues?q=install+error
Если вы планируете разрабатывать Android-приложение или что-то подобное, что должно работать с вашим существующим приложением, то, вероятно, вам будет удобнее сразу использовать WebSocket (WS). Socket.io может создать некоторые сложности в этом случае...
Кроме того, модуль WS для Node.js невероятно прост в использовании.
Использование Socket.IO в основном похоже на использование jQuery: если вы хотите поддерживать старые браузеры, вам нужно написать меньше кода, а библиотека предоставит вам резервные варианты. Socket.IO использует технологию веб-сокетов, если она доступна, а если нет, то проверяет наилучший доступный способ общения и использует его.
Socket.IO использует WebSocket для обеспечения соединений в реальном времени, однако, когда WebSocket недоступен, он применяет алгоритм запасного варианта для установления соединения. Это позволяет поддерживать функциональность в самых различных условиях и обеспечивать надежное соединение, даже если прямая поддержка WebSocket отсутствует.
Как предотвратить установку "devDependencies" модулей NPM для Node.js (package.json)?
Ошибка "npm WARN package.json: Нет поля repository"
Как исправить ошибку "ReferenceError: primordials is not defined" в Node.js
Как протестировать один файл с помощью Jest?
nvm постоянно "забывает" Node.js в новой сессии терминала