I've read that HTTP is not suitable as a messaging protocol in several places such as here in reference to RabbitMQ.
I assume that there's a technical reason for this and that it's not a mere opinion. I've looked through the AMQP spec for example and can't see any reason why HTTP + Web Sockets can't work. In fact, something seems to be in the works for AMQP over Web Sockets. Furthermore, I've looked at the STOMP protocol which does use HTTP + Web Sockets and can't see any significant limitations (other than a small performance hit).
What technical characteristic does HTTP + Web Sockets lack that makes it unsuitable as a messaging protocol?
UPDATE:
This is what I was looking for: Crossbar.IO - a WAMP message broker. I needed a message broker that I can easily connect to from a browser and have not been satisfied with RabbitMQ (over STOMP) or HiveMQ (MQTT).
HTTP is request/response based, what makes it difficult to work in a publisher/subscriber fashion. Basically, you can either poll the source of messages for new ones, or create another local endpoint where the other end push messages to you.
WebSocket is different. Despite of starting as a HTTP request, it switches straightaway to a persistent, full-duplex connection, where both end can push data. Basically, in this case HTTP is only used as protocol to negotiate the connection, once negotiated WebSocket uses its own protocol to transfer data.
UPDATE: We are clear that HTTP is not a messaging protocol, since it is request/response. WebSockets, although it allows pushing data from both ends, it is not a messaging protocol neither. It defines a way of framing data, but there are not defined semantic or grammar to subscribe to topics or any operation about messaging. For example WAMP is an actual messaging protocol for websockets.
Related
Using CNCF's Strimzi Kafka Bridge I have created a small API that can interact with Kafka server using a HTTP/1.1 protocol. This is all good for a request-response scenario. However, my requirement is to stream events received on the Kafka topic to the subscribed client(s) (through the Strimzi bridge) as soon as I receive them preferably on a long lived HTTP connection (as per my understanding). It's a waste of client resources to continuously poll the bridge for messages and come back empty handed. I would like the Kafka server stream these events to the client directly.
I am a little unsure about SSE or Websockets or long polling. I did quite a bit of reading on these methodologies to stream data to the client. However, I am unable to figure out if these changes are at the communication or the application layer or both.
Do you just build an API (irrespective of the technology) using a traditional HTTP communication protocol and somehow upgrade it to use Websockets OR use of Websockets should be embedded in your application libraries ground up?
I can provide more information if needed. The Strimzi Kafka bridge website does not mention anything about "server side streaming" OR maybe I am misunderstanding the real purpose of the tool.
The Strimzi Kafka HTTP bridge is meant as a "translator" for HTTP to Kafka native protocol and vice versa. It means that the HTTP client has to have the same behavior as a native Kafka client so, in the case of a consumer, doing a poll for getting messages which is how Kafka works natively. Imho HTTP 1.1 is not for streaming at all.
Websockets is a completely different protocol to which you can upgrade of course starting from an HTTP connection but it's not supported by the Strimzi bridge.
Actually, the AMQP 1.0 protocol which is in the bridge (as a POC) can support this kind of scenario so establishing a connection and having the bridge pushing on that connection instead of polling from the client side.
#Nick thinking more, actually you can do "long polling". The GET on the /records endpoint for getting messages has a timeout parameter on the query string. Its value is used as timeout for the internal native Kafka poll in the bridge. It somehow provides you the long polling behaviour because the poll doesn't return until there are available records or the timeout expires. If you set a high timeout, you can have the behavior you want avoiding polling more times with opening/closing more HTTP connections for that.
More details on the timeout parameter here:
https://strimzi.io/docs/bridge/latest/#_poll
What are the major differences between WebSocket and STOMP protocols?
This question is similar to asking the difference between TCP and HTTP. I shall still try to address your question, its natural to get confused between these two terms if you are beginning.
Short Answer
STOMP is derived on top of WebSockets. STOMP just mentions a few specific ways on how the message frames are exchanged between the client and the server using WebSockets.
Long Answer
WebSockets
It is a specification to allow asynchronous bidirectional communication between a client and a server. While similar to TCP sockets, it is a protocol that operates as an upgraded HTTP connection, exchanging variable-length frames between the two parties, instead of a stream.
STOMP
It defines a protocol for clients and servers to communicate with messaging semantics. It does not define any implementation details, but rather addresses an easy-to-implement wire protocol for messaging integrations. It provides higher semantics on top of the WebSockets protocol and defines a handful of frame types that are mapped onto WebSockets frames. Some of these types are...
connect
subscribe
unsubscribe
send (messages sent to the server)
message (for messages send from the server) BEGIN, COMMIT, ROLLBACK
(transaction management)
WebSocket does imply a messaging architecture but does not mandate the use of any specific messaging protocol. It is a very thin layer over TCP that transforms a stream of bytes into a stream of messages (either text or binary) and not much more. It is up to applications to interpret the meaning of a message.
Unlike HTTP, which is an application-level protocol, in the WebSocket protocol there is simply not enough information in an incoming message for a framework or container to know how to route it or process it. Therefore WebSocket is arguably too low level for anything but a very trivial application. It can be done, but it will likely lead to creating a framework on top. This is comparable to how most web applications today are written using a web framework rather than the Servlet API alone.
For this reason the WebSocket RFC defines the use of sub-protocols. During the handshake, the client and server can use the header Sec-WebSocket-Protocol to agree on a sub-protocol, i.e. a higher, application-level protocol to use. The use of a sub-protocol is not required, but even if not used, applications will still need to choose a message format that both the client and server can understand. That format can be custom, framework-specific, or a standard messaging protocol.
STOMP — a simple, messaging protocol originally created for use in scripting languages with frames inspired by HTTP. STOMP is widely supported and well suited for use over WebSocket and over the web.
The WebSocket API enables web applications to handle bidirectional communications whereas STOMP is a simple text-orientated messaging protocol. A Bidirectional WebSocket allows a web server to initiate a new message to a client, rather than wait for the client to request updates. The message could be in any protocol that the client and server agree to.
The STOMP protocol is commonly used inside a web socket.
A good tutorial is STOMP Over WebSocket by Jeff Mesnill (2012)
STOMP can also be used without a websocket, e.g. over a Telnet connection or a message broking service.
And Raw WebSockets can be used without STOMP - Eg. Spring Boot + WebSocket example without STOMP and SockJs.
Note: Others have well explained what are both WebSocket and STOMP, so I'll try to add the missing bits.
The WebSocket protocol defines two types of messages (text and binary), but their content is undefined.
STOMP protocol defines a mechanism for client and server to negotiate a sub-protocol (that is, a higher-level messaging protocol) to use on top of WebSocket to define following things:
what kind of messages each can send,
what the format is,
the content of each message, and so on.
The use of a sub-protocol is optional but, either way, the client and the server need to agree on some protocol that defines message content.
Reference
TLDR; STOMP is a framework built on top of websockets, i.e. stomp utilizes websockets in the background. If you are thinking of building a notification/messaging system then use stomp.
https://stomp.github.io/stomp-specification-1.2.html
I'd like to compare somehow capabilities of grpc vs. zeromq & its patterns: and I'd like to create some comparsion (feature set) - somehow - 0mq is "better" sockets - but anyways - if I apply 0mq patterns - I get comparable 'frameworks' I think - and here 0mq seems to be much more flexible ...
The main requirements are:
async req / res communication (inproc or remote) between nodes
flexible messages routing
loadbalancing support
well documented
any ideas?
thanks!
async req / res communication (inproc or remote) between nodes
Both libraries allow for synchronous or asynchronous communication depending on how to implement the communication. See this page for gRPC: http://www.grpc.io/docs/guides/concepts.html. Basically gRPC allow for typical HTTP synchronous request/response or a 'websocket-like' bidirectional streaming. For 0mq you can setup a simple REQ-REP connection which is basically a synchronous communication path, or you can create async ROUTER-DEALER type topologies.
flexible messages routing
'Routing' essentially means that a message gets from A to B via some broker. This is trivially done in 0mq and there are a number of topologies that support stuff like this (http://zguide.zeromq.org/page:all#Basic-Reliable-Queuing-Simple-Pirate-Pattern). In gRPC the same sort of topology could be created with a 'pub-sub' like connection over a stream. gRPC supports putting metadata in the message (https://github.com/grpc/grpc-go/blob/master/Documentation/grpc-metadata.md) which will allow you to 'route' a message into a queue that a 'pub-sub' connection could pull from.
loadbalancing support
gRPC has a health check support (https://github.com/grpc/grpc/blob/master/doc/health-checking.md) but because it's HTTP/2 you'd have to have a HTTP/2 load balancer to support the health check. This isn't a huge big deal, however, because you can tie the health check to a HTTP/1.1 service which the load balancer calls. 0mq is a tcp connection which means that a load balancer would likely check a 'socket connect' in tcpmode to verify the connection. This works but it's not as nice. Again you could get slick and front-end the 0mq service with a HTTP/1.1 webserver that the load balancer reads from.
well documented
both are well documented. 0mq's documentation must be read to throughly understand the technology and is more of a higher lift.
Here's the big differences:
0mq is a tcp protocol whereas gRPC is HTTP with a binary payload.
0mq requries you design a framing protocol (frame 1 = verison, frame 2 = payload, etc.), whereas much of this work is done for you in gRPC
gRPC is transparently coverted to REST (https://github.com/grpc-ecosystem/grpc-gateway) whereas 0mq requires a middleware application if you want to talk REST to it.
gRPC uses standard tls x509 certificates (think websites) whereas 0mq uses a custom encryption/authentication protocol (http://curvezmq.org/). Prior to 4.x there was no encryption support in 0mq and if you really wanted it you had to dive into this crap: https://wiki.openssl.org/index.php/BIO. (trust me don't do it)
0mq can create some pretty sick topologies (https://github.com/zeromq/majordomo) (https://rfc.zeromq.org/spec:7/MDP/) whereas gRPC is basically client/server
0mq requires much more time to build and get running whereas gRPC is basically compiling a protobuf messages and importing the service into your code.
Not quite the same. gRPC is primarily for heterogeneous service interoperability, ZeroMQ (ZMQ/0MQ/ØMQ) is a lower level messaging framework. ØMQ doesn't specify payload serialization beyond passing binary blobs whereas gRPC chooses Protocol Buffers by default. ØMQ is pretty much stuck on the same machine or machines between datacenters/clouds, whereas gRPC could potentially work on a real client too (ie mobile or web, it already supports iOS). gRPC using ØMQ could be significantly faster and more efficient for in-cloud/-datacenter services than the overhead, latency and complexity of http2 request/response chain. I'm not sure how (or even if) gRPC TLS security is adequate for public cloud and mobile/web usage, but one could always inject end-to-end security requirements (ie libsodium) at the router/controller level of the app/app framework and run in plaintext mode (which would also remove OpenSSL fork BoringSSL from causing maintenance headaches because of upstream flaws).
For very high latency / low bandwidth services (ie mission to mars), one would think about RPC using a transport like SMTP (ie Active Directory alternate replication) or MQTT (ie Facebook Messenger, ZigBee, SCADA)
Bonus (off-topic): It would be nice if gRPC had alternate pluggable transports like ØMQ (which also itself supports UNIX sockets, TCP, PGM and inproc), because HTTP/2 isn't stable in all languages yet and it's slower than ØMQ. And, it's worth looking at nanomsg (especially in the HFT world) because it could be extended with RDMA/SDP/MPI and made crazy low-latency/zero-copy/Infiniband-ready.
When publish/subscribe to messages directly from a web server to a web browser or vice versa we can use MQTT over WebSockets. At the same time, SSE(half duplex) can be used to push data from web server to web browser. What are the other major differences? Especially related security and consistency of the application.
WebSocket is a low-level (framing) transport standardized by the IETF and a JavaScript API standardized by the W3C. It is not publish/subscribe. You can have publish/subscribe protocols that sit "on top" of WebSocket. For example, AMQP is a pub/sub protocol that can be implemented with WebSocket. Another example is Java Message Service (JMS); while JMS is an API and not a bit protocol, it can be implemented over a pub/sub protocol that, in turn, is implemented with WS. I mention both AMQP and JMS because both the AMQP protocol and the JMS API provide for "acknowledgements", which will give you a high degree of reliability unlike other mechanisms.
MQTT is a publish/subscribe protocol that can be implemented over a low-level transport. MQTT can run over TCP/IP or WebSocket for example. MQTT has QoS levels which also give you acknowledgements (ie, for reliability). MQTT is not normally native to a browser, so MQTT messages have to be made web-friendly before connecting to a browser... usually WebSocket, since WS is a 'fat pipe' and similar to TCP in a way.
Server-Sent Events (SSE) is a HTML5 formalization of "Comet" (or "reverse AJAX) techniques. "Comet" was a loose collection of informal techniques; different implementations did not work together. SSE is not publish/subscribe. It is an HTTP mechanism to broadcast data from a server to the browser client(s). Essentially its a fire-and-forget technique.
Most modern browsers understand SSE and WS (IE/EDGE does not currently support SSE); they usually all understand Secure WebSocket (WSS) too. Practically all webservers and appservers understand SSE and WS/WSS. If you use WSS, your data will be encrypted in transit. The particular encryption cipher is setup on the connection; you'll have to investigate what ciphers your browser clients and web/app-servers understand.
MQTT offers 3 different QOS levels that control delivery of messages
QOS 0 - Best effort
QOS 1 - At least once
QOS 2 - Once only
MQTT supports User authentication and topic level ACL so you can ensure users only see what they need to see even when using wildcard subscriptions
MQTT also allows for direct connection to the backend systems without the need for bridging in the WebApp
First off - I understand SPDY and Websockets aren't the same thing, and that you can run Websockets over SPDY like you can with HTTP, etc.
However - I am wondering if SPDY would be a viable replacement for websockets if I am trying to provide a REST (like) API that also supports server push (bi-directional calls over the same connection).
My current prototype uses websockets (node+socket.io), and works fine. However, my issue with websockets is I am having to dream up my own JSON protocol for routing requests both to and from the server. I'd much rather use REST-style URIs and Headers in requests, which fits better in a REST-based architecture. SPDY seems like it would support this better.
Also, because of the lack of headers, I'm concerned websockets won't fit well in our deployment network, and thinking SPDY would be a better fit again.
However, I've not seen many examples of bidirectional SPDY requests, apart from pushing files to the browser. I would like to push events and data to the browsers, such as:
Content-Type: application/json
{
"id": "ca823f3e233233",
"name": "Greg Brady"
}
but it's not clear to me how the browser/Javascript might "listen" and react to these, as I would with the WebSocket and socket.io APIs.
Let's start from the beginning: why would you want to run WebSockets over SPDY, as opposed to doing an HTTP upgrade? If you upgrade an HTTP connection to WS, then nothing else can use that TCP stream - the WS connection can be idle, but the connection is blocked nonetheless. With SPDY, you can mux multiple requests/responses, and a websocket connection (or even multiple) over the same underlying TCP stream. On a practical note, as of July 2012, WS over SPDY is still a work in progress, so you will have to wait to use SPDY for WebSockets - hopefully not too long though!
But let's assume the support is there... The reason why it's not clear how to listen for "SPDY Push" from JavaScript is because there is no way to do that! A pushed resource goes into your browsers cache - nothing more, nothing less. If you need to stream data to your javascript callbacks, then WebSockets, or Server-Sent Events (SSE) is the answer.
So, putting it all together:
HTTP adds a lot of overhead for individual small requests (headers, etc)
WebSockets gives you a low overhead channel, but requires you implement own routing
SPDY will significantly reduce the overhead and cost of small HTTP requests (win)
SSE is a good, simple alternative to pushing data to the client (which works today, over SPDY)
You could use SPDY+SSE to meet your goals, and all of that communication can run over the same TCP channel. SPDY requests to the server, SSE push from the server.
First some clarifications:
The base WebSocket protocol (IETF 6455) is not layered onto HTTP. The initial handshake for WebSocket connections is HTTP compatible, but once the handshake is completed, the protocol is a framed, bi-directional full-duplex connection with very low overhead (often just 2 bytes per frame of header).
The WebSocket over SPDY idea is a proposal that may or may not see the light of day. In this case, WebSocket is in fact being layered on SPDY. The initial connection/handshake may happen faster due to the nature of SPDY versus HTTP, however, the data frames will have more overhead because the WebSocket header fields are mapped into SPDY header fields.
SPDY aims to be a more efficient replacement for HTTP. WebSocket is an entirely different beast that enables very low-latency bi-directional/full-duplex messaging between the client and server.
If what you are interested in server-push with a simple API and you don't need super low-latency, then you might consider server-sent events which has an API that is simple and similar to the WebSocket API. Or you could look into one of the many good Comet libraries which enable server-push but will better support old browsers unlike any of the above solutions.
However, my issue with websockets is I am having to dream up my own
JSON protocol for routing requests both to and from the server.
I wrote a thin RPC layer over socket.io wrapping network calls in promises just for that reason. You can take a peek at it here.