Your question is great!

I would like to try to answer it from the point of view involving the system calls listen() and accept(). Understanding the behavior of these two calls I think is quite insightful and sufficient to answer your question.

Spoiler: we can answer your question by looking into how TCP/IP works 🙂

For the core part of the question there really is 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 (I have tried to elaborate on that a bit more here).

In case of a simple web browser / web server scenario

1. first, a TCP connection is established between both (initiated by the client)
2. then an HTTP request is sent through that TCP connection (from the client to the server)
3. then an HTTP response is sent through the same TCP connection (in the other direction, from the server to the client)

After this exchange, the underlying TCP connection is not needed anymore and usually becomes destroyed/disconnected. In case of a so-called “HTTP Upgrade request” (which can be thought of as: “hey, server! Please upgrade this to a WebSocket connection!”), the underlying TCP connection just goes on living, and the WebSocket communication goes through the very same TCP connection that was created initially (step (1) above).

This hopefully clarifies that the key difference between WebSocket and HTTP is a switch in a high-level protocol (from HTTP toward WebSocket) without changing the underlying transport channel (a TCP/IP connection).

Handling multiple IP connection attempts through the same socket, how?

This is a topic I was once struggling with myself and that many do not understand because it is a little non-intuitive. However, the concept actually is quite simple when one understands how the basic socket-related system calls provided by the operating system are working.

First, one needs to appreciate that an IP connection is uniquely defined by five pieces of information:

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

Now, socket objects are often thought to represent a connection. But that is not entirely true. They may represent different things: they can be active or passive. A socket object in passive/listen mode does something pretty special, and that is important to answer your question.

http://linux.die.net/man/2/listen says:

listen() marks the socket referred to by sockfd as a passive socket,
that is, as a socket that will be used to accept incoming connection
requests using accept(2).

That is, we can create a passive socket that listens for incoming connection requests. By definition, such a socket can never represent a connection. It just listens for connection requests.

Let’s head over to accept() (http://linux.die.net/man/2/accept):

The accept() system call is used with connection-based socket types
(SOCK_STREAM, SOCK_SEQPACKET). It extracts the first connection
request on the queue of pending connections for the listening socket,
sockfd, creates a new connected socket, and returns a new file
descriptor referring to that socket. The newly created socket is not
in the listening state. The original socket sockfd is unaffected by
this call.

Let’s digest this carefully, I think this now really answers your question.

accept() does not change the state of the passive socket created before. It returns an active (connected) socket (such a socket then represents the five pieces of information states above — simple, right?).

Usually, this newly created active socket object is then handed off to another process or thread or just “entity” that takes care of the connection. After accept() has returned this connected socket object, accept() can be called again on the passive socket, and again and again — something that is known as accept loop.

But calling accept() takes time, right? Can’t it miss incoming connection requests? There is more essential information in the just-quoted help text: there is a queue of pending connection requests! It is handled automatically by the TCP/IP stack of your operating system.

That means that while accept() can only deal with incoming connection requests one-by-one, no incoming request will be missed even when they are incoming at a high rate or (quasi-)simultaneously. One could say that the behavior of accept() is rate-limiting the frequency of incoming connection requests your machine can handle. However, this is a fast system call and in practice, other limitations hit in first — usually those related to handling all the connections that have been accepted so far.