You certainly noticed that WebSocket is the current
trendy flavor for any modern web framework.
But does it scale? Would it replace HTTP/REST?
There is a feature
request ticket about them for mORMot, so here are some thoughts -
matter of debate, of course!
I started all this by answering a StackOverflow
question, in which the actual answers were not accurate enough, to my
From my point of view, Websocket - as a protocol -
is some kind of monster.
You start a HTTP stateless connection, then switch to WebSocket
mode which releases the TCP/IP dual-direction layer, then you may switch later
on back to HTTP...
It reminds me some kind of monstrosity, just like encapsulating everything over
HTTP, using XML messages... Just to bypass the security barriers... Just
breaking the OSI layered
It reminds me the fact that our mobile phone data providers do not use
broadcasting for streaming audio and video, but regular Internet HTTP servers,
so the mobile phone data bandwidth is just wasted when a sport event occurs:
every single smart phone has its own connection to the server, and the same
video is transmitted in parallel, saturating the single communication
channel... Smart phones are not so smart, aren't they?
WebSocket sounds like a clever way to circumvent a
But why not use a dedicated layer?
I hope HTTP 2.0 would allow
pushing information from the server, as part of the standard... and in one
decade, we probably will see WebSocket as a deprecated
You have been warned. Do not invest too much in WebSockets..
OK. Back to our existential questions...
First of all, does the WebSocket protocol scale?
Today, any modern single server is able to server millions of clients at
Its HTTP server software has just to be is Event-Driven (IOCP)
oriented (we are not in the old Apache's one connection = one
thread/process equation any more).
Even the HTTP server built in Windows (http.sys - which is used in
mORMot) is IOCP oriented and very efficient (running in kernel
From this point of view, there won't be a lot of difference at scaling between
WebSocket and a regular HTTP connection. One TCP/IP connection
uses a little resource (much less than a thread), and modern OS are optimized
for handling a lot of concurrent connections: WebSocket and HTTP
are just OSI 7 application layer protocols, inheriting from this TCP/IP
But, from experiment, I've seen two main problems with
- It does not support CDN;
- It has potential security issues.
About the potential problems of using WebSocket:
1. Consider using a CDN
Today, web scaling involves using Content Delivery
Network (CDN) front ends, not only for static content (html,css,js) but
also your (JSON) application
Of course, you won't put all your data on your CDN cache, but in practice, a
lot of common content won't change often.
I suspect that 80% of your REST resources may be cached...
Even a one minute (or 30 seconds) CDN expiration timeout may be enough
to give your central server a new life, and enhance the application
responsiveness a lot, since CDN can be geographically tuned...
To my knowledge, there is no WebSocket support in CDN yet, and
I suspect it would never be.
The WebSocket protocol is stateful, whereas HTTP is stateless, so
is designed to be cached.
In fact, to make WebSocket CDN-friendly, you may need to switch
to a stateless RESTful approach... which would not be
WebSocket any more.
2. Security issues
WebSocket has several potential security issues, especially
For illustration about new security vulnerabilities , see
this set of slides and this webkit ticket.
Some quotes from this set of slides:
- WebSockets still fall victim to “old” threats;
- If you can intercept or inject you can overtake ws:/wss: (MIM
- Malicious content can exhaust browser by grabbing max. allowed number of
WebSocket connections (DOS attacks on client side by browsers!);
- Malicious content can create large number of WebSocket connections
to victim WebSocket server (DOS attacks on server);
- Just waiting for mistakes to happen (since developers can put anything on
- wss: means secure transport, not secure app;
- Browser support still in flux;
- WebSockets solve connection problems, not security problems.
Furthermore, WebSocket avoid any chance of packet inspection
at OSI 7 application layer level.
firewalls, IDS, IPS are pretty
standard nowadays, in any serious security policy.
In fact, WebSocket makes the transmission obfuscated, so may
become a major breach of security leak.
When to use WebSockets?
As a conclusion, I would recommend the following, for any project:
- Use WebSocket for client notifications only (with a fallback
mechanism to long-polling - there are plenty of libraries around);
- Use RESTful / JSON for all other data, using a CDN or proxies for cache, to
make it scale.
In practice, full WebSocket's applications do not scale well.
Just use WebSocket for what it was designed to: a protocol to
push notifications from the server to the client.
With mORMot, and for all our end-user projects, this is the
direction we are currently entitled to go.
Still privileging a pure stateless approach, which fits so good with our
Discussion is welcome in our forum, as