How does Port Number really work in TCP?

Question

I have read the above questions but it seems the answers are inconsistent.

I want to know what exactly defines a socket connection, is it:

(sockid, source ip, source port, dest ip, dest port)

or only:

(source ip, source port, dest ip, dest port)

Can two different processes (e.g, two different browsers) communicate with a web server on the same source port? (the dest port would be the same by default)

What will happen in the case of different tabs in the same browser?

Also, as mentioned in one of the answers, a single web page can connect to multiple servers (e.g., ad servers) simultaneously. When connecting to multiple servers simultaneously, does the web browser (e.g., Chrome, Firefox) connect to each server using the same port, or does it use a different port for each server?

I did not read the referee questions but the sequenznumber has also a important role for identifying a connection. — rekire, Nov 02 '12 at 06:13

score 96 · Accepted Answer · edited Jul 31 '17 at 01:02

I know this is late, but since the thread is still on the internet, and because it's a common question with very few authoritative answers on the web, it deserves a more complete and concise explanation for those who may stumble into it, even at this late date.

You open a browser to pull up a web site, let's say google.com. In the process of specifying the web site your computer will arbitrarily pick a port number to use as its "source port." The number will be above 49152 which is the beginning of the "Dynamic, Private, or ephemeral ports" but below 65535 which is the highest port number available. The chosen port number is associated with that browser "instance."
Just for fun, you open a new tab on the browser and also type "google.com" on the url line. Your goal is to have two instances of google.com running because you're looking for different things. Your computer then chooses a second port number for that session, different from the "source" port it used for the first session. You could, in fact, do this many, many times, and each session will have a unique "source" port associated with each instance.
Your packet goes out to google.com, and the destination port number in every instance will be port 80. Web servers "listen" on port 80 for incoming connection requests. For each session with google.com you've opened, the destination port, from the perspective of your computer, will always be port 80, but for each instance of connection to google.com on your browser or browsers, the source port will uniquely identify one specific tab on one browser instance, uniquely. This is how they are differentiated on your computer.
google.com gets your first request. Its reply will specify port 80 as its source port. Here's where it gets interesting. Each query google.com received from you will be treated as a "socket," which is a combination of your IP address, and the specific port number associated with the process that contacted google.com. So, for instance we'll say your IP address is 165.40.30.12, and the source port number your computer used as its source port for four instances of communications with google.com (let's say four different tabs all opening google.com) were 61235, 62421, 58392, and 53925. These four "sockets" would then be 165.40.30.12:61235, 165.40.30.12:62421, 165.40.30.12:58392, and 165.40.30.12:53925. Each combination of "IP address:source port number" is unique, and google.com will treat each instance as unique. google.com responds to, and communicates with the "socket," that is, the combination of IP address and port.
Your computer gets its responses from google.com, and sorts them out by what it receives as its destination "socket" which it parses out by port numbers, assigning the response from google.com to the appropriate browser window or tab, as appropriate. No problem from your end of things as you see the correct response in the correct window every time.
"But," you're thinking, "what if someone else accidentally uses the same port number - let's say 61235 - as I've used for my source number? Doesn't this confuse google.com?" Not at all, because google.com is tracking "sockets" which are a combination of IP address and port number. Someone else, naturally, and we sincerely hope, is using a different IP address from the one you're using, let's say 152.126.11.27, and the combination of IP address and port number are unique - 152.126.11.27:61235 - differentiated by their different IP addresses, even though the port numbers are the same.
It doesn't matter if google.com gets 1000 queries from 1000 users, all using port 80 as their destination port number (the port google.com is listening to for incoming communications) because each of those 1000 users will all have unique IP addresses. google.com tracks its clients by their unique - and they always have to be unique, don't they? - socket numbers consisting of their IP address and "source" port number. Even if every one of those 1000 clients somehow managed to use the same "source" port number (unlikely to the max), they would still have differing IP addresses, making their source "socket" unique among all of the others.
This is all rather simple when you see it explained this way. It makes it clear that a web server can always listen on one port (80) and still differentiate from the various clients. It doesn't simply look at the IP address it received in the query - you'd think they should all be unique at first blush until you realize you could have more than one web page opened on that web server - but at the source port number, which in combination, make every query unique. I hope this is pretty clear. It's an elegant system when you think about it, yet simple once you understand it.

The local port is <= 65535, not < 65535. There is no guarantee the browser will use a new connection for a new tab to the same website. A query is not a socket. You are overlooking HTTP keepalive. You've made something rather simple rather complex, with 8 points where about two would do. — user207421, Feb 02 '17 at 19:30
@paul1307 - A little more info on how server side multiple requests are handled would make this answer complete and highly educating. — Saurabh Goyal, Nov 28 '17 at 11:39
But what if you have two computers as part of the same LAN, and the browsers just so happen to assign the same port number to one instance of google.com on PC-A and another instance of google.com on PC-B? — Aleksandr Hovhannisyan, Aug 31 '18 at 00:43
@AleksandrH The two computers have different IP addresses. There are no 'instances of coogle.com' anywhere except at Google. Presumably you mean *connections to* google.com. — user207421, May 31 '20 at 06:22
@AleksandrH "There are two "source port"s in play in a NAT scenario. The source port that the original computer set, and the external source port on the router. The latter is chosen by the router, not the hosts. Since, internally, each host has a different IP address, there is no collision." copy-pasted from comment on answer to a related question: https://stackoverflow.com/a/3329672 . I.e. the two computers PC-A and PC-B as hosts in the same LAN will choose their own ports, but when their packets are forwarded to the router, it will also translate the port numbers to ensure that the port + IP — hasManyStupidQuestions, Dec 16 '22 at 15:22
combinations will remain unique in the external network, even as the IP addresses are being translated by the router to become non-unique. So when the remote server sees the packets, it will see the same IP but two different port numbers (again the port numbers being chosen by the router). The "term NAT [network address translation] ... follow[s] common IT practice, though the actual role of a NAT device is both address translation and port address translation (PAT)", copy-pasted from https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat.html . — hasManyStupidQuestions, Dec 16 '22 at 15:25

score 10 · Answer 2 · edited Nov 02 '12 at 13:26

Taking your questions in turn:

A connection is defined by:

{ protocol, local IP, local port, remote IP, remote port }

(It's better to say local and remote rather than source and destination, because the local port is the source when you send, but the destination when you receive.)

The sockid is just a descriptor in the user process that maps to the connection in the kernel, just as a file descriptor maps to a file on disk that has been opened.

Two different processes cannot bind to the same local port. However, it's possible for two processes to use the same connection -- a socket descriptor can be inherited from a parent process to a child process, or the descriptor may be passed between processes using interprocess communications. The two processes would be using the same ports because they're actually sharing the same connection.

While the protocol allows use of the same local port when connecting to different remote servers or ports, most TCP stacks will not allow this. The API for binding a local port is the same whether you're using it for an outgoing connection or listening for an incoming connection, and the intention isn't specified until AFTER the port is bound. Since only one socket can listen on a particular port, the API simply refuses to allow multiple sockets to bind to a port (there's a special exception to this, but it's not relevant to this discussion). As a result, all outgoing connections will use different local ports. So when the browser opens multiple connections (either to the same or different web servers) they will have different local ports.

I have a question regarding your answer. Say I open two connections in two different tabs to stackoverflow.com (for the sake of this question let's assume I'm connecting to the same server). Let's say socket 1 is on local port 1 and remote port 80. The 2nd let's say local: 2 and remote: 80. From the view of the server, is it communicating on local: 80 and remote: 1 for socket 1 and local: 80 remote: 2 for socket 2 ? Or is it local: 1 and remote: 80 for socket 1 and local: 2 remote: 80 for socket 2? If it's the former, how is the server maintaining 2 open connections with the same local port? — Hart Simha, Aug 02 '13 at 08:14
It's the first way. The local port on the server is the remote port on the client, and vice versa. It's able to do it because a connection is defined by both ports and IPs, there's no problem having multiple connections with the same local port, as long as the remote port and/or IP are different. — Barmar, Aug 02 '13 at 12:19

score -2 · Answer 3 · answered Nov 02 '12 at 09:30

I have read the above question on respective forum but I guess people there also do not agree with each other.

I see no disagreement in any of those concerning the matters you mention.

I want to know what exactly defines a socket Connection

( sockid , source ip , source port , dext ip , dest port )

or only

( source ip , source port , dext ip , dest port )

The latter. The former is a figment of imagination. It isn't mentioned in any of the threads you cite.

What I want to ask is that can two different processes like two different Browsers communicate with a web server on same source port.(Dest port would be same by default).

Not if they are at the same source IP. It would violate the identity definition stated above.

What in case of Different tabs in same browser.

Yes, because of connection pooling. If you are talking about separate connections, the answer is still no.

Also as mentioned in one of the answers a single web page tries to connect to many different servers like ad servers etc. So does Chrome or firefox for that matter connect with the same port to different servers or use a single port.

You are going to have to explain this. What is the difference between 'the same port' and 'a single port'? Not a real question.

"Not if they are at the same source IP. It would violate the identity definition stated above." Surely they would be using a different ephemeral source/local port (their "exit" port) thus leading you to have a unique identity from: "{ local IP, local port, remote IP, remote port }" - i.e. the example isn't realistic. — Joe, Nov 02 '12 at 09:34
@Joe He asked about using the *same* source and destination ports. Your point? — user207421, Nov 03 '12 at 09:30
Just that having something manage to use the same source and destination ports seems contrived. Usually you'd get the exit port allocated for you, and I was wondering if that was the point of confusion. It's not typical to define your exit port, is it? — Joe, Nov 05 '12 at 08:51
@Joe It certainly isn't, but that doesn't invalidate anything I've said here. It seems to me that your comment belongs under his question, not my answer. — user207421, Nov 17 '12 at 23:38

How does Port Number really work in TCP?

3 Answers3

Linked