问题描述
我想知道 ZeroMQ 和 WebSockets 协议之间有什么区别.我知道 WebSockets 是为 Web 浏览器客户端设计的，但我假设它也可以用于服务器到服务器.而且，在这种情况下，我想知道使用 WebSockets 而不是像 ZeroMQ 这样的其他东西来进行实时消息传递是否会更好.具体来说，我担心临时网络故障时的可靠性和丢失消息.
A: Real-Time-Messaging 是一个不错的标签，但是
您可能很快就会意识到，一旦进入实时领域，就没有理由花费时钟周期将任何消息包装到 XHTML-Matrjoska-in-Another-Matrjoska 中-inside-another-Matrjoska 类似的信封和相关的低效率.
实时难以实时运行，因此要花费/损失处理taskUnit所需的最短时间.
虽然有人试图以类似的 *ML-sexy" 方式重新包装东西，但结果性能只是降低了，超出"了实时领域，而不是任何在那里表现更好的重要帮助.
这方面的一个很好的例子是与准 IT-guru-crowd"相关的废话，为 XHTML 编码的有效负载制作金融市场的标准 FIX 协议扩展"，而高频交易研发中的奶油色工作花费了大量资金/时间/精力来减少与每个 IP 数据包有线卸载和相关联的纳秒.prefixTag:value 的简约设计中包含的等待实时 data 元素的最快解映射/解码规范.
A:协议差异是主要的
虽然 WebSockets 专注于 port:80 HTML/XHTML - 类似一些高级负载内容的包装和框架，ZeroMQ 直接进入相反的方向.它隐藏"&从传输的任何低级细节中卸载"代码(因此透明地通过 INPROC/IPC/TCP/>PGM/EPGM/UDP/VMCI/... 传输类，无论是本地、云范围还是混合)
WebSocket 协议具有固定的客户端和服务器角色以及 HTTP 风格的握手.
WebSocket 焦点结束于 UTF-8/CRLF 内容格式，在一对 0×00 和0xff 字节，并建立在 WebBrowsers 解析此类缓冲消息的能力之上，而浏览器旨在能够做到这一点).
ZeroMQ gives a designer an open architecture to build on building blocks, that were elaborated to cooperate in certain manners -- yes, they have BEHAVIOUR -- that the design is using for some more complex messaging pattern. This allows unlimited upper-layer abstractions, that build on a set of proven building blocks -- ZMQ.PUBLISHER just sends messages to all ZMQ.SUBSCRIBER-s, that listen to and that have demonstrated their respective will to subscribe to some of the news being published. Other ZMQ-primitives help making round-robin based load-balancers, additional steps allow to build fail-safe architectures and similar advanced solutions.
A: Protocol features
While you asked about reliability of a protocol, there are more important attributes at the protocol level -- Assembly/Reassembly/Decomposition overheads, Performance-scaleability, API-to-wire-access latency, thread-safe and relaxation of performance attributes under growing levels of workload.
While WebSocket port:80 communication is "open" to any non-WebSocket intrusion, ZeroMQ low-level protocols were designed for fast, efficient, exclusive ZMQ-2-ZMQ, peer handshaking and all the design efforts are being built from a higher abstraction API level, from which one may add application-based soft-signalling, that may introduce repair/remedy activities so that your requested missing-message issue does not create any adverse effect on the application state.
Hard-working concurrent systems' programmers
would also like a few advanced bonus points on threading and zero-copy & zero-latency internalities from this piece of indepth insight from Martin SUSTRIK, a co-father of both ZeroMQ & it's a bit younger POSIX-compliant sister nanomsg
这篇关于ZeroMQ 和 WebSockets 之间的差异的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！