Nodejs: Ajax против Socket.IO, плюсы и минусы

Ответ 1

Отправка односторонних сообщений и вызов обратных вызовов для них могут стать очень запутанными.

$.get('/api', sendData, returnFunction); чище, чем socket.emit('sendApi', sendData); socket.on('receiveApi', returnFunction);

Именно поэтому dnode и nowjs были построены поверх socket.io, чтобы сделать вещи управляемыми. Все еще управляемое событие, но не отказываясь от обратных вызовов.

Ответ 2

В этой ветке много распространенной дезинформации, которая очень неточна.

TL/DR; WebSocket заменяет HTTP для приложений! Он был разработан Google с помощью Microsoft и многих других ведущих компаний. Все браузеры поддерживают это. Там нет минусов.

SocketIO построен на основе протокола WebSocket (RFC 6455). Он был разработан, чтобы полностью заменить AJAX. У него нет проблем с масштабируемостью. Он работает быстрее, чем AJAX, потребляя при этом на порядок меньше ресурсов.

AJAX 10 лет, и он построен на основе единственной функции JavaScript XMLHTTPRequest, которая была добавлена, чтобы разрешить обратные вызовы серверам без перезагрузки всей страницы.

Другими словами, AJAX - это протокол документов (HTTP) с единственной функцией JavaScript.

Напротив, WebSocket - это протокол приложения, который был разработан, чтобы полностью заменить HTTP. Когда вы обновляете HTTP-соединение (запрашивая протокол WebSocket), вы активируете двустороннюю полнодуплексную связь с сервером, и никакое согласование протоколов не используется, как никогда. В AJAX вы должны либо включить поддержку активности (то же самое, что и SocketIO, только старый протокол), либо инициировать новые HTTP-рукопожатия, которые приводят к остановке сервера при каждом выполнении запроса AJAX.

Сервер SocketIO, работающий поверх Node, может обрабатывать 100 000 одновременных соединений в режиме keep-alive, используя только 4 ГБ оперативной памяти и один ЦП, и это ограничение вызвано механизмом сбора мусора V8, а не протоколом. Вы никогда, никогда не достигнете этого с AJAX, даже в своих самых смелых мечтах.

Почему SocketIO намного быстрее и потребляет гораздо меньше ресурсов

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

Если вы погрузитесь в HTTP-протокол и будете использовать MVC-фреймворки, вы увидите, что один запрос AJAX фактически передает 700-900 байт загрузки протокола только в AJAX на URL-адрес (без какой-либо собственной полезной нагрузки). В отличие от этого, WebSocket использует около 10 байтов, или примерно в 70 раз меньше данных для связи с сервером.

Так как SocketIO поддерживает открытое соединение, никакого рукопожатия не происходит, и время отклика сервера ограничено временем приема-передачи или проверки связи с самим сервером.

Существует неверная информация о том, что сокетное соединение является соединением порта; это не. Сокетное соединение - это просто запись в таблице. Потребляется очень мало ресурсов, и один сервер может обеспечить 1000 соединений 000+ WebSocket. Сервер AWS XXL может и размещает 1000 соединений 000+ SocketIO.

Соединение AJAX будет gzip/deflate все заголовки HTTP, декодировать заголовки, кодировать заголовки и раскрутить поток HTTP-сервера, чтобы снова обработать запрос, потому что это протокол документа; Сервер был спроектирован так, чтобы выкладывать документы один раз.

Напротив, WebSocket просто хранит запись в таблице для соединения, приблизительно 40-80 байтов. Это буквально это. Опрос вообще не происходит.

WebSocket был разработан для масштабирования.

Насколько SocketIO грязный... Это совсем не так. AJAX грязный, вам нужно обещание/ответ.

С SocketIO у вас просто есть излучатели и приемники; им даже не нужно знать друг о друге; система обещаний не нужна:

Чтобы запросить список пользователей, вы просто отправляете на сервер сообщение...

socket.emit("giveMeTheUsers");

Когда сервер будет готов, он отправит вам еще одно сообщение. Тада, ты готов. Итак, чтобы обработать список пользователей, вы просто говорите, что делать, когда получаете ответ, который вы ищете...

socket.on("HereAreTheUsers", showUsers(data) );

Это. Где беспорядок? Ну нету :) Разделение проблем? Сделанно для тебя. Блокировка клиента, чтобы они знали, что они должны ждать? Им не нужно ждать :) Вы можете получить новый список пользователей всякий раз, когда... Сервер может даже воспроизводить любую команду пользовательского интерфейса таким образом... Клиенты могут подключаться друг к другу, даже не используя сервер с WebRTC..,

Система чата в SocketIO? 10 строк кода. Видеоконференции в реальном времени? 80 строк кода Да... Люк... Присоединяйся ко мне. используйте правильный протокол для работы... Если вы пишете приложение... используйте протокол приложения.

Я думаю, что проблема и путаница здесь исходят от людей, которые привыкли использовать AJAX и думают, что им нужны все дополнительные протоколы обещаний на клиенте и REST API на стороне сервера... Ну, вы этого не делаете. :) Это больше не нужно :)

да, вы правильно прочитали... REST API больше не нужен, когда вы решите переключиться на WebSocket. ОТДЫХ на самом деле устарел. если вы пишете настольное приложение, вы общаетесь с помощью диалога с REST? Нет :) Это довольно глупо.

SocketIO, используя WebSocket, делает то же самое для вас... вы можете начать думать о клиентской стороне как о простом диалоге для вашего приложения. Вам больше не нужен отдых, вообще.

На самом деле, если вы пытаетесь использовать REST при использовании WebSocket, это так же глупо, как использование REST в качестве протокола связи для диалога на рабочем столе... в этом нет абсолютно никакого смысла.

Что ты скажешь, Тимми? А как насчет других приложений, которые хотят использовать ваше приложение? Вы должны дать им доступ к REST? Тимми... WebSocket существует уже 4 года... Просто подключите их к вашему приложению с помощью WebSocket и позвольте им запрашивать сообщения по этому протоколу... он потребляет в 50 раз меньше ресурсов, будет намного быстрее и в 10 раз проще развиваться... Зачем поддерживать прошлое, когда вы создаете будущее?

Конечно, есть варианты использования для REST, но они все для старых и устаревших систем... Большинство людей просто еще не знают об этом.

ОБНОВИТЬ:

Множество людей недавно спрашивали меня, как они могут начать писать приложение в 2018 году (а теперь и в 2019 году) с использованием WebSockets, что барьер кажется действительно высоким, что, когда они играют с Socket.IO, они не знают, где еще очередь или чему учиться.

К счастью, последние 3 года были очень добры к WebSockets...

В настоящее время существует 3 основные платформы, которые поддерживают ОБА REST и WebSocket, и даже протоколы IoT или другие минимальные/быстрые протоколы, такие как ZeroMQ, и вам не нужно беспокоиться об этом; Вы просто получаете поддержку для этого из коробки.

Примечание. Несмотря на то, что Meteor на данный момент является самым популярным, я оставляю его в стороне, потому что, хотя это очень и очень хорошо финансируемая среда WebSocket, любой, кто закодировал ее в течение нескольких лет, скажет вам, что это внутренняя путаница и кошмар в масштабе. Вроде как WordPress для PHP, он есть, он популярен, но он не очень хорошо сделан. Это не продумано, и скоро умрет. Извините, Метеор, но посмотрите эти 3 других проекта по сравнению с Метеором, и вы выбросите Метеор в тот же день :)

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

Перья Самый простой в использовании, работает одинаково на передней и задней панели и поддерживает большинство функций. Feathers - это коллекция облегченных оберток для существующих инструментов, таких как express. Используя потрясающие инструменты, такие как feathers-vuex, вы можете создавать неизменяемые сервисы, которые можно полностью смоделировать, поддерживать REST, WebSocket и другие протоколы (используя Primus), и получать бесплатные полные операции CRUD, включая поиск и разбиение на страницы, без единой строки кода (просто какой-то конфиг). Также отлично работает с сгенерированными данными, такими как json-schema-faker, так что вы можете не только полностью издеваться над вещами, но и над случайными, но действительными данными. Вы можете подключить приложение для поддержки поиска по типу, создания, удаления и редактирования без кода (только конфигурация). Как некоторые из вас могут знать, правильный код через конфигурацию является самым большим препятствием для самоизменяющегося кода. Перья делает это правильно, и подтолкнет вас к передней части пакета в будущем дизайна приложения.

Moleculer Moleculer, к сожалению, на порядок лучше, чем Feathers. В то время как перья будут работать и позволят вам масштабироваться до бесконечности, перья просто даже не начинают задумываться о таких вещах, как производственная кластеризация, консоль живого сервера, отказоустойчивость, конвейерные журналы из коробки или шлюзы API (пока я создавал производственный шлюз API из Feathers, Moleculer делает это намного лучше). Moleculer также является самым быстрорастущим, как по популярности, так и по новым возможностям, чем любая среда WebSocket.

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

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

ActionHero Перечислен здесь как жизнеспособная альтернатива, но Feathers и Moleculer являются лучшими реализациями. Если что-то в ActionHero не работает с вами, не используйте его; Есть два лучших способа, которые дают вам больше, быстрее.

ПРИМЕЧАНИЕ: API-шлюзы - это будущее, и все 3 из них поддерживают их, но Moleculer буквально дает вам это из коробки. API-шлюз позволяет вам массажировать взаимодействие с вашим клиентом, позволяя с помощью одного компонента платформы обрабатывать кэширование, запоминание, обмен сообщениями между клиентами, внесение в черный список, регистрацию, отказоустойчивость и все другие проблемы масштабирования. Соединение вашего шлюза API с Kubernetes позволит вам масштабироваться до бесконечности с наименьшим количеством возможных проблем. Это лучший метод проектирования, доступный для масштабируемых приложений.

Ответ 3

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

Socket.IO в основном предназначен для реального времени и двунаправленных соединений между клиентом и сервером, а в некоторых приложениях нет необходимости поддерживать постоянные соединения. С другой стороны, асинхронные соединения Ajax должны пройти фазу настройки HTTP-соединения и отправлять данные заголовка и все файлы cookie с каждым запросом.

Socket.IO был разработан как один сервер процессов и может иметь проблемы с масштабируемостью в зависимости от ресурсов сервера, к которым вы привязаны.

Socket.IO не подходит для приложений, когда вам лучше кэшировать результаты клиентских запросов.

Приложения Socket.IO сталкиваются с трудностями с оптимизацией SEO и индексированием поисковых систем.

Socket.IO не является стандартом и не эквивалентен W3C Web Socket API, он использует текущий API веб-сокета, если браузер поддерживает socket.io, созданный человеком для разрешения совместимости с браузером в приложениях реального времени и настолько молод, около 1 года. Его кривая обучения, меньше разработчиков и ресурсы сообщества по сравнению с ajax/jquery, долгосрочное обслуживание и меньшие потребности или лучшие варианты в будущем могут быть важны для разработчиков, чтобы их код был основан на socket.io или нет.