0

Let say I have a server XYZ that listens on port 50000 for TCP clients and port 80 for HTTP clients. And on the other side, I have a client that uses a WebSocket to establish a socket connection to port 50000 and will use HTTP port 80 for the handshake (of course).

Now, when the client begins, it will first send a request to server XYZ via the HTTP port 80, and the server will receive its request on port 80 for the handshake and will send a response for welcome. So, in that case, both parties are using port 80 (of course).

Now, when the handshake is done, the standard documentation says that the same TCP connection that is used for HTTP request/response for handshake purposes is then converted to the TCP socket connection. Ok right.

But, but if this whole handshake process and TCP connection for the HTTP request/response uses port 80 the first time, and that the same TCP connection is converted to the TCP socket connection, and this whole process is done via port 80, then how does the same TCP connection get converted to port 50000 for the TCP socket on both parties? Does the client initialize another TCP connection internally for changing to port 50000?

So, can anyone tell how the port conversion is performed and works in the WebSocket from port 80 to a different port in both parties? How does a complete single socket connection get established on the different ports? How does the same TCP connection change/flip its ports?

user207421
  • 305,947
  • 44
  • 307
  • 483
Stack Overflow
  • 1
  • 5
  • 23
  • 51
  • The 'standard documentation', whatever you mean by that, does not say any such thing. The socket is still the socket, the port is still the port, and the connection is still the connection. Nothing is converted. Port 5000 is the client port. No mystery. – user207421 Feb 07 '19 at 23:26

1 Answers1

5

A TCP socket connection cannot change ports at all. Once a connection has been established, its ports are locked in and cannot be changed. If you have a TCP socket connection on port 80, the only way to have a connection on port 50000 is to make a completely separate TCP socket connection.

A WebSocket cannot connect to port 80 and then switch to port 50000. However, an HTML page that is served to a browser from port 80 can contain client-side scripting that allows the browser to make a WebSocket object and connect it to port 50000. The two TCP connections (HTTP and WebSocket) are completely separate from each other (in fact, the HTTP socket connection does not even need to stay open once the HTML is served, since HTTP is a stateless protocol).

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • **Comment Part #1:** No, my question is let say I did `var ws = new WebSocket("ws://something:50000/something/something")` now when I run this file in the browser the `HTTP` protocol will come into the action to begin the Handshake and a regular `HTTP` request on port `80` will be generated, so, in that case, the `TCP` for the `HTTP` will also be used. – Stack Overflow Nov 06 '18 at 05:41
  • **Comment Part #2:** Now on the server side, the server is also listening on port `80` for `HTTP` requests. When the server receives that request it will respond with welcome `Handshake` on the same port `80` right? So, the main question is that as you see above I setup port `50000` for `WebSocket` communication then how the port from `80` is changed to `50000`? Because the same request was started with port `80` then how port from `80` to `50000` is converted/changed? – Stack Overflow Nov 06 '18 at 05:42
  • **Comment Part #3:** Because the communication began on port `80`. How this `ws` is handover from the port `80` to the port `50000` after the `Handshake`. This is my question !!! – Stack Overflow Nov 06 '18 at 06:02
  • 1
    You are just asking the same questions you already asked. I already covered this in my answer. The HTML page is delivered via HTTP on port 80 only. Then the browser runs the Javascript, which creates the WebSocket object, which connects to port 50000 only. That is a completely separate TCP connection. The only handshake involved is the WebSocket handshake on port 50000. There is no handshake on port 80. There is no port change. You need to study up more on how TCP, HTTP, and WebSockets actually work. Especially TCP, you are clearly lacking a fundamental understanding of the basics of sockets. – Remy Lebeau Nov 06 '18 at 06:05
  • Ok, I got you. But sir as you mentioned in the answer that `A WebSocket cannot connect to port 80` but here I tested and I can connect the `WebSocket` to port `80` and it works just fine `var ws = new WebSocket("ws://something:80/something/something")`. Can you please tell what exactly means `A WebSocket cannot connect to port 80`? – Stack Overflow Nov 06 '18 at 06:24
  • 1
    @SunnyKhan a WebSocket connection begins life as an HTTP request, but it quickly upgrades away from HTTP after the initial request is done. The client's WebSocket object can *connect* to port 80, but it cannot *complete its handshake* **unless** the server implements the WebSocket protocol on port 80. It is hard to know if that is actually the case in your situation. For all we know, your server ignores the port number when deciding whether to complete a WebSocket handshake. But I've already answered your question about how a client switches ports. Take it or leave it. – Remy Lebeau Nov 06 '18 at 07:57
  • Thanks. Can you tell me one more thing that whether this handshake HTTP request/response is real HTTP request/response or is a plain text contains the HTTP headers as a string data? You know why I am asking this because the port 80 understands the HTTP protocol but not port 50000(in my case). So how the port 50000 determines that this is HTTP request and generate HTTP response because the HTTP protocol is only understood by port 80, not 50000, or it is the responsibility of the programmer to make port 50000 understand and handle the HTTP protocol using the programming logic? can you tell? – Stack Overflow Nov 06 '18 at 09:09
  • 1
    @SunnyKhan the answer to that is in the [WebSocket protocol spec](https://tools.ietf.org/html/rfc6455), I suggest you read it. – Remy Lebeau Nov 06 '18 at 16:12