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

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

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

Ответ 5

В этом нет ничего "неправильного".

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

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

Ответ 6

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

Ответ 7

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

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

То есть вы уменьшаете размеры сообщений по цене.

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

Ответ 8

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

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