Является ли Comet устаревшим сейчас с Server-Sent Events и WebSocket?

Ответ 1

Comet - это набор принципов технологии/шаблонов связи, которые обычно реализуются с использованием HTTP-опроса. Он позволяет серверу отправлять данные в браузер по требованию (т.е. Нажимать сервер). Существующие реализации комет требуют сложного Javascript на стороне клиента и поддержки со стороны сервера (для длинных запросов).

События с сервером - это стандартный (HTML5) браузерный API для включения такого типа запросов на сервер по требованию. Вы можете думать о Server-Sent Events как о том, что было сделано с помощью сложного Javascript и выталкивать его в браузер.

WebSockets позволяет браузеру установить постоянное полнодуплексное/двунаправленное подключение к серверу с поддержкой WebSocket. Он не требует, чтобы клиент продолжал периодически отправлять HTTP-запросы на сервер, чтобы поддерживать соединение, как с AJAX/long-poll. Как только соединение установлено, накладные расходы на одно сообщение очень низки (несколько байтов) по сравнению с накладными расходами с обычным HTTP/HTTP-протоколом. Вы можете использовать WebSockets для эффективного нажатия на сервер, но это всего лишь одно приложение.

Существуют также библиотеки, которые построены на транспортном уровне AJAX/comet/WebSockets для обеспечения таких функций, как управление сеансом, каналы, трансляция, pubsub и т.д. CometD является примером этого. Другой популярный пример: Socket.IO. Оба поддерживают WebSockets, если они доступны для базового транспорта, но также поддерживают стандартный AJAX/long-poll, если WebSockets недоступен.

Ответ 2

Я подхожу к этому ответу как с терминологией, так и с исторической точки зрения.

Как я писал в этом другом ответе, мы можем использовать один из нескольких зонтичных терминов для обозначения набора технологий, доступных для асинхронной отправки событий с веб-сервера для веб-клиента (и наоборот). Термин " Push Technology" используется в течение пятнадцати лет (за короткую историю Push Technology вы можете увидеть эту старую белую бумагу Я написал много лет назад - полное раскрытие: я создатель Lightstreamer). Теперь термин " Веб-потоковая передача" набирает силу среди ИТ-аналитиков (см. Gartner, "Cool Vendors in Application and Integration Platforms, 2012" ) Массимо Пеццини и Джесс Томпсон, 11 апреля 2012 года).

Важным аспектом является то, что мы говорим о веб-коммуникациях, то есть использовании веб-протоколов. Существует множество протоколов и технологий обмена сообщениями, которые не являются веб-сайтами (например, большинство MOM), и мы не рассматриваем их как часть технологии Push (или веб-потоковой передачи).

При этом вы можете различать две подкатегории технологии Push (или веб-потоковой передачи):

• HTTP
• Основы WebSockets

Оба HTTP и WebSockets являются веб-протоколами.

Если вы взорвите механизмы push-на основе HTTP, вы можете определить:

• Потоковая передача HTTP
• Длительный опрос HTTP
• Опрос HTTP

Традиционно термин " Comet" (наложенный на 2006 Alex Russell) ссылается как на потоковое HTTP, так и на HTTP-опрос. Но учтите, что первые реализации потоковой передачи HTTP вернутся к 2000, задолго до того, как был придуман термин Comet (примеры - это кнопки и Lightstreamer).

Теперь WebSockets упрощают реализацию веб-потоковой передачи, особенно для "обратного" канала (сообщения, отправленные из браузера на сервер). Более подробное объяснение особенностей обратного канала через HTTP см. В заключительной части этой статьи, которую я написал для CometDaily: http://cometdaily.com/2011/07/06/push-technology-comet-and-websockets-10-years-of-history-from-lightstreamers-perspective/

Как отметил Фил, комета все еще необходима и, вероятно, будет продолжаться еще несколько лет, так как вокруг нее работают не только старые браузеры (в том числе IE9, которые не поддерживают WebSockets...), но и бесконечные части сетевых посредников которые не говорят на WS. Например, мы видели, что некоторые мобильные операторы в некоторых странах (например, Vodafone Italy) поддерживают WSS, но блокируют WS. Таким образом, мир без кометных "хаков" все еще далек... И позвольте мне добавить на личную заметку, что мне никогда не нравился термин "взломать", примененный к кометам (или, с более правильной исторической точки просмотр, применяемый к потоку HTTP и длинному опросу HTTP). Работая над этими методами уже 12 лет, я могу сказать, что нам удалось их доработать настолько, что они стали полномасштабной технологией, полностью надежной и используемой каждый день во многих критических сценариях производства (в области финансов, аэрокосмической, и военных, чтобы назвать несколько отраслей).

Теперь представьте себе мир, где WebSockets повсеместно поддерживаются, а комета больше не нужна. Что вы получаете точно? Ну, просто двунаправленный транспорт, не более того... Наверху вам нужно построить все: протокол обмена сообщениями (возможно, на основе pub/sub), интерфейс на стороне сервера, чтобы поговорить с вашим кодом сервера, и хороший набор методов оптимизации и алгоритмов управления потоком данных, включая управление пропускной способностью, объединение данных, автоматическое дросселирование, доставку дельты и т.д. Хорошо, что и протоколы обмена сообщениями, и механизмы оптимизации уже реализованы хорошими решениями Comet. Таким образом, расширение прежних серверов Comet для поддержки WebSocket - это естественная эволюция, которую реализовали все наши поставщики.

Итак, в ближайшем будущем WebSockets может сделать Comet транспортом устаревшим, но ему нужно будет сосать все более высокие уровни, уже реализованные и хорошо протестированные на традиционных серверах Comet.

Ответ 3

Первоначально я думал, что WebSockets реализует комету. Они не являются альтернативой. Однако после некоторого обсуждения я позже был исправлен и убежден Alex Russell, создателем "Comet", что это не так.

Комета, как говорит @kanaka, представляет собой набор принципов для моделирования двунаправленной связи между клиентом и сервером (серверный push - половина решения и теперь предоставляется событиями Server-Sent и API Source Source).

Однако решения комет - это взломы, потому что они работают непоследовательно в веб-браузерах. По этой причине Алекс Рассел говорит:

Далее, являются ли Web-сокеты формой кометы? Или комета просто HTTP-хаки? Я собираюсь пойти на последнее определение. Фраза и хаки должны, вероятно, отправиться на закат вместе. Я, например, приветствую наших не-HTTP-серверов в реальном времени. В той мере, в какой мы можем забыть о старых браузерах (и бог знает, что я делаю свой бит: http://google.com/chromeframe), мы все можем доска с "веб-сокетами" и необходимость в каком-либо конкретном зонтике уходит.

Итак, давайте сосредоточимся на этом: как мы получаем пользователей в блестящий новый браузер? Какое предложение мы можем предложить им о богатстве и опыте в реальном времени, которое может обеспечить приложение на основе WebSockets? Комета о прошлом. Давайте сделаем будущее реальным.

Я сейчас с Алексом на этом. Однако Comet-HTTP-решения не устаревают, пока:

• Поддержка браузера - 100%, и нам не нужны резервные копии для < IE10. Я не верю, что проблемы Firefox, Safari и Opera будут проблемой. Может быть небольшой процент пользователей, которые игнорируют подсказки автоматического обновления для браузеров, таких как Firefox, но не так много.
• Производители антивирусов (таких как Avast!) начинают поддерживать веб-технологии HTML5 и останавливают их программное обеспечение, препятствуя подключению.
• Некоторая интернет-инфраструктура обновлена ​​для обеспечения поддержки WebSockets. В моих опытах, связанных с WSS через порт 443 (безопасное соединение с WebSocket), обычно означает, что соединения пробиваются через брандмауэры и прокси, но мы хотим, чтобы WS поверх порта 80 всегда поддерживался.

Ответ 4

В то время как WebSocket предоставляет на самом фундаментальном уровне способ двусторонней связи между клиентом и сервером в контексте Web и HTTP, это простая форма связи.

Комета обеспечивает большую функциональность поверх WebSocket (на самом деле, cometd даже поддерживает websocket), для функций:

• как публикация/подписка и каналы связи
• отказаться от старых методов связи с клиентами и сервером, когда websocket недоступен