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 ).
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.
Concurrent systems’ programmers
would also like a few advanced bonus points on threading and zero-copy & zero-latency internalities from this piece of in-depth insight from Martin SUSTRIK, a co-father of both ZeroMQ & its younger POSIX-compliant sister nanomsg