Зачем использовать AJAX, когда доступны WebSockets?

Я уже некоторое время использую WebSockets. Я решил создать инструмент управления Agile-проектами для своего последнего учебного года в университете, используя сервер Node и WebSockets. Я обнаружил, что использование WebSockets увеличило на 624% число запросов в секунду, которое могло обрабатывать мое приложение.

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

Это приводит меня к вопросу:

Зачем использовать AJAX, когда кажется, что WebSockets делает такую большую работу по снижению задержки и нехватки ресурсов, есть ли что-нибудь, что AJAX делает лучше, чем WebSockets?

 Dante30 апр. 2012 г., 03:08
Вот список движков, которые поддерживают веб-сокеты. En.wikipedia.org / вики / ...
 Rune Jeppesen08 янв. 2018 г., 11:20

Ответы на вопрос(7)

Решение Вопроса

для Comet / long-poll (хотя во многих случаях это имеет смысл).

Целью WebSockets является обеспечение двунаправленного, дуплексного и долговременного соединения между браузером и сервером с низкой задержкой. WebSockets открывает новые домены приложений для браузерных приложений, которые на самом деле были невозможны с использованием HTTP и AJAX (интерактивные игры, динамические потоки мультимедиа, соединение с существующими сетевыми протоколами и т. Д.).

Однако между WebSockets и AJAX / Comet есть определенное совпадение. Например, когда браузер хочет получать уведомления о серверных событиях (например, push), методы Comet и WebSockets, безусловно, являются приемлемыми вариантами. Если вашему приложению требуются push-события с низкой задержкой, это будет фактором в пользу WebSockets. С другой стороны, если вам необходимо сосуществовать с существующими инфраструктурами и развернутыми технологиями (OAuth, RESTful API, прокси, балансировщиками нагрузки), то это будет фактором в пользу методов Comet (на данный момент).

Если вам не нужны особые преимущества, которые предоставляет WebSockets, то, вероятно, лучше придерживаться существующих методов, таких как AJAX и Comet, поскольку это позволяет вам повторно использовать и интегрировать с огромной существующей экосистемой инструментов, технологий, безопасности механизмы, базы знаний (т. е. гораздо больше людей в стеке потока знают HTTP / Ajax / Comet, чем WebSockets) и т. д.

С другой стороны, если вы создаете новое приложение, которое не работает должным образом с задержкой и ограничениями соединения HTTP / Ajax / Comet, тогда подумайте об использовании WebSockets.

Кроме того, некоторые ответы указывают, что одним из недостатков WebSockets является ограниченная / смешанная поддержка серверов и браузеров. Позвольте мне немного рассказать об этом. Хотя iOS (iPhone, iPad) по-прежнему поддерживает старый протокол (Hixie), большинство серверов WebSockets поддерживают как Hixie, так и HyBi / IETF 6455 версия. Большинство других платформ (если они еще не имеют встроенной поддержки) могут получить поддержку WebSockets через Веб-сокетов-JS (Полифилл на основе Flash). Это охватывает подавляющее большинство веб-пользователей. Кроме того, если вы используете Node в качестве серверной части, подумайте об использовании Socket.IO, который включает web-socket-js в качестве запасного варианта, и если даже он недоступен (или отключен), он вернется к использованию любой техники Comet, доступной для данного браузера.

Обновит: iOS 6 теперь поддерживает текущий стандарт HyBi / IETF 6455.

 Charlotte Dunois23 янв. 2017 г., 00:05
Извините, но для меня это не ответ на вопрос. В основном это просто говорит о том, что они не предназначены для замены друг друга и что WS не поддерживается полностью (сейчас). Это не отвечает, почему вы бы предпочли AJAX веб-сокету? Давайте возьмем Discord для примера. Discord использует WS для передачи сообщений и событий с сервера клиентам, а также использует HTTP-запросы от клиента к серверу (отправка сообщений, запрос данных и т. Д.). Я пришел к этому вопросу, чтобы получить ответ, почему вы это сделаете. Есть ли какая-то техническая причина, по которой вы бы поместили AJAX выше открытого соединения WS?
 Miles M.28 мар. 2014 г., 18:54
Правда, Opera Mini не поддерживает его, но еще более смущает отсутствие поддержки браузера Android, что делает его немного более сложным для использования с приложениями на основе веб-браузера (Cordova PhoneGap)
 Dirk Bester01 янв. 2014 г., 22:40
А сейчас на заре 2014 года WebSockets практически является стандартом (RFC 6455), и только Opera mini его не поддерживает.
 kanaka07 мая 2014 г., 18:21
@ Pacerier полный ответ будет долгим, но в основном он сводится к тому, что вы пытаетесь повторно реализовать вещи, которые браузер уже делает хорошо (кеширование, безопасность, параллелизм, обработка ошибок и т. Д.). Что касается производительности, хотя скорость передачи больших файлов с нуля была бы одинаковой, у браузеров были годы на тонкую настройку кэширования веб-содержимого (большая часть которого относится к запросам AJAX), поэтому на практике переход от AJAX к WebSockets вряд ли обеспечит выгода для существующего функционала. Но для двунаправленного общения с низкой задержкой это огромная побед
 Pacerier03 мая 2014 г., 02:47
@ kanaka, отправлять файлы через WebSocket быстрее или медленнее по сравнению с HTTP (ajax, comet)?

Вебсокеты поддерживаются (практически) каждым браузером и их использование очень распространено.

Однако это не означает, что Websockets удалось заменить AJAX, по крайней мере, не полностью, особенно в связи с ростом адаптации HTTP / 2.

Короткий ответ: AJAX по-прежнему отлично подходит для большинства приложений REST, даже при использовании веб-сокетов. Но Бог в деталях, так что ...:

AJAX для опроса?

Использование AJAX для опроса (или длительного опроса) вымирает (и так и должно быть), но он по-прежнему используется по двум причинам (в основном для небольших веб-приложений):

Для многих разработчиков AJAX проще в написании кода, особенно когда речь идет о кодировании и проектировании бэкэнда.

С HTTP / 2 была устранена самая высокая стоимость, связанная с AJAX (установление нового соединения), что позволило AJAX-вызовам быть весьма производительными, особенно для публикации и загрузки данных.

Тем не мение,Websocket push намного превосходит AJAX (не требуется повторная проверка подлинности или повторная отправка заголовков, нет необходимости в обходах без данных и т. д.). Это обсуждалось несколько раз.

AJAX для отдыха?

Лучше использовать AJAX для вызовов REST API. Такое использование упрощает базу кода и предотвращает блокирование соединения Websocket (особенно при загрузке данных среднего размера).

Есть несколько неопровержимые причины отдавать предпочтение AJAX для вызовов REST API и загрузка данных:

AJAX API был практически разработан для вызовов REST API, и он отлично подходит.

REST-вызовы и загрузка с использованием AJAX значительно легче кодировать как на клиенте, так и на сервере.

По мере увеличения полезной нагрузки соединения Websocket могут блокироваться, если не будет закодирована логика фрагментации / мультиплексирования сообщений.

Если загрузка выполняется в одном Websocketsend call, он может блокировать поток Websocket до завершения загрузки. Это снизит производительность, особенно на более медленных клиентах.

Обычный дизайн использует небольшие двунаправленные сообщения, передаваемые через веб-сокеты, тогда как REST и загрузка данных (клиент-сервер) используют простоту использования AJAX для предотвращения блокировки веб-сокета.

Однако в более крупных проектах гибкость, предлагаемая Websockets, и баланс между сложностью кода и управлением ресурсами перевесят баланс в пользу Websockets.

Например, при загрузке через Websocket можно возобновить загрузку больших объемов после сброса и восстановления соединения (помните, какой фильм объемом 5 ГБ вы хотите загрузить?).

Благодаря кодировке логики фрагментации загрузки легко возобновить прерванную загрузку (сложная часть - это кодирование

Как насчет HTTP / 2 push?

Мне, вероятно, следует добавить, что функция HTTP / 2 push не заменяет (и, вероятно, не может) Websockets.

Это было обсуждали здесь раньше, но достаточно упомянуть, что одно соединение HTTP / 2 обслуживает весь браузер (все вкладки / окна), поэтому данные, передаваемые HTTP / 2, не знают, к какой вкладке / окну оно принадлежит, что исключает их способность замените способность Websocket отправлять данные непосредственно на определенную вкладку / окно браузера.

Хотя Websockets отлично подходят для передачи небольших двунаправленных данных, AJAX по-прежнему обладает рядом преимуществ - особенно при рассмотрении больших полезных нагрузок (загрузки и т. Д.).

А безопасность?

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

AJAX по своей природе будет иметь преимущество, поскольку его безопасность встроена в код браузера (что иногда сомнительно, но оно все еще там).

С другой стороны, вызовы AJAX более восприимчивы к атакам типа «человек посередине», в то время как проблемы безопасности Websockets обычно представляют собой ошибки в коде приложения, которые привели к недостатку безопасности (обычно вы найдете их в логике аутентификации бэкэнда).

Лично я не вижу в этом особой разницы, если что-то, на мой взгляд, немного лучше, если вы знаете, что делаете.

Мое скромное мнение

IMHO, я бы использовал Websockets для всего, кроме вызовов REST API. Большие загрузки данных я бы фрагментировал и отправлял через Websockets, когда это возможно.

Поллинг, ИМХО, должен быть объявлен вне закона, стоимость сетевого трафика ужасна, а толчок Websocket достаточно прост в управлении даже для новых разработчиков.

 Myst24 дек. 2017 г., 20:42
@ spottedmahn - Спасибо! Наверное, так и происходит, я использую свой редактор кода для черновика текст
 TheCoder08 февр. 2018 г., 21:35
@ Myst спасибо за это замечательное объяснение. Что бы вы предпочли для живых уведомлений, таких как fb / stackoverflow? Я разрабатываю веб-сервисы RestFull для своего веб-приложения, но очень смущен тем, что я должен использовать для функции уведомлений? AJAX или WebSockets?
 Duncan Jones02 янв. 2018 г., 13:44
Извинения, я отсутствовал, когда истек срок действия щедрости. Плохое планирование с моей стороны. Я назначил еще одну награду, которую я назначу вам по истечении 23 часов.
 Myst08 февр. 2018 г., 22:04
@ puspen уведомления (IMHO) отлично подходят для Websockets. При разработке логики переподключения и автономных очередей уведомлений необходимо принять множество решений, но фактическое уведомление легко кодировать и выполнять с помощью веб-сокетов.
 spottedmahn24 дек. 2017 г., 20:38
Небольшая грамматическая ошибка: «Если что-нибудь я придумаю ..

те, которые поддерживают это часто имеют разные реализации. Это в значительной степени единственная причина, почему они не используются постоянно вместо AJAX.

 Pacerier03 мая 2014 г., 03:11
@ DanD., HTTP и WebSocket - это два разных протокола. Конечно, мы не можем запрашивать ресурсы HTTP, используя протокол WebSocket, по той же причине, по которой мы не можем запрашивать ресурсы WebSocket, используя протокол HTTP! Это не означает, что клиент не может запрашивать HTML-файлы и / или файлы изображений, отправленные по протоколу Websocket.
 Dan D.30 апр. 2012 г., 03:10
Лучшая причина в том, что AJAX-запрос - это обычный HTTP-запрос, который означает, что он может извлекать HTTP-ресурсы; WebSockets не может этого сделать.
 vsync15 мая 2013 г., 20:13
@ Dan D - иногда вы не хотите, чтобы вся эта чушь перешла все границы, например, куки и заголовки ...
 Jack30 апр. 2012 г., 03:12
@ Dan Что, если, например, файлы изображений отправляются как base64, CSS как текст, JavaScript также как текст и затем добавляются в документ? Это было бы правдоподобно?
 jli30 апр. 2012 г., 03:12
@ Dand. +1, я согласен, думаю, я больше подходил к вопросу из контекста быстрой потоковой передачи данных, как в примере вопроса, но это определенно правильно.

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

так как WebSockets будет поддерживаться начиная с IE10), по-прежнему существуют большие проблемы с сетевыми посредниками, которые еще не поддерживают WebSockets, включая прозрачные прокси, обратные прокси-серверы и балансировщики нагрузки. Некоторые операторы мобильной связи полностью блокируют трафик WebSocket (то есть после команды HTTP UPGRADE).

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

 Tracker130 апр. 2012 г., 19:25
К счастью, большинство фреймворков WebSocket поддерживают указанные недостатки, в том числе использование Flash для сокетов. Socketn.IO и SignalR - достойные фреймворки ... хотя вы действительно ограничены, как вы упомянули из-за прокси и балансировщиков нагрузки. К счастью, и Node.JS, и следующий IIS отлично справляются с этой ролью.
 Alessandro Alinone08 июн. 2012 г., 15:21
Например, в настоящее время Vodafone Italy блокирует WS на порту 80, но разрешает WSS на порту 443. Вы можете довольно легко протестировать любой носитель через нашу домашнюю страницу, к которой вы можете получить доступ как по HTTP, так и по HTTPS. Он пытается WebSockets и возвращается к HTTP, если они заблокированы. Используйте этот URL для отображения в середине виджета, который сообщает о текущем транспорте: Lightstreamer.com /? S
 oberstet01 июн. 2012 г., 16:45
Curious: какие носители блокируют WebSocket на порту 80? Какой блок защищен WebSocket (WSS) на порте 443? Последнее подразумевает принудительные, прозрачные веб-прокси MITM ... никогда не видел этого в публичных сетях (только в корпоративных), поскольку требует установки новых сертификатов CA в браузерах.

ента, которая может обрабатывать конечную точку Websocket, например, API-интерфейсы REST, и конечные точки RESTful, такие как Websockets на клиенте.https: //github.com/mikedeshazer/sockres Кроме того, для тех, кто пытается использовать API веб-сокетов на клиенте или наоборот, как они привыкли. Libs / sockrest.js в значительной степени проясняет различия (или, скорее, должен).

что мы можем провести четкое сравнение Websockets и HTTP, поскольку они не являются конкурентами и не решают одни и те же проблемы.

Websockets - отличный выбор для обработки долгоживущих двунаправленных потоков данных практически в режиме реального времени, тогда как REST отлично подходит для периодической связи. Использование веб-сокетов является значительным капиталовложением и, следовательно, избыточным для случайных подключений.

Вы можете обнаружить, что при наличии высоких нагрузок веб-сокеты работают лучше, в некоторых случаях HTTP работает немного быстрее, поскольку он может использовать кэширование. Сравнение REST с Websockets похоже на сравнение яблок с апельсинами.

Мы должны проверить, какое из них обеспечивает лучшее решение для нашего приложения, которое лучше всего подходит для нашего варианта использовани

 Myst27 дек. 2017 г., 12:30
вопрос был об AJAX в целом, а не о REST в частности. Это правда, что AJAX может использоваться для REST, но он также используется для опроса и длинного опроса. Хотя я согласен с вашим выводом (как вы можете сказать из моего ответа), я думаю, что ваш ответ может отражать это различие (обратите внимание, что Websockets можно использовать и для REST, хотя и не с использованием методов HTTP).
 Gaurav Gandhi28 дек. 2017 г., 06:12
@ Я согласен с тобой.

Ваш ответ на вопрос