Internals of Web Socket Communication

First, one needs to appreciate that an IP connection is uniquely defined by five pieces of information. A socket is a tuple of 5 pieces —

IP:PORT of Machine A and IP:PORT of Machine B and the protocol (TCP or UDP)

Example
(client IP, client port, server IP, 9999, tcp)

How the WebSocket server handles multiple incoming connection requests?

There is really no difference depending on HTTP or WebSocket. The common ground is TCP over IP. Sending an HTTP request requires an established TCP/IP connection between two parties.

Each connection to a server (in particular to your HTTP server here) creates it’s own socket and then runs on that socket.

What happens on one socket is completely independent of what happens on any other socket that is currently connected. So, when one socket is switched to the WebSocket protocol, that does not change what happens to other current or incoming socket connections. Those get to decide on their own how they will be processed.

So, open sockets can be using the WebSocket protocol while other incoming connections can be regular HTTP requests or requests to create a new WebSocket connection.

What is the sequence of handshake and HTTP upgrade to WebSocket ?

So, you can have this type of sequence. Simultaneous Websocket and HTTP connections to port 80 are handled.

1. Client A connects to server on port 80 with HTTP request to initiate a webSocket connection. This process creates a socket between the two.
2. Server responds yes, to the upgrade to webSocket request and both client and server switch the protocol for this socket only to the webSocket protocol.
3. Client A and Server start exchanging packets using the webSocket protocol and continue to do so for the next several hours.
4. Client B connects to the same server on port 80 with a regular HTTP request. This process creates a new socket between the two.
5. Server sees the incoming request is a normal HTTP request and sends the response.
6. When client B receives the response, the socket is closed.
7. Client C connects to the same server on port 80 with an HTTP request to upgrade to a webSocket.
8. Server responds yes, to the upgrade to webSocket request and both client and server switch the protocol for this socket only to the webSocket protocol.
9. At this point, there are two open sockets using the webSocket protocol that can be communicating and the server is still accepting new connections that can be either regular HTTP requests or can be requests for an updrade to the webSocket protocol.

So, at all times, the Server is still accepting new connections on port 80 and those new connections can either be regular HTTP requests or can be HTTP requests that are a request to upgrade to the webSocket protocol (and thus start a webSocket connection). And, while all this is going on, webSocket connections that have already been established are communicating over their own socket using the webSocket protocol.

The main thing here is: Websocket protocol is not HTTP.

It serves a different purpose. It is an independent application-layer communication protocol also built on top of TCP (although TCP isn’t necessary the requirement, but a transport layer protocol that fits the requirements of the Websockets application layer protocol).