В этой ветке много распространенной дезинформации, которая очень неточна.
TL / DR; WebSocket заменяет HTTP для приложений! Он был разработан Google с помощью Microsoft и многих других ведущих компаний. Все браузеры его поддерживают. Никаких минусов.
SocketIO построен на основе протокола WebSocket (RFC 6455). Он был разработан для полной замены AJAX. У него вообще нет проблем с масштабируемостью. Он работает быстрее, чем AJAX, при этом потребляет на порядок меньше ресурсов.
AJAX исполнилось 10 лет, и он построен на основе единственного JavaScript XMLHTTPRequest функция, которая была добавлена, чтобы разрешить обратные вызовы серверам без перезагрузки всей страницы.
Другими словами, AJAX - это протокол документов (HTTP) с единственной функцией JavaScript.
Напротив, WebSocket - это протокол приложения, который был разработан для полной замены HTTP. Когда вы обновляете HTTP-соединение (запрашивая протокол WebSocket), вы включаете двустороннюю полнодуплексную связь с сервером, и никакого подтверждения протокола не требуется. С AJAX вы должны либо включить keep-alive (то же самое, что и 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 поддерживает открытое соединение, рукопожатие отсутствует, а время ответа сервера ограничено временем приема-передачи или проверкой связи с самим сервером.
Существует неверная информация о том, что соединение сокет является соединением через порт; Нет. Соединение через сокет - это просто запись в таблице. Потребляется очень мало ресурсов, и один сервер может обеспечить более 1 000 000 соединений WebSocket. Сервер AWS XXL может размещать и поддерживает более 1 000 000 соединений SocketIO.
Соединение AJAX сжимает / сжимает все заголовки 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 на самом деле устарел. если вы пишете настольное приложение, общаетесь ли вы с помощью диалога с помощью REST? Нет :) Это довольно глупо.
SocketIO, использование WebSocket делает то же самое для вас ... вы можете начать думать о клиентской стороне как о простом диалоге для вашего приложения. REST вам больше не нужен.
Фактически, если вы попытаетесь использовать REST при использовании WebSocket, это так же глупо, как использование REST в качестве протокола связи для диалогового окна рабочего стола ... в этом нет абсолютно никакого смысла.
Что ты говоришь, Тимми? А как насчет других приложений, которые хотят использовать ваше приложение? Вы должны дать им доступ к REST? Тимми ... WebSocket отсутствует уже 4 года ... Просто попросите их подключиться к вашему приложению с помощью WebSocket и позвольте им запрашивать сообщения, используя тот протокол ... он будет потреблять в 50 раз меньше ресурсов, быть намного быстрее и в 10 раз легче развиваться ... Зачем поддерживать прошлое, когда вы создаете будущее?
Конечно, есть варианты использования REST, но все они предназначены для старых и устаревших систем ... Большинство людей просто еще не знают об этом.
ОБНОВИТЬ:
МНОГО людей недавно спрашивали меня, как они могут начать писать приложение в 2018 году (а теперь уже скоро в 2019 году) с использованием WebSockets, что барьер кажется очень высоким, и когда они начнут играть с Socket.IO, они не знаю, куда еще обратиться и чему научиться.
К счастью, последние 3 года были очень хороши для WebSockets ...
В настоящее время существует 3 основных фреймворка, которые поддерживают ОБЕ REST и WebSocket, и даже протоколы IoT или другие минимальные / быстрые протоколы, такие как ZeroMQ, и вам не о чем беспокоиться; вы просто получаете поддержку прямо из коробки.
Примечание. Хотя Meteor, безусловно, является самым популярным, я опускаю его, потому что, хотя это очень, очень хорошо финансируемый фреймворк WebSocket, любой, кто писал код с Meteor в течение нескольких лет, скажет вам , это внутренний беспорядок и кошмар в масштабе. В некотором роде WordPress похож на PHP, он есть, он популярен, но сделан не очень хорошо. Он не продуман до мелочей и скоро умрет. Извините, ребята, Meteor, но посмотрите эти 3 других проекта по сравнению с Meteor, и вы выбросите Meteor в тот же день :)
Со всеми нижеприведенными фреймворками вы пишете свой сервис один раз и получаете поддержку как REST, так и WebSocket. Более того, это одна строка кода конфигурации для переключения практически между любой серверной базой данных.
Feathers Самый простой в использовании, работает одинаково на передней и внутренней стороне и поддерживает большинство функций. Feathers - это коллекция света. -весные обертки для существующих инструментов, таких как экспресс. Используя потрясающие инструменты, такие как перья-vuex, вы можете создавать неизменяемые сервисы, которые полностью подделывать, поддерживать REST, WebSocket и другие протоколы (с использованием Primus), а также получать бесплатные полные операции CRUD, включая поиск и разбиение на страницы, без единой строчки кода (просто какой-то конфиг). Также отлично работает с сгенерированными данными, такими как json-schema-faker, поэтому вы можете не только полностью имитировать вещи, но и использовать случайные, но достоверные данные. Вы можете подключить приложение для поддержки поиска с опережающим вводом, создания, удаления и редактирования без кода (просто сконфигурируйте). Как некоторые из вас, возможно, знают, правильная сквозная конфигурация кода является самым большим препятствием для самомодификации кода. Feathers делает это правильно и подтолкнет вас к лидирующей позиции в будущем дизайне приложений.
Moleculer Moleculer, к сожалению, на порядок лучше в серверной части, чем Feathers. Хотя перья будут работать и позволят вам масштабироваться до бесконечности, перья просто даже не задумываются о таких вещах, как производственная кластеризация, рабочие консоли серверов, отказоустойчивость, готовые журналы трубопроводов или шлюзы API (пока я создавал производственный шлюз API от Feathers, Moleculer делает это лучше, намного лучше). Moleculer также является самым быстрорастущим как по популярности, так и по новым функциям, чем любой фреймворк WebSocket.
Победный удар с Moleculer заключается в том, что вы можете использовать интерфейс Feathers или ActionHero с серверной частью Moleculer, и, хотя вы потеряете некоторые генераторы, вы получите много качества производства.
Из-за этого я рекомендую изучить Feathers как на переднем, так и на внутреннем интерфейсе, и как только вы создадите свое первое приложение, попробуйте переключить свой сервер на Moleculer. Начать работу с Moleculer сложнее, но только потому, что он решает все проблемы масштабирования за вас, и эта информация может запутать новых пользователей.
ActionHero Указан здесь как жизнеспособная альтернатива, но Feathers и Moleculer являются лучшими реализациями. Если что-то в ActionHero вам не нравится, не используйте его; есть два лучших способа, описанных выше, которые дают вам больше и быстрее.
ПРИМЕЧАНИЕ. Шлюзы API - это будущее, и все 3 вышеперечисленных поддерживают их, но Moleculer буквально дает вам это прямо из коробки. Шлюз API позволяет массировать взаимодействие с клиентом, позволяя кэшировать, запоминать, отправлять сообщения клиент-клиент, заносить в черный список, регистрировать, обеспечивать отказоустойчивость и все другие проблемы масштабирования, которые решаются одним компонентом платформы. Соединение вашего API-шлюза с Kubernetes позволит вам масштабироваться до бесконечности с наименьшим количеством возможных проблем. Это лучший метод проектирования для масштабируемых приложений.
Обновление 2021 года:
Индустрия настолько изменилась, что вам даже не нужно обращать внимание на протокол. GraphQL теперь по умолчанию использует WebSockets! Просто посмотрите, как использовать подписки, и готово. Самый быстрый способ справиться с этим - вы сами.
Если вы используете Vue, React или Angular, вам повезло, потому что для вас есть собственная реализация GraphQL! Просто вызовите свои данные с сервера с помощью подписки GraphQL, и этот объект данных будет обновляться и реагировать сам по себе.
GraphQL даже вернется к REST, когда вам нужно использовать устаревшие системы, а подписки по-прежнему будут обновляться с использованием сокетов. Все решается при переходе на GraphQL.
Да если бы вы думали, WTH?!? когда вы услышали, что вы можете просто подписаться, как с FireBase, на объект сервера, и он обновится за вас. да. Теперь это правда. Просто используйте подписку GraphQL. Он будет использовать WebSockets.
Система чата? 1 строка кода. Видеосистема в реальном времени? 1 строка кода. Видеоигра с 10 МБ данных открытого мира, доступными 1 млн пользователей в режиме реального времени? 1 строка кода. Теперь код - это просто ваш запрос GQL.
Пока вы создаете или используете правильную серверную часть, все эти вещи в реальном времени теперь выполняются за вас с помощью подписок GQL. Переключитесь как можно скорее и перестаньте беспокоиться о протоколах.
person
Nick Steele
schedule
21.12.2015
