In the traditional Client-Server model, the client communicates with the server via the HTTP protocol. This consists of request-response pairs. A three way handshake happens establishing a TCP connection. Post the TCP connection, HTTP request-response pairs are transmitted between the client and server.
However, this way of communication is stateless, since one client can request to multiple HTTP servers and the client state need not be stored in the server. Therefore, millions of clients can be served independently across multiple HTTP servers that are load balanced by reverse proxy servers. Therefore, HTTP servers are horizontally scalable.
However, note that a typical HTTP server cannot, on its own, initiate a communication. It can only respond back to the incoming request initiated by a client. Hence, the server cannot broadcast or issue Server Sent Events simply because the server just does not know the state of the client.
However, in case of a WebSocket protocol, one client is bound to a single WebSocket server and the WebSocket server knows the state of the client. The server can broadcast or multicast events that are initiated from the server itself. This can happen simply because the way of communication is stateful and the server knows the state of the client. This helps in low latency real time communications between the client and the server. Now, a loss of connection implies the loss of state.
Note that one client ideally binds to one WebSocket server and this server maintains the state of the client. However, just simply scaling the WebSocket servers horizontally cannot replicate the states across the multiple WebSocket servers and vertically scaling a WebSocket server is capped by hardware limitations.
