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?
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).
Related
Im trying to write a server client program, where client sends request through UDP socket to a server, then server responds back to a client through TCP socket.
My question is, how can server establish a TCP connection back to a client after getting the request through UDP?
I'll add code parts on Monday, but I more interested in pseudocode for that. Does that mean that the client should listen on tcp port after sending udp request? So confused
I have a TCP server sitting on one host in a VPC, and a TCP client sitting on a separate host and VPC. Right now they are able to transmit data to each other using any matching ports, but I want their data to be transmitted to each other over HTTPS (port 443), is there a standard way of doing this?
My initial thought it to have Nginx running on both hosts to handle SSL over 443 with streams to handle the TCP traffic, but I'm lost when it comes to configuring the stream block in Nginx to wrap the TCP traffic with SSL on 443 for outgoing traffic for the server, or how to receive it on the client side and forward it to the TCP client. Any and all help is appreciated.
(This question is inspired by a response to this thread: How WebSocket server handles multiple incoming connection requests?)
My understanding is this way:
Assume client IP = 1.1.1.1, server IP = 9.9.9.9
Browser choose a random local available port, say 5555, and initiate a connection to server's port 80. So on client, the socketfd_client should represent an IP connection like (1.1.1.1:5555, 9.9.9.9:80, TCP).
Server calls accept() on its port 80 and identified the connection request from client. Then server picks a random local available port, say 8888, to fulfill that connection request. So on server, the socketfd_server should represent an IP connection like (1.1.1.1:5555, 9.9.9.9:8888, TCP).
My question is:
If my above understanding is correct, socektfd_client and socketfd_server have different server port. Client has 80 while server has 8888. How could the communication be carried out? I think client should change to use the server port 8888 as well, but when and how?
Browser choose a random local available port, say 5555
No. The operating system does that: specifically, the TCP part of the network stack.
and initiate a connection to server's port 80. So on client, the socketfd_client should represent an IP connection like (1.1.1.1:5555, 9.9.9.9:80, TCP).
Correct.
Server calls accept() on its port 80 and identified the connection request from client.
Correct.
Then server picks a random local available port, say 8888
No.
to fulfill that connection request.
No.
So on server, the socketfd_server should represent an IP connection like (1.1.1.1:5555, 9.9.9.9:8888, TCP).
No. The connection at both ends is represented by {1.1.1.1:5555, 9.9.9.9:80}. There is no new port at the server end.
My question is:
If my above understanding is correct
It isn't.
socektfd_client and socketfd_server have different server port.
No.
Client has 80 while server has 8888. How could the communication be carried out? I think client should change to use the server port 8888 as well, but when and how?
Never.
I have a load balancer group with few target servers and they are SSL enabled.
Now I want to do the TCP monitoring on the target servers port (443)
Does TCP monitor work with the backends which are on https ?
TCP Monitor, according to me, does a socket connect on the given Host and Port. What this means is, if there is an open port on the target server, then server is considered alive and kicking.
Since this is only a socket connect; protocol HTTP,HTTPS does not matter as long as there is port open and has a listener on the port.
Port 80 accept two different protocols: HTTP and Stratum. The latter is a line-based protocol always start with '{'. If the client connect to port 80 and sends something like 'GET / HTTP/1.0...', forward the connection to port 8000, if it sends '{"id": 1,...', forward it to port 3333. Is it possible to do it with iptables? Thanks!
I don't think you can do that with iptables.
The problem is that, at the time you can detect the first byte of the TCP payload, a connection has been established between source:port to server:80.
Forwarding the packets in mid-connection will result in the packets being rejected, because the TCP stack never sees the SYN/SYN-ACK packets for connection establishment to ports :8000 or :3333.
You'll need something listening on port :80, then based on the very first by received, open a connection to port :8000 or :3333 and replay the contents. That something must also perform reverse-replay of the webserver's/Stratumserver's replay toward the connection initiator.