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

Ответ 1

WebSockets не предназначен для замены AJAX и не является строго заменой Comet/long-poll (хотя есть много случаев, когда это имеет смысл).

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

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

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

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

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

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

Ответ 2

Ускоренный переход к декабрю 2017 года, Websockets поддерживаются (практически) каждым браузером, и их использование очень распространено.

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

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

AJAX для опроса?

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

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

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

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

AJAX для ОТДЫХА?

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

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

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

2. REST-вызовы и закачки с использованием AJAX значительно проще кодировать, как на клиенте, так и на бэкэнд.

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

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

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

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

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

Кодируя логику фрагментации загрузки, легко возобновить прерванную загрузку (сложная часть кодировала вещь).

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

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

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

Ответ 7

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