ZeroMQ 和 WebSockets 之间的差异 [英] Differences between ZeroMQ and WebSockets
问题描述
我想知道 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，
您可以在这里先看看
I'd like to know what the differences are between the ZeroMQ and WebSockets protocols. I know WebSockets was designed for web browser clients, but I'm assuming it can also be used server to server. And, in that case, I'm wondering if it would be good to use WebSockets instead of something else like ZeroMQ for real-time messaging. Specifically, I'm worried about reliability and missing messages in case of temporary network failure.
A: Real-Time-Messaging is a nice tag, however
You may soon realise, that once going into the territory of Real-Time, there is no justification for spending clock-cycles on wrapping any message into the XHTML-Matrjoska-in-Another-Matrjoska-inside-another-Matrjoska alike envelopes-inside-envelopes and associated inefficiencies.
Real-Time struggles to operate in real time, so to spend/lose a minimum achievable time necessary to process a taskUnit.
While there are attempts to re-wrap things in similar *ML-"sexy" manner, the resulting performance is just degraded, going "outside" of the Real-Time territory, instead of any significant help in performing better there.
A very good example of this is a nonsense related to an "quasi-IT-guru-crowd" efforts making financial markets' standard FIX-Protocol "extension" for XHTML-encoded payloads, while the créme-a-la-créme efforts in High-Frequency-Trading R&D spend immense funds/time/efforts on how to shave down nanoseconds associated with each IP-packet wire-unloading & fastest possible de-mapping/de-coding of the awaited real-time data-elements contained there in a minimalistic design of prefixTag:value original specification.
A: Protocol differences are principal
While WebSockets focus on port:80 HTML/XHTML-alike wrapping and framing of some high-level payload-content, ZeroMQ goes right into an opposite direction. It "hides" & "off-loads" the code from any low-level details on transports ( being thus transparently served over INPROC / IPC / TCP / PGM / EPGM / UDP / VMCI / ... transport classes, be it locally, cloud-wide or a mix of both )
The WebSocket protocol has the fixed client and server role and HTTP-style handshaking.
WebSocket focus finishes at UTF-8/CRLF content formatting, framing between a pair of 0×00 & 0xff bytes and builds on WebBrowsers' ability to parse such buffered messages, which the browser were designed to be able to do ).
In case one has never worked with ZeroMQ,
one may here enjoy to first look at "ZeroMQ Principles in less than Five Seconds"
before diving into further details
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 之间的差异的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
