1

http-client.js:

const http = require('http');

http.get
(
    {
        port : 9001,
        host : 'localhost'
    },
    (res) =>
    {
        //...
    }
);

tcp-server.js:

const net = require('net');

let server = new net.Server();

server.listen(9001, 'localhost', (err) =>
{
    console.log('Started listening', server.address());
});

server.on('connection', (sock) =>
{
    console.log(`Connected ${sock.remoteAddress}:${sock.remotePort}`);
});

I run node tc-server.js and then when I run node http-client.js I see output like:

Started listening { address: '127.0.0.1', family: 'IPv4', port: 9001 }
Connected 127.0.0.1:59506

I close http-client.js and run node http-client.js again. I see: Connected 127.0.0.1:59508

I close server and run again, and run the client again, I see Connected 127.0.0.1:59510

So the socket.remotePort is increasing all the time. What I don't understand is why those numbers for ports, I was expecting to see 9001 for port number since that's where the http request was being sent and successfully reached the listening tcp server.

Robert C. Holland
  • 1,651
  • 4
  • 24
  • 57

1 Answers1

3

Both sides of a TCP conversation have to have an address and a port. E.g., clients use ports too. What your console.log was telling you was that the client connected to your port 9001 using its port 59506. When your server sends packets to the client, it addresses them with the client's address and that port number, so the TCP layer of the network stack on the client knows what process to send the packet to. (More in the Wikipedia article on TCP.) You see the number increasing just as a byproduct of how your client system assigns available ports to connections.

You don't normally need to care about the client's port.

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
  • If the http client is talking to underlying tcp client to send tcp messages via port `59506`, how is the `tcp-server.js` listening on tcp port `9001` is receiving the message, wouldn't the tcp server have to instead listen on port `59506` ? – Robert C. Holland Apr 01 '18 at 17:43
  • 1
    @RobertC.Holland: No, each side uses its own port, and the ports don't have to match (they *usually* don't). Consider the common case where a web server is also used as a web client (perhaps scraping information from another site in response to a request). If it's using port 80 to serve HTTP to clients, it's obviously not going to use port 80 when *it's* the client connecting to another server. (Or if you run a web browser on the machine where the web server is running, it's even more obvious that port 80 can't be used for both processes...) – T.J. Crowder Apr 01 '18 at 17:54
  • Reason for picking different ports are clarified now, thanks. I still don't understand how -if client is sending through different ports, it still manages to reach listening server on a specified port. – Robert C. Holland Apr 01 '18 at 18:03
  • 1
    @RobertC.Holland: :-) Let's say we have server S and client C. S is listening on IP 1.2.3.4 port 9001. C (on IP 9.10.11.12) connects to S's port 9001 using C's port 59506, and as part of the setup of that connection, *tells* S that's the port it's using. When C sends a packet to S, it sends it to 1.2.3.4:9001. When S sends a packet to C, it sends it to 9.10.11.12:59506. Both sides are perfectly happy, they each have a unique address+port to send the data to for the connection. – T.J. Crowder Apr 01 '18 at 18:12
  • The fact that S's port is "fixed" is so that clients know how to connect to it. C's port isn't fixed, a different port is used for each connection (ports for old, closed connections can get reused for new ones). The channel isn't the port, the channel is each side knowing what address+port to send its messages to. (But again, you typically don't need to care about what port the client is using, it's handled for you.) – T.J. Crowder Apr 01 '18 at 18:14
  • 1
    This breakdown was very helpful. I understand now. Thank you very much for taking the time to explain it! – Robert C. Holland Apr 01 '18 at 18:18