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