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

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

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

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

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

3 ответов


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

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

WebRTC позволяет одноранговой связи.

Я рекомендую обучение WebSockets.

для сравнения:

различных коммуникационные технологии в сети

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

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

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

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

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

плюсы:

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

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

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

П. С.

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


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


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