Какие конкретные варианты использования требуют BOSH через WebSockets и длительный опрос?

Ответ 1

Сначала позвольте мне задать готовность к использованию WebSockets:

Внедрение WebSockets протокола Hixie-76 поставляется по умолчанию в Chrome, Safari и iOS (iPhone и iPad). Протокол Hixie-76 также отправляется, но по умолчанию отключен в Firefox 4 и Opera 11. Проект web-socket-js - это флеш-шайба/polyfill, который добавляет поддержку WebSocket (Hixie-76) в любой браузер с Flash.

Другими словами, WebSockets доступен практически для каждого браузера в дикой природе.

Причина, по которой Opera и Mozilla по умолчанию отключили протокол, объясняются теоретической проблемой, что могут быть некоторые пропущенные HTTP-прокси/посредники, которые могут быть атакованы/отравлены с использованием версий протокола Hixie. То же самое относится и к Flash, но Mozilla и Opera чувствуют большую ответственность за код, который они отправляют. Версия протокола HyBi (протокол был перенесен в рабочую группу IETF HyBi), чтобы решить проблему безопасности.

Mozilla, Opera, Google и Microsoft работают над реализацией протоколов HyBi (хотя Microsoft сейчас поддерживает их как отдельную загрузку), Существует ветвь web-socket-js Flash-прокладка/polyfill. На мобильных устройствах IETF6455 поддерживается Safari на iOS 6.0, Opera Mobile 12.1, Chrome 14 для Android, Firefox 7 для Android и Blackberry 7. У оригинального браузера по умолчанию Android нет поддержки WebSocket.

Серверы WebSocket просты в реализации. Существует множество автономных и плагиновых реализаций, большинство из которых поддерживают как версии протокола Hixie-76, так и версии HyBi:

• libwebsockets
• Jetty
• pywebsockets
• websockify
• Socket.IO
• phpwebsocket
• Протокол:: WebSocket (perl)
• em-websocket (ruby)
• node-websocket-server

BOSH vs WebSockets:

• латентность. Хотя проект BOSH претендует на очень низкую задержку, BOSH будет сложно конкурировать с WebSockets. Если у вас нет идеальных условий, при которых HTTP/1.1 поддерживается всеми посредниками и целевым сервером, менеджеру BOSH и диспетчеру подключения потребуется восстановить соединения после каждого пакета и каждого таймаута запроса. Это значительно увеличит дрожание задержки и задержки. Низкий джиттер часто более важен для приложений реального времени, чем средняя латентность. Соединения WebSocket будут очень похожими на латентность и дрожание до необработанных TCP-соединений. И даже в идеальных условиях латентность связи между серверами BOSH (и, следовательно, в оба конца) всегда будет выше, чем WebSockets: BOSH все еще должен соблюдать семантику HTTP-запроса-ответа. Потоковая передача HTTP включает несколько ответов на запрос (путем разделения "одного" ответа на несколько частей), но не наоборот (каждое сообщение клиента является новым запросом).
• накладные расходы на небольших пакетах. В WebSockets есть два байта накладных расходов на фреймворк для небольших Сообщения. В BOSH каждое сообщение имеет HTTP-запрос и заголовки ответов (легко 180+ байтов для каждого раунда). Кроме того, каждое сообщение обернуто в XML (предположительно необязательно, но спецификация не определяет, как) с несколькими атрибутами, связанными с сеансом.
• сложность: в то время как BOSH использует существующие механизмы в браузере, для реализации семантики BOSH требуется довольно сложная библиотека JavaScript. Управление этим в Javascript также увеличит задержку и дрожание по сравнению с реализацией native/browser (или даже Flash).
• тяговый: BOSH начал жизнь как способ сделать XMPP более эффективным. Он вырос из сообщества XMPP, и из того, что я могу сказать, получилось очень мало внимания вне этого сообщества. Проекты документов для BOSH и XMPP разделены, но, похоже, очень мало реального использования BOSH в реальном мире без XMPP.

Обновление

Просто нашел видео, где Ян Фет обсуждает преимущества преимуществ WebSockets над API канала, который похож на BOSH (в 44:00)