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

Question

Аналогичные вопросы задавали раньше, и все они пришли к выводу, что AJAX не устареет. Но каким образом ajax лучше, чем websockets?

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

Websockets являются двунаправленными. Если ajax выполнит асинхронный запрос, клиент websocket отправит сообщение на сервер. Параметры POST/GET могут быть закодированы в JSON.

Итак, что не так с использованием 100% -ных веб-карт? Если каждый посетитель поддерживает постоянное соединение с сервером на сервере, это будет более расточительно, чем создание нескольких аякс-запросов на протяжении всего сеанса посещения?

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

websocket api to replace rest api?

Answer 5

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

Answer 6

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

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

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

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

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

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

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

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

Короче:
- Однонаправленный от клиента: Ajax
- Однонаправленный с сервера: SSE
- Двунаправленный: WebSockets

Answer 7

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

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

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

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

Answer 8

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

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