How does a TCP server know which application a client wants to reach?
Each server application is bound to ("listening on") a specific port; that port is "open," so when a segment arrives addressed to that port, the transport layer accepts it and hands the data to the matching application.
A server doesn't run "TCP" for clients to talk to — it runs applications (a web server, a mail server, an SSH daemon), and each one is configured to listen on a particular port number. The transport layer uses the destination port in every incoming segment as the address that picks the right application.
The key rules:
- An active application bound to a port is considered open: the transport layer accepts and processes any segment addressed to that port and passes the data up to that application.
- Only one service per port on a given host — you cannot bind two applications to the same TCP port on the same machine, because the destination port would be ambiguous. (This is why "Address already in use" errors happen.)
- An incoming request is accepted only if it is addressed to the correct socket (the server's IP + the open port). Traffic to a closed/unbound port is rejected (typically with a TCP RST).
Why it matters: this is the demultiplexing step in reverse. The client labels its request with a destination port; the server side uses that same number to route the data to whichever of its many listening processes asked for it. It is exactly why one server with one IP address can simultaneously offer HTTP (80), HTTPS (443), and SSH (22) without confusion.
Tip: "open port" = a process is listening there. Running netstat -a (or ss -l) on the server shows every port in the LISTENING state — that is the list of services currently accepting connections.
Go deeper:
Port (computer networking) — listening — how a listening server port demultiplexes incoming connections to the right process.
Network socket — server sockets — the bind/listen/accept model behind an "open" server port.