Ответ 1

WebSockets - это определенно будущее.

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

WebRTC позволяет осуществлять одноранговую связь.

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

Сравнение:

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

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

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

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

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

• События с сервером - client & larr; server. Клиент устанавливает постоянное и долгосрочное подключение к серверу. Только сервер может отправлять данные клиенту. Если клиент хочет отправить данные на сервер, для этого потребуется использование другой технологии/протокола. Этот протокол совместим с HTTP и прост в применении на большинстве серверных платформ. Это предпочтительный протокол, который будет использоваться вместо Long Polling. график поддержки (хорошо, кроме IE) | wikipedia

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

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

Вопросы безопасности

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

P.S.

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

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

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

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

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