WebSockets, безусловно, будущее.
Длинный опрос - это грязный обходной путь, который предотвращает создание соединений для каждого запроса, как это делает AJAX, но длинный опрос был создан, когда WebSockets не существовало. Теперь из-за WebSockets долгий опрос проходит.
WebRTC обеспечивает одноранговую связь.
Я рекомендую изучать WebSockets .
Сравнение:
различных методов общения в Интернете
AJAX - request→ response. Создает соединение с сервером, отправляет заголовки запроса с дополнительными данными, получает ответ от сервера и закрывает соединение.
Поддерживается во всех основных браузерах.
Длинный опрос - request→ wait→ response. Создает подключение к серверу, как это делает AJAX, но поддерживает соединение keep-alive открытым в течение некоторого времени (хотя и ненадолго). Во время подключения открытый клиент может получать данные с сервера. Клиент должен периодически переподключаться после закрытия соединения из-за тайм-аутов или данных eof. На стороне сервера он по-прежнему обрабатывается как HTTP-запрос, так же, как AJAX, за исключением того, что ответ по запросу будет происходить сейчас или в будущем, что определяется логикой приложения.
график поддержки (полный) | википедия
WebSockets - client↔ server. Создайте TCP-соединение с сервером и оставляйте его открытым столько, сколько нужно. Сервер или клиент могут легко закрыть соединение. Клиент проходит через HTTP-совместимый процесс рукопожатия. Если это удастся, то сервер и клиент могут обмениваться данными в обоих направлениях в любое время. Это эффективно, если приложение требует частого обмена данными обоими способами. В WebSockets есть кадрирование данных, которое включает маскирование для каждого сообщения, отправляемого с клиента на сервер, поэтому данные просто шифруются.
график поддержки (очень хорошо) | википедия
WebRTC - peer↔ поддержка диаграммы (средняя) | википедияpeer . Транспорт для установления связи между клиентами и является независимым от транспорта, поэтому он может использовать UDP, TCP или даже более абстрактные уровни. Это обычно используется для передачи данных большого объема, такой как потоковое видео / аудио, где надежность является вторичной, и несколько кадров или снижение качества могут быть принесены в жертву в пользу времени отклика и, по меньшей мере, некоторой передачи данных. Обе стороны (одноранговые узлы) могут передавать данные друг другу независимо. Хотя он может использоваться полностью независимо от любых централизованных серверов, он все же требует некоторого способа обмена данными конечных точек, где в большинстве случаев разработчики все еще используют централизованные серверы для «связи» одноранговых узлов. Это требуется только для обмена важными данными для установления соединения, после чего централизованный сервер не требуется.
Отправленные сервером события - client← server. Клиент устанавливает постоянное и долгосрочное соединение с сервером. Только сервер может отправлять данные клиенту. Если клиент хочет отправить данные на сервер, для этого потребуется использовать другую технологию / протокол. Этот протокол совместим с HTTP и прост в реализации на большинстве серверных платформ. Это предпочтительный протокол, который следует использовать вместо длительного опроса. график поддержки (хорошо, кроме IE) | википедия
Преимущества:
Основное преимущество серверной части WebSockets заключается в том, что это не HTTP-запрос (после рукопожатия), а надлежащий протокол связи на основе сообщений. Это позволяет достичь огромных преимуществ в производительности и архитектуре . Например, в файле node.js вы можете использовать одну и ту же память для разных соединений с сокетами, чтобы каждый из них мог обращаться к общим переменным. Следовательно, вам не нужно использовать базу данных в качестве точки обмена в середине (например, с AJAX или Long Polling с таким языком, как PHP). Вы можете хранить данные в оперативной памяти или даже сразу же переиздавать их между сокетами.
Соображения безопасности
Люди часто беспокоятся о безопасности WebSockets. Реальность такова, что это не имеет большого значения или даже делает WebSockets лучшим вариантом. Прежде всего, с AJAX, существует более высокая вероятность MITM , так как каждый запрос является новым TCP-соединением, которое проходит через интернет-инфраструктуру. С WebSockets, когда он подключен, гораздо сложнее перехватывать между ними, с дополнительной принудительной маскировкой кадров, когда данные передаются от клиента к серверу, а также с дополнительным сжатием, которое требует больше усилий для проверки данных. Все современные протоколы поддерживают оба: HTTP и HTTPS (зашифрованные).
PS
Помните, что WebSockets, как правило, использует совершенно другой подход к работе с сетью , более похожий на игры реального времени, которые были все это время, а не на http.
