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

Question

БОШ это...

транспортный протокол, который эмулирует семантику долгоживущего двунаправленного TCP-соединения между двумя объектами (например, клиентом и сервером), эффективно используя несколько синхронных пар HTTP-запросов / ответов, не требуя использования частых опросов или фрагментированных ответов.

Это похоже на длинный опрос WebSockets и HTTP, за исключением того, что он использует два открытых HTTP-соединения вместо одного и не расширяет HTTP-протокол.

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

Answer 1

Сначала позвольте мне обратиться к готовности WebSockets:

Реализация протокола Hixie-76 в WebSockets поставляется и включена по умолчанию в Chrome, Safari и iOS (iPhone и iPad). Протокол Hixie-76 также поставляется, но по умолчанию отключен в Firefox 4 и Opera 11. Проект web-socket-js - это Flash shim/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 с поддержкой HyBi-07.

Обновление: по состоянию на февраль 2013 года новейшая спецификация HyBi/IETF RFC 6455 поддерживается в Chrome 14, Firefox 7, IE10, Opera 12.1, Safari 6.0 и web-socket-js Flash shim/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
• пристань
• pywebsockets
• websockify
• Socket.IO
• phpwebsocket
• Протокол::WebSocket (Perl)
• em-websocket (ruby)
• Узел-WebSocket-сервер

BOSH против WebSockets:

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

Обновление:

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