Различия между ZeroMQ и WebSockets
Я хотел бы знать, в чем различия между ZeroMQ а также WebSockets протоколы
я знаю WebSockets был разработан для клиентов веб-браузера, но я предполагаю, что он также может быть использован сервер-сервер.
И, в этом случае, мне интересно, было бы хорошо использовать WebSockets вместо чего-то другого, как ZeroMQ для обмена сообщениями в реальном времени.
В частности, меня беспокоит надежность и отсутствие сообщений в случае временного сбоя сети.
3 ответа
A: Real-Time-Messaging - хороший тег, однако
Возможно, вы скоро поймете, что, попав на территорию реального времени, нет смысла тратить циклы часов на завершение любого сообщения в конверты XHTML-Matrjoska-in-Another-Matrjoska-inside-another-Matrjoska. -конверты и связанная с ними неэффективность.
Реальное время борется за работу в реальном времени, поэтому тратить / терять минимально достижимое время, необходимое для обработки taskUnit,
Хотя есть попытки перефразировать вещи похожим *ML-" сексуальным " образом, результирующая производительность просто ухудшается, выходя "за пределы" территории в реальном времени, вместо какой-либо существенной помощи в улучшении результатов там.
Очень хорошим примером этого является бессмыслица, связанная с " квази-IT-гуру-толпой " усилиями по созданию стандартного "расширения" FIX-протокола финансовых рынков для полезных нагрузок с кодировкой XHTML, в то время как усилия по созданию крем-а-ла-крем в Исследования и разработки в области высокочастотной торговли тратят огромные средства / время / усилия на то, как сократить наносекунды, связанные с разгрузкой проводов каждого IP-пакета, и максимально быстро де-картографирование / декодирование ожидаемого в реальном времени data -элементы, содержащиеся там в минималистском дизайне prefixTag:value оригинальная спецификация
A: различия протокола являются принципиальными
В то время как WebSockets сосредоточиться на порте:80 HTML/XHTML-подобная упаковка и кадрирование некоторого высокоуровневого полезного контента, ZeroMQ идет прямо в противоположном направлении. Он "скрывает" и "разгружает" код от любых низкоуровневых деталей транспорта (таким образом, прозрачно обслуживается INPROC / IPC / TCP / PGM / EPGM транспортные классы, будь то локально, в облаке или сочетание обоих)
WebSocket Протокол имеет фиксированную роль клиента и сервера и подтверждение связи в стиле HTTP.
WebSocket Фокус заканчивается на форматировании контента UTF-8/CRLF, кадрирование между парой 0×00 & 0xff байт и основывается на способности WebBrowsers анализировать такие буферизованные сообщения, которые браузер должен был делать).
ZeroMQ дает дизайнеру открытую архитектуру для построения на строительных блоках, которые были разработаны для сотрудничества определенным образом - да, у них есть ПОВЕДЕНИЕ - которое дизайн использует для более сложного шаблона обмена сообщениями. Это позволяет неограниченное количество абстракций верхнего уровня, которые основаны на наборе проверенных строительных блоков - ZMQ.PUBLISHER просто отправляет сообщения всем ZMQ.SUBSCRIBER которые слушают и продемонстрировали свое желание подписаться на некоторые из публикуемых новостей. Другие примитивы ZMQ помогают создавать балансировщики нагрузки на основе циклического перебора, дополнительные этапы позволяют создавать отказоустойчивые архитектуры и аналогичные передовые решения.
A: Особенности протокола
В то время как вы спрашивали о надежности протокола, на уровне протокола есть более важные атрибуты - накладные расходы на сборку / сборку / декомпозицию, масштабируемость производительности, задержку доступа API-к-проводу, безопасность потоков и ослабление атрибутов производительности при росте уровни нагрузки.
В то время как WebSocket порт: 80 связь "открыта" для любого WebSocket вторжение, ZeroMQ протоколы низкого уровня были разработаны для быстрого, эффективного, эксклюзивного ZMQ-2-ZMQ, однорангового рукопожатия, и все усилия по разработке основаны на более высоком уровне API абстракции, с которого можно добавить прикладную мягкую сигнализацию, которая может вводить действия по исправлению / устранению, чтобы запрошенная проблема с отсутствующим сообщением не оказала негативного влияния на состояние приложения.
Трудолюбивые программисты параллельных систем
Также хотелось бы получить несколько дополнительных бонусных баллов за многопоточность и внутреннюю работу с нулевым копированием и нулевой задержкой из этого углубленного представления Мартина СУСТРИКА, одного из отцов обоих. ZeroMQ и это немного младшая POSIX-совместимая сестра nanomsg
Ваш вопрос звучит как "в чем разница между Apache и HTTP"
WebSockets - это просто протокол (похожий на http), а ZeroMQ - это протокол и сервер, который отвечает за жизненный цикл вашего сообщения с момента его получения до его использования.
Есть некоторые интересные различия.
ZeroMQ — это строго модель актера. Передача сообщений асинхронна. Если между конечными точками существует соединение, ZeroMQ гарантирует, что сообщения будут доставлены целиком или не доставлены вообще (т. е. не будут доставлены частичные сообщения). В рамках модели актера возможные места размещения сообщений: 1) в отправляющем приложении, 2) где-то в транспортном средстве или 3) в принимающем приложении.
Похоже, что WebSockets по сути являются операцией http с некоторой кодировкой сверху. Вероятно, это больше похоже на взаимодействие последовательных процессов. CSP является развитием модели актеров, но акт отправки синхронен с актом получения сообщения. Это «свидание казни». Предположительно, при использовании http «отправитель» точно знает, что сообщение было передано в принимающее приложение, поскольку сеанс http завершен, и, предположительно, для этого требуется, чтобы принимающее приложение находилось там, готовое и ожидающее, настроив Прежде всего, http-сервер (предостережение: я никогда не использовал веб-сокеты, и возможно, между http-сервером и реальным серверным приложением действительно существует какая-то скрытая очередь).
Разница с CSP заключается в том, что сообщения могут находиться только в двух местах: 1) в отправляющем приложении или 2) в принимающем приложении. С ZeroMQ нет неопределенного местоположения «в пути».
Как всегда, невозможно сказать, что лучше, потому что это зависит от потребностей человека.
CSP лучше подходит для строгих приложений жесткого реального времени, поскольку вы не скрываете задержку обработки сообщений, помещая сообщения в очередь/TCP-буфер ОС/память NIC/коммутаторы Ethernet. Однако CSP менее эффективно использует IP-сети, поскольку через базовую сеть передается больше данных протокола для подтверждения и закрытия сеанса передачи HTTP. Обратите внимание, что «реальное время» не обязательно означает «быстро», но подразумевает «гарантировано». Корректность систем CSP может быть доказана математически (Тони Хоар придумал для нее расчеты процессов, и действительно, мотивация CSP заключалась в том, чтобы ее можно было легко математически проанализировать), и если системные проблемы записаны в систему, они гарантированно будут возникать каждый раз (т. е. это легко найти проблемы при тестировании).
Модель актера может лучше использовать любые существующие коммуникационные ресурсы, но ее правильность не может быть доказана, и она может скрывать неприятные проблемы (например, тупики) до тех пор, пока в один напряженный день сеть не начнет работать немного медленнее.ZeroMQ не позволяет вам извлекать сообщения из очереди, и в зависимости от того, что происходит с сетью, отправленные сообщения для некоторых шаблонов отбрасываются (по замыслу). Это может быть или не быть проблемой. Вы не можете доказать правильность систем модели актеров (за исключением тривиальных случаев), и тестирование не обязательно выявит системные проблемы, такие как активная блокировка или взаимоблокировка.
Несмотря на это, можно реализовать режим CSP в системе модели актера (вставляется протокол подтверждения/nack сообщения поверх ZeroMQ), а также можно реализовать режим модели актера в CSP (у вас есть очередь сообщений внутри приложения исходящие сообщения).