How does that tcp traffic work

[Cleber P. de Souza]

For each session the server fork() the request and give them a id
process. For data arriving at port 80 the server check the process id
that has the same ip address source, ip source port, ip destination
port and ip ip destination address. Using this the server process know
to how internal process (fork'ed) follow the request.
It's possible many connections to the same server port due a param in
the socket options and the fork/thread treatment on the server code.
Remember that in the David example about FTP, exist two conections
methods like active and passive that have different bahaviors.
Nowadays, passive is the more common.


On 8/4/06, David Tonhofer <d.tonhofer at m-plify.com> wrote:
> Bliss, Aaron wrote:
> > I know this is a bit of a networking question more than a redhat
> > question, however I'm sure you guys will be able to explain this to me;
> > I'm trying to understand exactly how this works, and have not been able
> > to find any solid authority on the subject; I understand the concept of
> > ports, well know ports, and part of the initial 3 way handshake of a new
> > tcp session; My question is, does the initial receiving host of a
> > session (usually a server) use the port that it's listening for the tcp
> > session, or does it negotiate a port number that is not in use like the
> > client does?  For example, host A is a client, host B is a webserver
> > listening on port 80; host A wants some data from host B's port 80; lets
> > say host A wants to use port 6785; will the tcp session then use port
> > 6785 for host A and port 80 for host B, or will they also pick an
> > available port from host B as well; if port 80 is used, how are multiple
> > sessions possible; i.e. how can the host B serve up more web traffic if
> > port 80 is busy?  Thanks for your help.
> >
> > Aaron
> >
> Here is what happens:
>
> 1) TCP Server listens on port X at address IP1
> 2) TCP Client connects ("handshake")
>    to port X at address IP1
>    from port Z at address IP2
> 3) TCP Server code will spawn a thread or process to handle this
> connection. The
>   abstraction used to represent the connection is the 'socket', which is
> a source and sink
>   of bytes, but basically it's a I/O buffer.
>
> The TCP session identifier is: (IP1,Z,IP2,X), all TCP packets carry that
> information.
> The OS at IP1 will correctly route the packet to its destination I/O
> buffer (to be picked up
> by the handling thread) based on that identifier. Thus the packets can
> STILL go to the
> same port X on the Server.
>
> Note that for FTP, there is first a connection from the client to server
> port 21, then
> a negotiation over the TCP connection whereupon the server opens another
> server
> port (high-numbered) on the the server machine and the client
> additionally connects to
> that to transfer data. But this means *two* TCP connections.
>
>
> Best regards,
>
> -- David
>
> "four fifty -- press return"
>
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>


-- 
Cleber P. de Souza