В чем недостаток использования websocket / socket.io там, где будет работать ajax?

Я думаю, это было бы расточительнее. Для каждого подключенного клиента вам нужен какой-то объект / функция / код / ​​что-то еще на сервере в паре с этим одним клиентом. Обработчик сокета или дескриптор файла, или что-то еще, ваш сервер настроен для обработки подключений.

С AJAX вам не нужно сопоставление ресурсов сервера с клиентом 1: 1. Количество клиентов может масштабироваться менее зависимо, чем ресурсы на стороне сервера. Даже у node.js есть ограничения на количество подключений, которые он может обрабатывать и держать открытыми.

Также следует учитывать, что некоторые ответы AJAX тоже можно кэшировать. По мере увеличения масштаба вы можете добавить кеш HTTP, чтобы снизить нагрузку от частых запросов AJAX.

Краткий ответ
Поддержание активного веб-сокета требует затрат как для клиента, так и для сервера, независимо от того, будет ли Ajax стоить только один раз, в зависимости от того, что вы с ним делаете.

Длинный ответ
Веб-сокеты часто неправильно понимают из-за всего этого «Эй, используйте Ajax, это подойдет!». Нет, веб-сокеты не заменяют Ajax. Они потенциально могут применяться к одним и тем же полям, но бывают случаи, когда использование Websocket абсурдно.

Возьмем простой пример: динамическая страница, которая загружает данные после загрузки страницы на стороне клиента. Это просто, сделайте вызов Ajax. Нам нужно только одно направление, от сервера к клиенту. Клиент запросит эти данные, сервер отправит их клиенту, готово. Зачем вам реализовывать веб-сокеты для такой задачи? Вам не нужно, чтобы ваше соединение было постоянно открыто, вам не нужно, чтобы клиент постоянно запрашивал сервер, вам не нужно, чтобы сервер уведомлял клиента. Соединение останется открытым, оно будет тратить ресурсы, потому что, чтобы соединение оставалось открытым, вам нужно постоянно его проверять.

Теперь с приложением чата все по-другому. Вам нужно, чтобы ваш клиент получал уведомление от сервера, вместо того, чтобы заставлять его запрашивать сервер каждые x секунд или миллисекунды, если что-то ново. В этом нет смысла.

Чтобы лучше понять, рассмотрите это как два человека. Один из двух - это сервер, второй - клиент. Ajax похож на отправку письма. Клиент отправляет письмо, сервер отвечает другим письмом. Дело в том, что для приложения чата разговор будет таким:
«Привет, Сервер, есть что-то для меня?
- Нет.
- Привет, Сервер, есть что-то для меня?
- Нет.
- Эй, сервер, есть что-то для меня?
- Да, вот оно. »
Сервер не может отправить письмо клиенту, если клиент никогда не запрашивал ответа. Это огромная трата ресурсов. Потому что для каждого запроса Ajax, даже если он кэширован, вам необходимо выполнить операцию на стороне сервера.

Теперь случай, который я обсуждал ранее, с данными, загруженными с помощью Ajax. Представьте, что клиент разговаривает по телефону с сервером. За поддержание активного соединения приходится платить. Это стоит электричество, и вы должны платить своему оператору. Теперь зачем вам звонить кому-то и держать его на телефоне в течение часа, если вы просто хотите, чтобы этот человек сказал вам 3 слова? Отправь проклятое письмо.

В заключение, Websocket не является полной заменой Ajax!
Иногда вам понадобится Ajax там, где использование Websocket абсурдно.

Изменить: случай SSE
Эта технология не очень широко используется, но может быть полезна. Как следует из названия, отправленные сервером события - это односторонняя передача от сервера к клиенту. Клиент ничего не запрашивает, сервер просто отправляет данные.

Вкратце:
- Однонаправленный от клиента: Ajax
- Однонаправленный от сервера: SSE
- Двунаправленный: Websockets

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

Такие проекты, как DNode и socketstream, помогают устранить сложность и обеспечить простое кодирование в стиле RPC. Это означает, что ваш клиентский код просто вызывает функцию на сервере, передавая ей нужные данные. И сервер может вызывать функцию на клиенте и передавать ему данные. Вам не нужно беспокоиться о мельчайших подробностях TCP.

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

Я подробно ответил на другой связанный с этим вопрос, включая множество ссылок на связанные ресурсы. Вы можете проверить это:

api websocket для замены rest api?

Я думаю, что рано или поздно фреймворки на основе веб-сокетов начнут появляться не только для написания чатов в реальном времени, таких как части веб-приложений, но и как отдельные веб-фреймворки. После создания постоянного соединения его можно использовать для получения всех видов материалов, включая части пользовательского интерфейса веб-приложения, которые теперь обслуживаются, например, через запросы AJAX. Такой подход может в некоторой степени повредить SEO, хотя он может уменьшить объем трафика и нагрузку, создаваемую асинхронными запросами, которые включают в себя избыточные заголовки HTTP.

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

В этом нет ничего "плохого".

Единственная разница - в основном удобочитаемость. Основное преимущество Ajax заключается в том, что он позволяет вам быстро разрабатывать, поскольку большая часть функций написана для вас.

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

Соединения WS: // имеют гораздо меньше накладных расходов, чем запросы AJAX.

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

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

То есть вы уменьшаете размер сообщения за счет затрат.

Итак, мой выбор - AJAX для запроса-ответа, веб-сокеты для отправки на сервер и высокочастотный обмен сообщениями с низкой задержкой.

Если вы хотите, чтобы соединение с сервером было открыто, и если будет непрерывный опрос на сервере, тогда переходите на сокеты, иначе вам хорошо пойти с ajax.

Простая аналогия: Ajax задает вопросы (запросы) серверу, а сервер дает ответы (ответы) на эти вопросы. Теперь, если вы хотите задавать непрерывные вопросы, тогда ajax не будет работать, у него большие накладные расходы, которые потребуют ресурсов на обоих концах.