Will WebSocket replace HTTP? Does it scale?

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 opinion.

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 model...
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 limitation...
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 technology.
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 once.
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 mode).
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 specifications.

But, from experiment, I've seen two main problems with WebSocket:

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 data.

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 about DOS attacks.
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 attack);
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 the wire);
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.
Application 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 RESTful model.

Discussion is welcome in our forum, as usual!

Synopse Open Source