How does Port Number really work in TCP?

Question

https://serverfault.com/questions/296603/understanding-ports-how-do-multiple-browser-tabs-communicate-at-the-same-time

how can an application use port 80/HTTP without conflicting with browsers?

How do multiple clients connect simultaneously to one port, say 80, on a server?

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?

Answer 1

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.

1. 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."

2. 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.

3. 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.

4. 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.

5. 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.

6. "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.

7. 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.

8. 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.

Answer 2

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.