14

Suppose two web browsers are running on the same computer and are accessing the same website (in other words, accessing the same IP address on the same port).

How does the operating system recognize which packets are from/for which program?

Does each program have a unique id field in the TCP header? If so, what is the field called?

Shog9
  • 156,901
  • 35
  • 231
  • 235
mcjabberz
  • 9,788
  • 10
  • 36
  • 38
  • 17
    People, come on. Just because it's about a network protocol doesn't mean it belongs on serverfault! – John Saunders Jul 20 '09 at 16:07
  • More likely superuser.com, in my mind... – Rowland Shaw Jul 20 '09 at 16:16
  • 2
    I agree with John, this sort of knowledge can come in extremely handy when doing programming that involves the network (which is really common these days). Refer to Joel's Law of Leaky Abstractions (http://www.joelonsoftware.com/articles/LeakyAbstractions.html) if you're interested to know why. – Jack Leow Jul 20 '09 at 16:19
  • 1
    Anyone who does network programming and doesn't know this kind of stuff shouldn't be doing network programming. This definately belongs on SO. – Robert S. Barnes Jul 20 '09 at 17:27
  • @Will: what about it makes it useful to be on SF? TCP/IP protocol details aren't something most sysadmins I know are familiar with. – John Saunders Jul 21 '09 at 01:12
  • @mcjabberz: are you asking about any two programs, or is your question specific to web browsers? – John Saunders Jul 21 '09 at 01:13

8 Answers8

37

The two programs are not actually accessing the "same port." For purposes of TCP, a connection is defined by the tuple (src_ip,src_port,dst_ip,dst_port).

The source port is usually ephemeral, which means it is randomly assigned by the OS. In other words:

Program A will have:

(my_ip, 10000, your_ip, 80)

Program B will have:

(my_ip, 10001, your_ip, 80)

Thus, the OS can see those are different "connections" and can push the packets to the correct socket objects.

Christopher
  • 8,815
  • 2
  • 32
  • 41
  • It's also worth noting that when you're performing socket operations while developing (say, opening a socket connection in Java), the source port is automatically assigned by the system. – Jack Leow Jul 20 '09 at 16:21
  • 1
    I did mention that: "The source port is usually ephemeral, which means it is randomly assigned by the OS" :-) – Christopher Jul 20 '09 at 20:50
  • Thanks man! I was told that there was some field in the TCP header... I guess I should stop listening to them then. :) – mcjabberz Jul 20 '09 at 21:34
  • It doesn't have to be assigned by the system, you can request a specific source port with bind. – Robert S. Barnes Jul 20 '09 at 21:35
  • 1
    Hence Christopher's choice of the word "usually" in the description of the source port choice. – lavinio Jul 20 '09 at 21:57
  • And when it is assigned by the system, its often not random. Sequential assignment of ephemeral source ports is not at all uncommon. – caf Jul 30 '09 at 04:00
4

the source port number will be different even if the destination port number is the same. the kernel will associate the source port number with the process.

QAZ
  • 4,870
  • 6
  • 36
  • 50
3

When the client opens a connection to destination port 80, it uses an arbitrary unused source port on the local machine, say 17824. The web server then responds to that client by sending packets to destination port 17824.

A second client will use a second unused port number, say 17825, and so the two sockets' packets will not be mixed up since they'll use different port numbers on the client machine.

John Kugelman
  • 349,597
  • 67
  • 533
  • 578
3

Christopher's answer is partially correct.

Programs A and B actually have a handle to a socket descriptor stored in the underlying OS's socket implementation. Packets are delivered to this underlying socket, and then any process which has a handle to that socket resource can read or write it.

For example, say you are writing a simple server on a Unix like OS such as Linux or Mac OSX.

Your server accepts a connection, at which point a connection consisting of 

( src IP, src Port, dest IP, dest Port )

comes in to existence in the underlying OS socket layer. You then fork a process to handle the connection - at this point you now have two processes with handles to the socket both of which can read / write it.

Typically ( always ) the original server will close it's handle to the socket and let the forked process handle it. There are many reasons for this, but the one that is not always obvious to people is that when the child process finishes it's work and closes the socket the socket will stay open and connected if the parent process still has an open handle to it.

Robert S. Barnes
  • 39,711
  • 30
  • 131
  • 179
  • I think few modern server-side programs `fork` and `exec` for each incoming connection. A single thread can handle many simultaneous connections, and is way more efficient. This comment describes one particular method of implementation. – lavinio Jul 20 '09 at 16:36
  • 2
    Actually, this comment is trying to clarify the misunderstanding that the socket belongs exclusively to one process and that the OS "delivers" packets to a particular process. The socket belongs to the OS and the process has access to that underlying OS resource. – Robert S. Barnes Jul 20 '09 at 17:25
  • 1
    @lavinio That's why Robert said "fork" and not "fork and exec" – wnrph Jul 06 '13 at 06:47
  • 1
    It's still incorrect to describe a single implementation as a more complete "way" that TCP works. Many network programs that require massive scale do not do things this way, and some of them do not use the OS's network stack at all. From the standpoint of the network protocol, this answer is not correct. The TCP specification has no notion of a "socket". Only ports and addresses. – Christopher Aug 07 '13 at 17:49
  • @Christopher The OP is specifically asking about how an OS implements a TCP/IP stack and how packets are delivered to the application layer. I wanted to clarify that TCP doesn't deliver packets to the application and in fact doesn't know anything about the application at all. The way your answer is worded, it sounds to me like you are implying that that OS "pushes" / delivers packets to the socket in the client application. I just wanted to clarify that that's not the case. – Robert S. Barnes Aug 08 '13 at 10:23
  • @Robert I was not trying to explain how sockets are implemented. Merely that there is such a concept and packets do indeed get delivered to them based on the mapping specified. Where the socket lives and what exactly it means to deliver data to a socket varies wildly, even among Unix-like OS's, so it is best not to muddle up the concepts of mapping and delivery with the details of some implementation. – Christopher Aug 09 '13 at 14:15
0

By port number.

  • why was this voted down? It's somewhat lacking in detail but it's not wrong and the link to wikipedia would be useful if it wasn't a rather confusing wikipedia page – Mark Baker Jul 20 '09 at 16:10
0

IP address is used to identify computer, and port is used to identify process(application) within the computer. When a port is used by one process, other processes can't use it any more. So if any packet is sent to that port, only the owner of that port can handle that packet.

Hardy Feng
  • 459
  • 4
  • 13
  • While this is basically true (there are some minor caveats about forked processes using the same socket because it was created before the fork), I'm not sure what it adds compared with the answers that have been here for a while. In general, it is a good idea to make sure that a new answer to an old question is providing some new, valuable insight — and I'm not convinced this answer does that. – Jonathan Leffler Aug 28 '13 at 04:46
0

Connections are identified by a pair of endpoints. – Endpoint means (ip, port)

Prakhar Agarwal
  • 2,724
  • 28
  • 31
0

Os assigns random number as src port number so, when packet travels to the receiving side, it is treated as different process's msg, since src port numbers are different.

ADITI MISHRA
  • 1