Веб-сокеты делают ajax/CORS устаревшими?

Будет ли веб-сокеты при использовании во всех браузерах сделать ajax устаревшим?

Причина, если я могу использовать веб-сокеты для извлечения данных и обновления данных в реальном времени, зачем мне нужен ajax? Даже если я использую ajax, чтобы просто извлекать данные один раз при запуске приложения, я все равно могу посмотреть, изменились ли эти данные через некоторое время.

И будут ли сетевые сокеты возможными в кросс-доменах или только в одном и том же происхождении?

Ответ 1

WebSockets не сделает AJAX полностью устаревшим, а WebSockets - междоменным.

AJAX

Механизмы AJAX могут использоваться с обычными веб-серверами. На своем самом базовом уровне AJAX - это всего лишь способ для веб-страницы сделать HTTP-запрос. WebSockets - это протокол с более низким уровнем и требует сервера WebSockets (встроенного в веб-сервер, автономного или проксированного с веб-сервера на автономный сервер).

С помощью WebSockets кадрирование и полезная нагрузка определяются приложением. Вы можете отправлять HTML/XML/JSON обратно и обратно между клиентом и сервером, но вы не вынуждены. AJAX - это HTTP. У WebSockets есть дружеское квитирование, но WebSockets не HTTP. WebSockets - это двунаправленный протокол, который ближе к исходным сокетам (преднамеренно), чем к HTTP. Данные полезной нагрузки WebSockets - это кодировка UTF-8 в текущей версии стандарта, но это, вероятно, будет изменено/расширено в будущих версиях.

Таким образом, вероятно, всегда будет место для запросов типа AJAX даже в мире, где все клиенты поддерживают WebSockets изначально. WebSockets пытается решить ситуации, когда AJAX не способен или малейшим образом (потому что WebSockets имеет двунаправленные и гораздо более низкие издержки). Но WebSockets не заменяет все, для чего используется AJAX.

Cross-Domain

Да, WebSockets поддерживает кросс-домен. Первоначальное рукопожатие для настройки соединения связывает информацию о политике начала. На странице wikipedia показан пример типичного рукопожатия: http://en.wikipedia.org/wiki/WebSockets

Ответ 2

Я попытаюсь разбить это на вопросы:

Будет ли веб-сокеты при использовании во всех браузерах сделать ajax устаревшим?

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

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

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

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

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

И будут ли сетевые сокеты возможными в кросс-доменах или только в одном и том же происхождении?

У вас могут быть межсетевые WebSockets, но вы должны закодировать свой WS-сервер, чтобы принять их. У вас есть доступ к заголовку домена (хоста), который вы можете использовать для принятия/отклонения запросов. Это может, однако, быть подделано чем-то простым, как nc. Чтобы действительно защитить соединение, вам необходимо аутентифицировать соединение другими способами.

Ответ 3

В Websockets есть несколько больших недостатков с точки зрения масштабируемости, которые избегают ajax. Поскольку ajax отправляет запрос/ответ и закрывает соединение (.. или вскоре после), если кто-то остается на веб-странице, он не использует серверные ресурсы при холостом ходу. Websockets предназначены для передачи данных обратно в браузер, и для этого они связывают серверные ресурсы. Серверы имеют ограничение на количество одновременных подключений, которые они могут одновременно открывать. Не говоря уже о том, что в зависимости от вашей серверной технологии они могут связывать поток для обработки сокета. Таким образом, веб-узлы имеют более ресурсоемкие требования для обеих сторон для каждого соединения. Вы можете легко исчерпать все ваши клиенты, обслуживающие темы, а затем новые клиенты не могут войти, если на странице просто сидят пользователи. Именно здесь nodejs, vertx, netty действительно могут помочь, но даже те имеют верхние пределы.

Также возникает проблема состояния базового сокета и написания кода с обеих сторон, который ведет разговор с состоянием, который не является чем-то, что вам нужно сделать с ajax-стилем, потому что он без гражданства. Websockets требуют, чтобы вы создали протокол низкого уровня, который решается для вас с помощью ajax. В настоящее время жизненно важны такие вещи, как избиение сердца, закрытие незанятых соединений, повторное подключение к ошибкам и т.д. Это то, что вам не нужно было решать при использовании AJAX, потому что он был без гражданства. Состояние очень важно для стабильности вашего приложения и, что более важно, для здоровья вашего сервера. Это не тривиально. В предварительном HTTP-протоколе мы построили много протоколов TCP с поддержкой состояния (FTP, telnet, SSH), а затем HTTP. И никто больше этого не делал, потому что даже с его ограничениями HTTP был на удивление проще и надежнее. Websockets возвращают хорошее и плохое протоколы с состоянием. Вы узнаете достаточно скоро, если вы не получите дозу этого последнего времени.

Если вам нужна потоковая передача данных в реальном времени, это дополнительные накладные расходы оправданы, потому что опрос сервера для получения потоковых данных хуже, но если все, что вы делаете, это пользовательский интерфейс- > запрос- > ответ- > обновить интерфейс, то ajax проще и будет использовать меньше ресурсов, поскольку после отправки ответа разговор завершается, и никакие дополнительные ресурсы сервера не используются. Поэтому я думаю, что это компромисс, и архитектор должен решить, какой инструмент подходит для их проблемы. AJAX имеет свое место, и веб-узлы имеют свое место.

Обновление

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

Модель HTTP-запроса/ответа делает ее очень эффективной при переключении потоков для новых сокетов. Если вы просто собираетесь использовать запрос/ответ, используйте HTTP, который он уже построил, и намного проще, чем переопределять что-то подобное в websockets.

Так как websockets не должны быть запросом/ответом как HTTP и могут передавать данные, если ваш сервер имеет фиксированное количество потоков в пуле потоков, и у вас есть такое же количество веб-узлов, связывающих все ваши потоки с активными цепочками, вы не можете обслуживать новых клиентов! Вы достигли максимальной емкости. То, что протокол имеет важное значение также с websockets и потоками. Ваш протокол может позволить вам ослабить поток для каждого сокета на каждой модели беседы таким образом, чтобы люди, сидевшие там, не использовали поток на вашем сервере.

Что там, где присутствуют асинхронные серверы с одним потоком. В Java мы часто называем этот NIO для неблокирующего ввода-вывода. Это означает, что это другой API для сокетов, где отправка и получение данных не блокирует поток, выполняющий вызов.

Так традиционно в блокирующих сокетах, когда вы вызываете socket.read() или socket.write(), они ждут, пока данные будут получены или отправлены, прежде чем возвращать управление вашей программе. Это означает, что ваша программа застряла, ожидая, когда данные сокета поступят или выходят, пока вы не сможете сделать что-либо еще. Вот почему у нас есть потоки, поэтому мы можем работать одновременно (в то же время). Отправьте эти данные клиенту X, пока я жду данных от клиента Y. Конкуренты - это название игры, когда мы говорим о серверах.

В NIO-сервере мы используем один поток для обработки всех клиентов и регистрации обратных вызовов, которые будут уведомлены о прибытии данных. Например

socket.read( function( data ) {
   // data is here! Now you can process it very quickly without waiting!
});

Сокет socket.read() будет немедленно возвращаться без чтения каких-либо данных, но наша функция, которую мы предоставили, будет вызываться, когда она появится. Этот проект радикально меняет порядок создания и архивирования вашего кода, потому что, если вы повеситесь, ожидая то, что вы не можете получить новых клиентов. У вас есть нить, которую вы не можете делать сразу сразу. Вы должны держать этот поток в движении.

NIO, Asynchronous IO, программа, основанная на событиях, поскольку все это известно, представляет собой гораздо более сложный системный дизайн, и я бы не предложил вам попробовать и написать это, если вы начинаете. Даже очень старшим программистам очень сложно создавать надежные системы. Поскольку вы асинхронны, вы не можете вызывать блокируемые API. Подобно чтению данных из БД или отправке сообщений на другие серверы, необходимо выполнить асинхронно. Даже чтение/запись из файловой системы может замедлить ваш единственный поток, уменьшая масштабируемость. Когда вы идете асинхронно, все асинхронно все время, если вы хотите, чтобы один поток перемещался. То, где это становится сложным, потому что в конечном итоге вы столкнетесь с API, например с DB, который не является асинхронным, и вам нужно принять больше потоков на определенном уровне. Таким образом, гибридные подходы распространены даже в асинхронном мире.

Хорошей новостью являются другие решения, которые используют этот API более низкого уровня, уже построенный, который вы можете использовать. NodeJS, Vertx, Netty, Apache Mina, Play Framework, Twisted Python, Stackless Python и т.д. Может быть какая-то неясная библиотека для С++, но, честно говоря, я бы не стал беспокоиться. Серверная технология не требует самых быстрых языков, потому что она связана с привязкой более чем к ЦП. Если вы умеете умереть, используйте Java. У этого есть огромное сообщество кода, чтобы тянуть, и это скорость очень близко (а иногда и лучше), чем С++. Если вы просто ненавидите его с помощью Node или Python.

Ответ 4

Да, да.: D

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