Core CS · Computer Networks

IP finds the machine, the port finds the program

Every packet arriving for your laptop carries exactly one destination address, and that address names the machine and nothing else. Sixteen bits in the transport header close the gap to the process. Four numbers rather than two are what let one server port hold ten thousand conversations without mixing a single byte.

Step seven segments through one host and watch the four-tuple decide →

One host at 10.0.0.5 is holding five sockets at once: nginx listening on port 80, two live connections to two different laptops, sshd on 22, and a DNS resolver on UDP 53. Every segment that arrives has to end up in exactly one of them. This lesson is the rule the host uses to pick.

01 The idea

The network layer stops at the front door

An IP packet carries exactly two addresses, and both of them name machines. Every router between here and there reads the destination address, looks it up in a table, and forwards; the previous module was entirely about how that lookup works. When the packet finally lands at 10.0.0.5, the network layer has finished its whole job, and what it has achieved has a name: host-to-host delivery. The right bits are on the right machine.

That is not what any application asked for. The machine at 10.0.0.5 is running a web server, an SSH daemon, a DNS resolver and a hundred other processes, and nothing in the IP header says which of them this packet belongs to. Closing the gap between the right machine and the right program on that machine is process-to-process delivery, and it is the first and most basic thing the transport layer does. Everything else transport can offer you is optional. This part is not, which is why even UDP, which declines almost everything, still has ports.

The mechanism is one number. The transport layer puts its own header in front of the application data, and the first four bytes of that header, in both TCP and UDP, are two 16 bit fields: the source port and the destination port. A TCP header is 20 bytes when no options are set and can reach 60 bytes with them. A UDP header is 8 bytes and never changes size. In both, the two ports come first, and that ordering is not decoration: they are the first thing the receiving host needs to read.

Sixteen bits gives 2¹⁶ = 65,536 distinct values, numbered 0 to 65535. Say 65,536 values, or say the range 0 to 65535, and both are right. Saying “65,535 ports” is the small slip that gets picked up, and you get that many per transport protocol rather than in total, which section 03 comes back to.

Now the pairing. An IP address on its own identifies a machine. A port on its own identifies nothing at all, because port 80 exists on every machine on the Internet. Put them together and you have an endpoint that is unique in the world, 10.0.0.5:80, and that pair is a socket. Here is the refinement the rest of the lesson turns on: a socket is enough to name an endpoint, but it is not enough to name a conversation. Two clients talking to that same 10.0.0.5:80 are two different conversations, and the host has to keep them apart with something. That something is the other end of each one.

IP delivers to a host; a port number is the 16 bit field that turns that into delivery to a process. A socket is one IP address plus one port. A TCP connection is named by four numbers, source IP, source port, destination IP and destination port, and that is the entire reason one server port can hold ten thousand conversations at once without confusing any of them.

MultiplexingThe sending side. Many processes hand data down to one transport layer; it wraps each chunk in a header carrying that process’s source port and the destination’s port, and passes all of them to a single IP layer. Many streams in, one stream of packets out.

DemultiplexingThe receiving side, and the harder half. One stream of packets comes up from IP. The transport layer reads the port numbers off each one, and for TCP the source address and port as well, and drops the payload into the buffer of exactly one socket. One stream in, many processes out.

SocketAn endpoint: one IP address plus one port, written 10.0.0.5:80. Your program holds it as a file descriptor it reads and writes; on the wire it is only those two numbers, and the operating system keeps the table that maps between the two views.

02 Worked example

One click, from the source port to the right socket

This is the scene for the whole lesson. A laptop at 203.0.113.7 opens a page on a web server at 10.0.0.5. That server is also running sshd and a DNS resolver, so it holds five sockets in all, and it is the same host the console in section 04 runs. Read the five nodes left to right. The highlighted one is where the decision actually happens; the other four are setting it up.

The client picks a source portThe destination port is fixed at 80 by the URL. Nobody told the laptop what its own port should be, so its kernel takes a free number from the ephemeral range and returns 52310. The connection is now fully named: (203.0.113.7, 52310, 10.0.0.5, 80).

→

Multiplex on the way outTCP writes 52310 into the source port field and 80 into the destination port field, the first four bytes of a 20 byte header. IP wraps that with source 203.0.113.7 and destination 10.0.0.5. Twenty other processes are doing the same, and it all leaves as one stream.

→

IP stops at the machineEvery router on the path reads 10.0.0.5 and nothing else. The ports sit in the transport header, which a router never has to open. When the packet lands, the network layer is finished and the question of which process wants it has not been touched.

→

Demultiplex on all fourThree of the five sockets are on port 80: one listening, one established for this laptop and one established for a different client. The destination port narrows five to three and then stops helping. Compare all four numbers and exactly one established socket agrees on every one. Payload delivered there.

→

A second tab, nothing mixesThe same laptop opens the page again in a new tab. Same source IP, same destination IP, same destination port 80. Only the source port changes, to 52311, and it is enough: a fourth socket on port 80 appears, pinned to that four-tuple, and the two tabs never see each other’s bytes.

Count what changed between the fourth node and the fifth. Three of the four numbers were identical and one differed, and that one number is the whole difference between two mixed-up tabs and two clean conversations. State the argument in that form and it is hard to forget: the destination pair says which door, the source pair says which visitor, and a server needs both to answer the right person. A demultiplexer keyed on the destination pair alone would have dropped both tabs into one buffer, and the reply to the second request could be painted into the first tab.

The reply direction is worth a sentence, because it is the same mechanism with the fields swapped. When the server answers, its source becomes (10.0.0.5, 80) and its destination becomes (203.0.113.7, 52310). The laptop then runs the identical four-field lookup on the way in. Nothing about this is asymmetric, which is why the proper name for the four numbers is a socket pair: one socket at each end, and the connection is the pair.

One caution about the first node, because it is exactly the sort of detail an interviewer follows up on. IANA calls 49152 to 65535 the dynamic or private range, and that is the answer to give when asked where a source port comes from. Linux does not use it: the default value of net.ipv4.ip_local_port_range is 32768 60999, which dips well into the registered range. Windows has used the IANA range since Vista. Give the standard, then name the difference in one clause, and the follow-up question stops there.

03 Mechanics

The ranges, the ports, and the two demultiplexers

Four tables, in the order the questions arrive. First the three ranges. The boundaries are exact numbers and they get asked for as exact numbers, so the count column is there to be checked: the three add up to 65,536 or one of your boundaries is wrong.

Range	Numbers	How many	Who assigns them	Where you meet it
Well-known (system)	`0 to 1023`	`1,024`	IANA, through a standards process	The server side of every protocol in the next table. Binding one on Linux or macOS needs root, or the CAP_NET_BIND_SERVICE capability.
Registered (user)	`1024 to 49151`	`48,128`	IANA on request, but no privilege is needed to bind one	MySQL 3306, PostgreSQL 5432, Redis 6379, Tomcat 8080. Everything you run in a lab lives here.
Dynamic (private, ephemeral)	`49152 to 65535`	`16,384`	Nobody. The kernel picks a free one per outgoing connection	Your own source port, every time you open a connection. You never choose it and you rarely look at it.
The three must total the field width. 1,024 + 48,128 + 16,384 = 65,536, which is 2¹⁶. Count a range inclusively at both ends: 49151 − 1024 + 1 = 48,128. Dropping the + 1 is where the off-by-one comes from.

What the privilege on the first range is actually protecting. A well-known port carries an implied promise about what is listening there: connect to port 25 of a mail server and you expect SMTP. If any user on a shared machine could bind port 25, any user could impersonate that promise. So Unix systems refuse the bind below 1024 unless the process is root or holds CAP_NET_BIND_SERVICE. In production the three usual answers are to grant that one capability instead of running as root, to let systemd open the socket and pass the descriptor to an unprivileged process, or to listen on 8080 and put a reverse proxy in front.

Now the list. These are the ports a placement interview actually asks for, and the transport column is asked for as often as the number.

Port	Service	Transport	What to say about it
`20`	FTP data	TCP	Carries the file itself. In active mode the server opens this connection back towards the client.
`21`	FTP control	TCP	Commands and replies. Two ports for one protocol is why FTP gets asked about at all.
`22`	SSH	TCP	Also carries scp and sftp, so one port covers three tools.
`23`	Telnet	TCP	The same job as SSH with nothing encrypted. Name it as the thing SSH replaced.
`25`	SMTP	TCP	Relay between mail servers.
`53`	DNS	UDP and TCP	UDP for ordinary queries, TCP when the response will not fit or for a zone transfer. The only row here with two transports.
`67`	DHCP server	UDP	The server listens here.
`68`	DHCP client	UDP	The client listens here. Both ends are fixed because the client has no address yet and must broadcast.
`80`	HTTP	TCP	The default when a URL has no port.
`110`	POP3	TCP	Downloads mail and by default removes it from the server.
`143`	IMAP	TCP	Leaves mail on the server, which is why every phone uses it.
`443`	HTTPS	TCP	And UDP 443 for HTTP/3 over QUIC, which is the modern follow-up question.
`587`	SMTP submission	TCP	Client to server, authenticated. 25 is relay, 587 is submission, and swapping them is the trap.

Two rows worth one extra sentence each. DNS uses UDP because a query and its answer are one small exchange, and paying a handshake round trip to look up an address would double the cost of every page load. The classic limit is 512 bytes of DNS payload in a datagram; if the answer is larger, the server sets the truncated bit and the resolver asks again over TCP 53, and the EDNS0 extension raises that limit to negotiate larger datagrams instead. DHCP is stranger: the client has no IP address at the moment it asks for one, so it sends from 0.0.0.0:68 to the broadcast address 255.255.255.255:67. Both ports must be fixed and well-known because neither end can be told the other’s ephemeral port in advance.

This is the table the lesson is really about. Same job on both sides, and a genuinely different amount of work.

Demultiplexing	UDP	TCP
A socket is keyed on	`dest IP, dest port` — 2 fields	`src IP, src port, dest IP, dest port` — 4 fields
The source fields are	read, but not used to choose the socket. Handed to the application beside the payload	part of the key, and compared on every arriving segment
Two clients to the same server port	one socket, both datagrams land in it	two sockets, one per client
Sockets the server holds	one, for as long as the process runs	one listening socket plus one per live connection
API shape	socket, bind, then recvfrom in a loop	socket, bind, listen, then accept, which returns a new socket each time
Nothing bound on that port	`ICMP type 3 code 3, port unreachable`	`TCP RST segment`
Header cost	`8 bytes, fixed`	`20 bytes minimum, 60 with options`
Selected by	IPv4 protocol field `17`	IPv4 protocol field `6`

Listening sockets, and the 0.0.0.0 you keep seeing. A listening socket never carries data. It sits at a local address and port with a wildcard peer, written *:*, and its only job is to catch a SYN for a connection that does not exist yet; accept then hands you a brand new socket pinned to that one four-tuple, and every byte flows through the new one. The local half of a socket is an address and a port, not a port alone, and that has a consequence people meet the hard way. A server that binds 10.0.0.5:8080 has claimed that port on one interface only, so a second process can bind 192.168.1.9:8080 on another interface and both succeed. Bind 0.0.0.0:8080 instead and you are asking for that port on every interface at once, which is what most servers do by default and what ss prints as 0.0.0.0:8080 or *:8080.

Two separate port spaces, not one. TCP and UDP each get their own 65,536 numbers, because the IPv4 protocol field is consulted before the port table is. A process can hold TCP 53 while a completely different process holds UDP 53, and neither bind fails. That is not a corner case; it is exactly how a DNS server is normally deployed, and it is why “is port 53 free” is not a well-formed question until you say which protocol.

Last, what the transport layer is actually offering. Read this column by column rather than row by row: TCP is a bundle, and UDP is what is left when you decline the bundle.

Service	TCP	UDP	If you pick UDP, who does it
Process-to-process delivery	yes	yes	Neither can decline this. It is what a port is for.
Error detection over the payload	yes, checksum mandatory	checksum optional in IPv4, mandatory in IPv6	The application, or nobody.
Reliable delivery	yes, acknowledgements and retransmission	`no`	The application. A DNS resolver asks again after a timeout.
In-order delivery	yes, sequence numbers reorder the stream	`no`	The application. RTP carries its own sequence number for this.
Flow control	yes, the receive window	`no`	Nobody. A fast sender can drown a slow receiver.
Congestion control	yes	`no`	The application. QUIC implements it in user space over UDP.
Connection setup cost	a three-way handshake, one round trip before any data	none, the first datagram carries data	—

A menu, not a mandate. The rows above are services the transport layer offers, and the interesting thing about UDP is not that it lacks them but that declining them is a design decision somebody made on purpose. Live audio does not want retransmission, because a frame that arrives 200 milliseconds late is useless however perfectly it arrives, and worse, TCP would hold every later frame behind it while it recovered the lost one. A DNS query does not want a handshake, because the handshake would cost more than the query. So the honest summary of the whole layer is this: process-to-process delivery is compulsory, everything else is a menu, and UDP is the order that takes the first item and nothing else.

05 Cheat sheet

The numbers to have ready

Every row is something you can be asked to state in under ten seconds. The right-hand column is the specific wrong answer that gets given, not a general caution.

What they ask	The answer	The trap
Width of the port field	`16 bits, 65,536 values, 0 to 65535`	`saying 65,535 ports` — and forgetting it is per protocol
Well-known range	`0 to 1023, which is 1,024 numbers`	Saying 1 to 1024. Binding one on Unix needs root or CAP_NET_BIND_SERVICE.
Registered range	`1024 to 49151, which is 48,128 numbers`	Claiming it runs to 65535, which erases the third range entirely.
Dynamic or ephemeral range	`49152 to 65535, which is 16,384 numbers`	`quoting IANA as what Linux does` — its default is 32768 to 60999
What a socket is	`one IP address plus one port, 10.0.0.5:80`	`calling the four-tuple a socket` — that is a socket pair, which is a connection
What names a TCP connection	`src IP, src port, dest IP, dest port`	Giving two fields, which merges every client on one server port into one stream.
What UDP demultiplexes on	`destination IP and destination port`	`claiming UDP uses the four-tuple too` — it has no connections to separate
TCP segment to a closed port	`a RST segment`	Saying ICMP. A firewall dropping it silently is a third outcome and not the protocol’s.
UDP datagram to a closed port	`ICMP type 3 code 3, port unreachable`	Saying RST. UDP has no connections, so it has no reset.
Header sizes	`TCP 20 bytes min, 60 with options; UDP 8 fixed`	Quoting the TCP header as a flat 20. It is a minimum.
TCP 80 and UDP 80	`two different sockets, two separate port spaces`	`one shared table of 65,536 ports per machine`
The ports to memorise	`20 21 22 23 25 53 67 68 80 110 143 443 587`	`25 versus 587` — 25 is relay between servers, 587 is authenticated submission

The two numbers live in two headersThe port is in the transport header and the address is in the IP header, so naming a socket takes fields from two layers. That is why a router can forward without ever opening a transport header, and why a firewall or a NAT box is reaching above its own layer the moment it looks at a port.

One listening socket, many connection socketsThe listener sits at a local address and port with a wildcard peer and never carries data. accept returns a new socket pinned to one four-tuple, and that is the socket the bytes flow through. A server holding ten thousand connections holds ten thousand and one sockets on one port.

The limit is on the client, not the serverA server’s port is one number and it never runs out of them. What runs out is the pool of source ports a single client, or a NAT box standing in for many clients, can put in front of it, and that is where the real ceiling on simultaneous connections sits.

06 Where & why

Where these numbers show up on a real machine

None of this is a teaching abstraction. Each of these four is a socket table with a local pair, a remote pair, a rule for choosing a row, and a fixed answer when no row matches. Two of them differ from the textbook in a way worth naming out loud.

Linux · ss

The four-tuple printed one row at a time

ss -tan prints one line per TCP socket with the local address and the peer address side by side, which is the four-tuple with the fields in that order. A LISTEN row shows a peer of *:*, meaning any remote endpoint; an ESTAB row shows a real one. Run it with a browser open and you will see several rows sharing one server address and differing only in the client port. The ephemeral ports it draws from are set by net.ipv4.ip_local_port_range, whose default is 32768 60999 and not the IANA 49152 to 65535.

OpenSSH

Why the config file has a Port line at all

sshd binds TCP 22, which is inside the privileged range, so it starts as root and drops privileges afterwards. Changing Port 22 to Port 2222 in sshd_config moves it into the registered range where an unprivileged user can bind it, and every client then has to be told with ssh -p 2222, because nothing in the protocol advertises the move. That trade, one privileged default against one extra argument forever, is the well-known range doing exactly its job.

nginx

One listening socket, tens of thousands of connection sockets

A worker holds one listening socket on port 443 and one further socket per live connection, all sharing that same local pair and differing only in the remote half. worker_connections caps how many it will keep, and the operating system open-file limit caps it again, because every socket is a file descriptor. When several workers need to accept in parallel they use SO_REUSEPORT to each hold their own listening socket on the same port, and the kernel spreads arriving connections across them by hashing the four-tuple.

Google Public DNS 8.8.8.8

One UDP socket, the whole world

A resolver at 8.8.8.8:53 is reached over UDP by clients that have no connection to it and never had one. Every query lands in the same socket, and the server learns who sent it from the sender address delivered beside the payload, which it then uses as the destination of the reply. The same address answers on TCP 53 when a response will not fit in one datagram, and on TCP 443 for DNS over HTTPS, which exists largely to get through networks that filter port 53.

When you meet a networking problem in a job, the first genuinely useful thing you can do is print the socket table and ask which row the traffic should have hit. Almost every “the service is not responding” ticket resolves to one of three answers: nothing is bound to that port, something is bound but only on one address, or it is bound on the other transport protocol.

07 Interview questions

What they ask, and what they follow up with

This topic is asked early in an interview because it is cheap to check and expensive to fake. The pattern is that a definition question is followed immediately by a number question, so give the boundary values without being asked for them; that one habit does more for you here than any amount of extra theory.

What does the transport layer give you that the network layer cannot?

Process-to-process delivery. IP gives you host-to-host delivery: every router on the path reads the destination IP address and nothing else, so when the packet lands the right bits are on the right machine and nobody knows which of its hundred processes wants them. The transport layer adds a header whose first two fields are a source port and a destination port, and those 16 bit numbers name the program. Everything else transport offers is optional, which is why even UDP, which declines almost all of it, still carries ports.

What exactly is a port number, and how many are there?

It is a 16 bit field in the transport header, so there are 2¹⁶ = 65,536 of them, numbered 0 through 65535. It sits in the transport header and not the IP header, which is why a router never has to open it and why a firewall filtering on ports is doing strictly more work than a router does. Say 65,536 values or say the range 0 to 65535; answering “65,535 ports” is the small slip that gets noticed.

Give me the three port ranges with their boundaries.

Well-known or system ports are 0 to 1023, which is 1,024 numbers, assigned by IANA and privileged to bind on Unix. Registered or user ports are 1024 to 49151, which is 48,128 numbers, handed out by IANA on request but bindable by anyone. Dynamic, private or ephemeral ports are 49152 to 65535, which is 16,384 numbers that nobody assigns because the kernel picks one per outgoing connection. They add to 65,536, and that sum is the check. One caveat worth volunteering unprompted: Linux does not use the IANA ephemeral range by default, it uses 32768 to 60999.

What is a socket, and is a socket the same thing as a connection?

A socket is an endpoint: one IP address and one port, written 10.0.0.5:80. A connection is not one socket, it is a pair of them, and TCP names it by all four numbers, source IP, source port, destination IP and destination port. That distinction is the point of the whole topic: a server holds one listening socket at 10.0.0.5:80 and one further socket per live connection, all sharing that local pair and differing only in the remote half. There is a third meaning too, since in the Berkeley API you hold a socket as a file descriptor, and separating the three out loud is worth doing.

Two browser tabs are open on the same website. Why do the responses not get mixed up?

Because the two connections have different four-tuples. Both tabs share a source IP, a destination IP and destination port 80, but the client kernel picks a fresh ephemeral source port for the second one, so the keys differ in exactly one field. The server holds two separate connection sockets and demultiplexes every arriving segment on all four fields, and the client does the same on the replies. If either side keyed only on the destination pair, both tabs would land in one buffer and the answer to one request could be painted into the other tab.

How is UDP demultiplexing different from TCP demultiplexing?

UDP keys a socket on the destination IP and destination port only, so two datagrams from two different clients addressed to the same server port land in the same socket, and the application separates them using the sender address that recvfrom hands it beside the payload. TCP keys on all four fields, so those same two datagrams as segments would go to two different sockets. The reason for the difference is that UDP has no connections to keep apart: a UDP server usually holds exactly one socket for its whole life, while a TCP server holds one listening socket plus one per live connection.

A segment arrives for a port with nothing bound. What happens?

For TCP the host replies with a RST segment, and that is what surfaces in an application as connection refused. For UDP there is no RST, because a reset is a connection idea and UDP has no connections, so the host sends back an ICMP Destination Unreachable message, type 3 with code 3, port unreachable. Both tell the sender immediately. In practice a firewall often drops the segment silently instead, which is why a blocked port hangs and a closed port fails fast, and that difference is exactly what a port scanner is reading.

Why does binding to port 80 need root?

Because 0 to 1023 are privileged on Unix systems: the kernel refuses the bind unless the process is root or holds CAP_NET_BIND_SERVICE. The reasoning still holds, that a well-known port carries an implied promise about what is listening there, so an ordinary user should not be able to put a fake SMTP server on port 25 of a shared machine. The usual production answers are to grant only that capability rather than run as root, to let systemd open the socket and pass the descriptor to an unprivileged process, or to listen on 8080 and put a reverse proxy in front.

Where in the packet are the port numbers, and why does the answer matter?

The ports are in the transport header and the IP addresses are in the IP header above it, so identifying a socket takes fields from two different layers. That is why a router can forward a packet without ever parsing a transport header, and why any device that does look at ports, a firewall or a NAT box, is reaching above its own layer to do it. It also explains a detail people find odd: the TCP and UDP checksums cover a pseudo-header containing the IP addresses and the protocol number, because the transport layer needs to be sure the segment reached the right port on the right host and not the right port on the wrong one.

Define multiplexing and demultiplexing in one sentence each.

Hard

Two laptops behind one home router, 192.168.1.10 and 192.168.1.11, each open a connection to 203.0.113.10:443, and both kernels happen to pick source port 52000. The router has a single public address, 198.51.100.9. Give the four-tuple of each connection as the laptops see it, the four-tuple the server sees, and the translation table the router must hold so that replies reach the right laptop.

Follow-up

The server has to see two connections that differ from each other, and the only field the router is free to change is one it does not own. Work out what the server would do if the router changed nothing, and you have the reason a box that calls itself a router has to read a transport header at all.

Show the hint

Write the four numbers of each connection as a column, once before the router and once after it, and find the entry that would otherwise be identical in both rows.