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

Question

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

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

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

Answer 1

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

АЯКС

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

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

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

Междоменный

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

Answer 2

Я постараюсь сломать это на вопросы:

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

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

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

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

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

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

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

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

Answer 3

Websockets имеют пару больших нисходящих с точки зрения масштабируемости, которые Ajax избегает. Поскольку Ajax отправляет запрос / ответ и закрывает соединение (..OR вскоре после), если кто-то остается на веб-странице, он не использует серверные ресурсы при нахождении на холостом ходу. WebSockets предназначены для потоковых данных обратно в браузер, и они связывают ресурсы сервера для этого. Серверы имеют ограничение в том, сколько одновременных подключений они могут оставаться открытыми одновременно. Не упоминать в зависимости от вашей боковой технологии серверов, они могут завязать нить для обработки розетки. Таким образом, Websockets имеют более ресурсные интенсивные требования для обеих сторон на связи. Вы можете легко исчерпать все ваши темы обслуживания обслуживающих клиентов, а затем новые клиенты не могут прийти, если бы много пользователей просто сидят на странице. Это где Nodejs, Vertx, Netty может действительно помочь, но даже у них есть верхние пределы.

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

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

Обновлять

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

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

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

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

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

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

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

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

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

Хорошие новости в том, что есть и другие решения, которые используют этот нижний уровень API, уже построен, что вы можете использовать. Nodejs, VertX, Netty, Apache Mina, Play Framework, витой Python, Stackless Python и т. Д. Там может быть некоторая неясная библиотека для C ++, но, честно говоря, я не буду беспокоиться. Серверная технология не требует самых быстрых языков, потому что это IO связано больше, чем граница ЦП. Если вы используете гайку жесткого характеристики, используйте Java. Он имеет огромное сообщество кода для тяги от и его скорость очень близко (а иногда лучше), чем C ++. Если вы просто ненавидите, он идет с узлом или Python.

Answer 4

Да, да, это делает. : D.

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