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

Ускоренный переход к декабрю 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 достаточно легко справиться даже для новых разработчиков.

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

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

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

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

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

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

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

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

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