title: How WebSocket server handles multiple incoming connection requests?
body: <p>According to <a href="https://msdn.microsoft.com/en-us/hh969243.aspx" rel="noreferrer">here</a>:</p>
  
  <blockquote>
    <p>The HTTP Upgrade header requests that the server <strong><em>switch the
    application-layer protocol from HTTP to the WebSocket protocol</em></strong>.</p>
    
    <p>The client handshake established a HTTP-on-TCP connection between IE10
    and server. After the server returns its 101 response, the
    application-layer protocol switches from HTTP to WebSockets which uses
    the previously established TCP connection.</p>
    
    <p><strong><em>HTTP is completely out of the picture</em></strong> at this point. Using the
    lightweight WebSocket wire protocol, messages can now be sent or
    received by either endpoint at any time.</p>
  </blockquote>
  
  <p>So, my understanding is, after the 1st client finished handshake with the server, the server's 80 port will be <strong><em>monopolized</em></strong> by the WebSocket protocol. And the <strong>HTTP is no longer working on 80 port</strong>. </p>
  
  <p>So how could the 2nd client exchange handshake with the server. <strong><em>After all the WebSocket handshake is in HTTP format.</em></strong></p>
  
  <h2>ADD 1</h2>
  
  <p>Thanks for all the answers so far. They are really helpful.</p>
  
  <p>Now I understand that the same server's 80 port is <strong><em>shared</em></strong> by multiple <code>TCP</code> connections. And this sharing is totally OK because <code>TCP</code> connections are identified by a 5-element tuple as <code>Jan-Philip Gehrcke</code> pointed out.</p>
  
  <p>I'd like to add a few thoughts.</p>
  
  <p>Both <code>WebSocket</code> and <code>HTTP</code> are merely application level protocols. <em>Usually</em> they both rely on the <code>TCP</code> protocol as their transport. </p>
  
  <h2>Why choose port 80?</h2>
  
  <p>WebSocket design intentionally choose server's port 80 for <em>both handshake and following communication</em>. I think the designer wants to make WebSocket communication <em>look like</em> normal HTTP communication <strong><em>from the transport level's perspective (i.e. the server port number is still 80)</em></strong>. But according to <code>jfriend00</code>'s answer, this trick doesn't always fool the network infrastructures.  </p>
  
  <h2>How does the protocol shift from <em>HTTP</em> to <em>WebSocket</em> happen?</h2>
  
  <p>From RFC 6455 - WebSocket protocol</p>
  
  <blockquote>
    <p>Basically it is intended to be as close to just exposing raw TCP to
    script as possible given the constraints of the Web. It’s also
    designed in such a way that its servers can share a port with HTTP
    servers, by having its handshake be a valid HTTP Upgrade request. One
    could conceptually use other protocols to establish client-server
    messaging, but the intent of WebSockets is to provide a relatively
    simple protocol that can coexist with HTTP and deployed HTTP
    infrastructure (such as proxies) and that is as close to TCP as is
    safe for use with such infrastructure given security considerations,
    with targeted additions to simplify usage and keep simple things
    simple (such as the addition of message semantics).</p>
  </blockquote>
  
  <p>So I think I am wrong on the following statement:</p>
  
  <blockquote>
    <p>The handshake request <em>mimic</em> HTTP request but the communication that
    follows don't. The handshake request arrives at the server on port 80.
    <strong>Because it's 80 port, server will treat it with HTTP protocol. And that's why the WebSocket handshake request must be in HTTP format.</strong> 
    If so, I think the HTTP protocol <strong>MUST</strong> be modified/extended to
    recognize those WebSocket-specific things. Otherwise it won't realize
    it should <strong><em>yield to</em></strong> WebSocket protocol.</p>
  </blockquote>
  
  <p>I think it should be understood like this:</p>
  
  <blockquote>
    <p>WebSocket communication starts with a <strong>valid</strong> HTTP request from
    client to server. So it is the server that follows the HTTP protocol
    to parse the handshake request and <strong>identify</strong> the begging for
    protocol change. And it is the server that switches the protocol. So
    HTTP protocol doesn't need to change. HTTP protocol doesn't even need
    to know about WebSocket.</p>
  </blockquote>
  
  <h2>WebSocket and Comet</h2>
  
  <p>So WebSocket is different from <a href="http://en.wikipedia.org/wiki/Comet_%28programming%29" rel="noreferrer">Comet</a> technologies in that WebSoket doesn't limit itself within the current HTTP realm to solve the bi-directional communication issue.</p>
  
  <h2>ADD 2</h2>
  
  <p>A related question: <a href="https://stackoverflow.com/questions/35387835/how-does-a-browser-establish-connection-with-a-web-server-on-80-port">How does a browser establish connection with a web server on 80 port? Details?</a></p>