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.