В каких ситуациях длинный / короткий опрос AJAX предпочтительнее HTML5 WebSockets?

306

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

В настоящее время я реализую это с помощью простого AJAX, но недостатком является регулярное попадание на сервер по истечении короткого таймера.

При исследовании длинных / коротких опросов я наткнулся на HTML5 WebSockets. Это кажется простым для реализации, но я не уверен, есть ли какие-то скрытые недостатки. Например, я думаю, что WebSockets поддерживается только определенными браузерами. Есть ли другие недостатки WebSockets, о которых я должен знать?

Поскольку кажется, что обе технологии делают одно и то же, в каких типах сценариев предпочтение будет отдаваться одному другому? В частности, сделали ли HTML5 WebSockets AJAX длинным / коротким опросом устаревшим или есть веские причины предпочесть AJAX над WebSockets?

somdow
источник

Ответы:

508

WebSockets, безусловно, будущее.

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

WebRTC обеспечивает одноранговую связь.

Я рекомендую изучать WebSockets .

Сравнение:

различных методов общения в Интернете

  • AJAX - requestresponse. Создает соединение с сервером, отправляет заголовки запроса с дополнительными данными, получает ответ от сервера и закрывает соединение. Поддерживается во всех основных браузерах.

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

  • WebSockets - clientserver. Создайте TCP-соединение с сервером и оставляйте его открытым столько, сколько нужно. Сервер или клиент могут легко закрыть соединение. Клиент проходит через HTTP-совместимый процесс рукопожатия. Если это удастся, то сервер и клиент могут обмениваться данными в обоих направлениях в любое время. Это эффективно, если приложение требует частого обмена данными обоими способами. В WebSockets есть кадрирование данных, которое включает маскирование для каждого сообщения, отправляемого с клиента на сервер, поэтому данные просто шифруются. график поддержки (очень хорошо) | википедия

  • WebRTC - peerподдержка диаграммы (средняя) | википедияpeer . Транспорт для установления связи между клиентами и является независимым от транспорта, поэтому он может использовать UDP, TCP или даже более абстрактные уровни. Это обычно используется для передачи данных большого объема, такой как потоковое видео / аудио, где надежность является вторичной, и несколько кадров или снижение качества могут быть принесены в жертву в пользу времени отклика и, по меньшей мере, некоторой передачи данных. Обе стороны (одноранговые узлы) могут передавать данные друг другу независимо. Хотя он может использоваться полностью независимо от любых централизованных серверов, он все же требует некоторого способа обмена данными конечных точек, где в большинстве случаев разработчики все еще используют централизованные серверы для «связи» одноранговых узлов. Это требуется только для обмена важными данными для установления соединения, после чего централизованный сервер не требуется.

  • Отправленные сервером события - clientserver. Клиент устанавливает постоянное и долгосрочное соединение с сервером. Только сервер может отправлять данные клиенту. Если клиент хочет отправить данные на сервер, для этого потребуется использовать другую технологию / протокол. Этот протокол совместим с HTTP и прост в реализации на большинстве серверных платформ. Это предпочтительный протокол, который следует использовать вместо длительного опроса. график поддержки (хорошо, кроме IE) | википедия

Преимущества:

Основное преимущество серверной части WebSockets заключается в том, что это не HTTP-запрос (после рукопожатия), а надлежащий протокол связи на основе сообщений. Это позволяет достичь огромных преимуществ в производительности и архитектуре . Например, в файле node.js вы можете использовать одну и ту же память для разных соединений с сокетами, чтобы каждый из них мог обращаться к общим переменным. Следовательно, вам не нужно использовать базу данных в качестве точки обмена в середине (например, с AJAX или Long Polling с таким языком, как PHP). Вы можете хранить данные в оперативной памяти или даже сразу же переиздавать их между сокетами.

Соображения безопасности

Люди часто беспокоятся о безопасности WebSockets. Реальность такова, что это не имеет большого значения или даже делает WebSockets лучшим вариантом. Прежде всего, с AJAX, существует более высокая вероятность MITM , так как каждый запрос является новым TCP-соединением, которое проходит через интернет-инфраструктуру. С WebSockets, когда он подключен, гораздо сложнее перехватывать между ними, с дополнительной принудительной маскировкой кадров, когда данные передаются от клиента к серверу, а также с дополнительным сжатием, которое требует больше усилий для проверки данных. Все современные протоколы поддерживают оба: HTTP и HTTPS (зашифрованные).

PS

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

мокко
источник
15
Дело не в совместимости. Самое главное, что он собирается полностью переосмыслить, как происходит общение. Поскольку RESTful API работают с шаблоном Request> Response, двунаправленная связь здесь будет бессмысленной. Поэтому попытка использовать WebSockets для запроса RESTful API - это немного странная попытка, и она не видит никакой выгоды от нее вообще. Если вам нужны данные из RESTful API, но в режиме реального времени, вы создаете API WebSockets для передачи данных, которые будут работать с двунаправленной связью, такой как WebSockets. Вы пытаетесь сравнить вещи под углом, что они несопоставимы :)
moka
2
Привет @pithhelmet, все зависит от серверного программного обеспечения (язык / технология). WebSocket - это слой поверх TCP, и существует множество способов реализации потоков TCP. Современные веб-серверы используют архитектуру, основанную на событиях, и очень эффективны с пулами потоков. Какие технологии вы используете? Node.js использует события за кулисами для ввода-вывода и события с одним потоком в контексте выполнения, так что это удивительно эффективно. Использование потоков для каждого соединения - очень неэффективно с точки зрения оперативной памяти (1 Мб + на поток), а также процессора, поскольку эти потоки будут просто простаивать или, что еще хуже, - бесконечный цикл проверки данных.
Мока
4
Длинный опрос не является грязным обходным путем и отличается от webSocket. Эти два предназначены для использования в другом сценарии.
bagz_man
5
@bagz_man Long Polling - это «хакерское» использование технологии для достижения результатов, которые технология не допускала по определению и не была доступна стандартная альтернатива. Причиной длинного опроса является именно тот факт, что WS не было, период.
Мока
4
@moka: свободный уровень Cloudflare будет поглощать длительную атаку 400 + Гбит / с. Может ли ваш кошелек поглотить счет AWS? Также AWS и Cloudflare придерживаются противоположных взглядов, когда дело касается жалоб на ваше происхождение. Это просто что-то иметь в виду, пока мы обсуждаем компромиссы. :)
Даннеу
11

Одна из конкурирующих технологий, которую вы пропустили, - это отправленные сервером события / источник события. Что такое Long-Polling, Websockets, Server-Sent Events (SSE) и Comet? имеет хорошее обсуждение всех этих. Имейте в виду, что некоторые из них проще, чем другие, интегрировать на стороне сервера.

bmm6o
источник
Из всего этого, что бы вы предложили изучить?
somdow
У меня был успех с длинным опросом, единственная хитрость (для него и других технологий) - не связывание потока сервера. Если вы не используете асинхронный код сервера, он не будет масштабироваться.
bmm6o
1
@somdow Maksims-Mihejevs хорошо ответили на ваш вопрос в первых двух параграфах своего ответа. Используйте веб-сокеты.
Джефф Шеффилд
7

Для приложений чата или любого другого приложения, которое постоянно общается с сервером, WebSocketsлучшим вариантом является. Тем не менее, вы можете использовать только WebSocketsс сервером, который поддерживает их, так что это может ограничить ваши возможности использовать их, если вы не можете установить необходимые библиотеки. В этом случае вам необходимо использовать Long Pollingдля получения аналогичных функций.

Брант Олсен
источник
5
WebSockets поддерживаются каждым сервером ... Вам просто нужно установить node.js или что-то подобное.
Ноб
9
Немного подправил, чтобы объяснить, что да, любой сервер будет поддерживать WebSockets. Однако, если вы используете хостинг, вы не сможете их использовать.
Брант Олсен
Я понимаю, что эта тема немного устарела, но ... WebSockets не может быть лучшим ответом для всех двунаправленных коммуникаций. Недавно я заметил, что документация по поддержке веб-сокетов Spring 4 предполагает, что WebSockets лучше подходят для перемещения больших объемов данных или низкой задержки. Если они неприменимы или не являются приоритетными, то я полагаю, что они предлагают использовать длинные опросы. Я не знаю полного оправдания этой точки зрения, я просто решил, что ребята из Spring знают, о чем они вообще говорят.
Стони
1
@ Stoney кроме того, что вам нужно было бы настроить websocket на сервере (обработчики и т. Д.) Нет просто никаких причин использовать Long polling over websocket. Websocket намного быстрее (с малой задержкой) и позволяет серверу «общаться» с клиентом без запроса со стороны клиента. В настоящее время я использую сигнализатор (одна из лучших реализаций websocket, когда-либо сделанных на мой взгляд - он работает на клиенте и сервере и позволяет клиенту вызывать методы на сервере и на сервере на клиенте, как будто нет разницы) на каждом сайт, который я
создаю
0

Опрос XHR против SSE против WebSockets

  • Опрос XHR На запрос приходит ответ, когда происходит событие (может быть сразу или после задержки). Последующие запросы должны быть сделаны для получения дальнейших событий.

    Браузер выполняет асинхронный запрос к серверу, который может подождать, пока данные станут доступны, прежде чем ответить. Ответ может содержать закодированные данные (обычно XML или JSON) или Javascript для выполнения клиентом. В конце обработки ответа браузер создает и отправляет еще один XHR, чтобы дождаться следующего события. Таким образом, браузер всегда поддерживает невыполненный запрос к серверу, чтобы получить ответ при каждом событии. Википедия

  • Сервер отправляет события Клиент отправляет запрос на сервер. Сервер отправляет новые данные на веб-страницу в любое время.

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

  • WebSockets После первоначального рукопожатия (по протоколу HTTP). Связь осуществляется в двух направлениях с использованием протокола WebSocket.

    Рукопожатие начинается с HTTP-запроса / ответа, что позволяет серверам обрабатывать HTTP-соединения, а также соединения WebSocket на одном и том же порту. Как только соединение установлено, связь переключается на двунаправленный двоичный протокол, который не соответствует протоколу HTTP. Википедия

JSON C11
источник