Your computer runs many programs that use the network at once. Every arriving segment has to reach exactly one of them, and that is the job of the two port numbers in its header.
Words you will meet
- Demultiplexing — reading an arriving segment’s header to decide which socket in this host it belongs to.
- Multiplexing — collecting data from many sockets and putting it into segments on one link.
- Port number — a 16-bit number naming a socket within a host.
- Well-known port number — a port below 1024, reserved by agreement for one particular kind of server.
- Four-tuple — the four values that name one TCP (Transmission Control Protocol) Transmission Control Protocol The Internet transport protocol that delivers data reliably and in order, with flow control and congestion control. introduced in ch. 1 socket: both addresses and both port numbers.
Why this matters
Section 3.1 said the transport layer’s one irreducible job is turning host-to-host delivery into process-to-process delivery. This is that job, in full. It is the only thing UDP (User Datagram Protocol) User Datagram Protocol A simple transport protocol with no reliability, no flow control and no congestion control. introduced in ch. 1 does beyond error checking, and it is the foundation everything TCP (Transmission Control Protocol) Transmission Control Protocol The Internet transport protocol that delivers data reliably and in order, with flow control and congestion control. introduced in ch. 1 adds is built on.
It also explains a surprising number of practical things. Why can a web server serve thousands of people through one port? Why can two computers pick the same port number without anyone minding? And how does a port scanner work out what software you are running?
Four programs, one Internet connection
Suppose you are sitting at your computer downloading web pages, while also running one FTP (File Transfer Protocol) File Transfer Protocol An application-layer protocol for transferring files between two hosts. introduced in ch. 1 session and two Telnet sessions. That is four network application processes at once — two Telnet, one FTP, one HTTP (HyperText Transfer Protocol) HyperText Transfer Protocol The application-layer protocol that requests and transfers Web documents. introduced in ch. 1 . Segments are arriving from the network layer continuously, and each one belongs to exactly one of those four.
Recall from section 2.7 that a process can have one or more sockets, the doors through which data passes between the network and the process. The transport layer does not deliver data to a process directly. It delivers to a socket. And because a host can have many sockets open at once, every socket needs a unique identifier.
The two halves of the job
Demultiplexing transport-layer demultiplexing Simple Reading a segment’s header to decide which socket in this host it belongs to. Precise The job, at the receiving host, of delivering the data in a transport-layer segment to the correct socket. The transport layer examines the fields that identify the socket — the destination port for UDP, all four of the four-tuple for TCP — and directs the segment there. introduced in ch. 3 — open in glossary is delivering the data in an arriving segment to the correct socket.
Multiplexing transport-layer multiplexing Simple Collecting data from many sockets in one host and putting it all into segments on one link. Precise The job, at the sending host, of gathering data chunks from different sockets, adding a header to each chunk (source and destination port numbers, plus error-detection bits) to form segments, and passing the segments to the network layer. Its counterpart at the receiving host is demultiplexing. introduced in ch. 3 — open in glossary is the reverse. The transport layer gathers data chunks from the different sockets on a host, wraps each chunk in a header, and passes the resulting segments to the network layer. That header is what lets the far end demultiplex.
They are not two mechanisms. They are one mechanism seen from its two ends — and the header written by one is the header read by the other.
Process P1 and process P2 are both running. Neither can receive anything directly: data reaches a process only through a socket, which is the door between the application layer and the transport layer.
The middle host is running two processes. Step through the decision it has to make on every segment that arrives.
Read all steps as text
- 1 — Two processes, each with a socket — Process P1 and process P2 are both running. Neither can receive anything directly: data reaches a process only through a socket, which is the door between the application layer and the transport layer.
- 2 — A segment arrives from the network layer below — The network layer pulls the segment out of the datagram and hands it up. At this instant the transport layer knows the bytes but not yet who they are for.
- 3 — The transport layer reads the header fields — It looks at the fields that identify the socket. For UDP that is the destination port alone. For TCP it is all four of the source IP address, source port, destination IP address and destination port.
- 4 — Demultiplexing: the data goes to P2’s socket — The segment’s data passes through that socket and into the process. This job — delivering the data in a segment to the correct socket — is demultiplexing.
- 5 — Multiplexing is the same job, backwards — Going the other way, the transport layer collects chunks from both sockets, puts a header on each one to make a segment, and hands the segments down to the network layer. The header it adds is what lets the far end demultiplex.
Everyday picture
The two households again. When Bill receives a batch of post from the mail carrier, he reads who each letter is addressed to and hands it to the right brother or sister. That is demultiplexing.
When Ann collects letters from her brothers and sisters and gives the whole bundle to the mail carrier, that is multiplexing.
Where the picture breaks: Bill reads a name written on the envelope by the sender, in the sender’s handwriting. A destination port number is not written by the sending application at all. The sending transport layer puts it in the header, and the application usually never sees it.
In plain words
This problem is not special to the Internet, and not special to the transport layer. Whenever one protocol at one layer is used by several protocols at the layer above, somebody has to decide which of them an arriving thing belongs to. You will meet the same problem at the network layer in chapter 4 and at the link layer in chapter 6. It is solved the same way each time: a field in the header that names the layer above.
The two fields that make it work
Multiplexing needs two things: sockets must have unique identifiers, and every segment must carry fields that indicate which socket it is for. Those fields are the source port number and the destination port number.
Click any box to read what that part of the message is for.
Every field, as text
- Source port # — 16 bits — the return address (example: 19157)
- Dest. port # — 16 bits — which socket on the receiving host (example: 46428)
Both UDP and TCP have more fields than this, and the next two sections show them. These two are the ones without which no transport protocol can work at all.
Each port number is 16 bits, so the range runs from 0 to 65535. The numbers from 0 to 1023 are well-known port numbers well-known port number Simple A port number below 1024, reserved by agreement for one particular kind of server. Precise A port number in the range 0 to 1023, restricted for use by well-known application protocols such as HTTP (80) and FTP (21). The list is in RFC 1700 and is kept up to date by IANA [RFC 3232]. A new application must be given a port number outside this range. introduced in ch. 3 — open in glossary and are restricted: they are reserved for well-known application protocols. HTTP uses 80 and FTP uses 21. The list is given in RFC (Request For Comments) Request For Comments The name of an IETF standards document. There are currently nearly 9000 of them. introduced in ch. 1 1700 and is kept up to date by IANA (Internet Assigned Numbers Authority) Internet Assigned Numbers Authority Coordinates the DNS root servers and publishes the well-known port numbers. introduced in ch. 2 [RFC 3232]. When you write a new application, you must give it a port number — and it must not be one of these.
So the demultiplexing service could work like this. Give each socket in the host a port number. When a segment arrives, read its destination port and hand the segment to the socket with that number.
That is basically how UDP does it. TCP is more subtle, and the difference between the two is the rest of this section.
Connectionless multiplexing and demultiplexing
A Python program creates a UDP socket with the line from section 2.7.1:
clientSocket = socket(AF_INET, SOCK_DGRAM)When a socket is created this way, the transport layer automatically assigns a port number. It picks some number in the range 1024 to 65535 that no other UDP socket on this host is using. If you want a particular number instead, you ask for it:
clientSocket.bind(('', 19157))A server implementing a well-known protocol must bind the corresponding well-known port. Typically the server side assigns a specific port and the client side lets the transport layer choose, transparently.
A UDP socket is named by two values, not four
A UDP socket is fully identified by a two-tuple: a destination IP (Internet Protocol) Internet Protocol The network-layer protocol that defines the datagram format and addressing every Internet device must use. introduced in ch. 1 address and a destination port number.
The consequence is worth stating on its own. Two UDP segments may have different source IP addresses or different source port numbers. If their destination IP address and destination port number are the same, they are directed to the same socket — and therefore to the same process.
That is why a single DNS (Domain Name System) Domain Name System Translates a human-friendly name such as www.ietf.org into a network address. introduced in ch. 1 server can answer the whole Internet through one socket on port 53, and why it needs no memory of who is talking to it.
Suppose a process on host A with UDP port 19157 wants to send data to a process on host B with UDP port 46428. A’s transport layer builds a segment containing the data, the source port 19157, the destination port 46428, and two other fields that section 3.3 will explain. It hands the segment to the network layer, which puts it in a datagram and makes a best-effort attempt to deliver it. If it arrives, B’s transport layer reads the destination port and delivers the data to the socket bound to 46428.
So what is the source port for?
Nothing in that walkthrough used it. It is the return address.
Click any arrow to see what that message says and why it is sent.
This is the whole reason a segment carries a source port at all. Click an arrow for the header the segment actually has.
Read this diagram as text
- Host A sends source port 19157 → dest. port 46428 to Server B. The destination port is how B’s transport layer finds the right socket. The source port is not used for that at all — it is carried so that B knows where to send an answer.
- Server B sends source port 46428 → dest. port 19157 to Host A. B takes the source port out of the segment it received and writes it into the destination field of its reply. In the chapter-2 UDP server this is literally what the code does: recvfrom() hands the server the client’s address and port, and the server sends its answer straight back to them.
Lifelines, left to right: Host A (host), Server B (server).
When B wants to reply, the destination port of its reply takes its value from the
source port of the segment it received. The complete return address is A’s IP
address plus that source port. In the chapter-2 UDP server this is not an
abstraction but a line of code. recvfrom() hands the server the data together
with the client’s address and port. The server then addresses its reply to
exactly those.
Connection-oriented multiplexing and demultiplexing
TCP is different in one respect, and everything else follows from it.
A TCP socket is identified by a four-tuple four-tuple Simple The four values that name one TCP socket: both addresses and both port numbers. Precise The set (source IP address, source port number, destination IP address, destination port number) that identifies a TCP socket. All four values are used to demultiplex an arriving TCP segment, which is why two connections to the same server port from different clients — or even from the same client on different ports — reach different sockets. A UDP socket, by contrast, is named by only two values: the destination IP address and destination port. introduced in ch. 3 — open in glossary : source IP address, source port number, destination IP address, destination port number. When a TCP segment arrives, the host uses all four values to direct it to a socket.
In contrast with UDP, two arriving TCP segments with different source IP addresses or different source ports will be directed to two different sockets. There is one exception: the segment that carries the original connection-establishment request, which has nowhere else to go yet.
How a connection socket comes into existence
Take the chapter-2 TCP client and server, exactly as they were written in section 2.7.2:
-
The server application has a welcoming socket that waits for connection-establishment requests on port 12000.
-
The client creates a socket and asks to connect:
clientSocket = socket(AF_INET, SOCK_STREAM) clientSocket.connect((serverName, 12000)) -
A connection-establishment request is nothing more than a TCP segment with destination port 12000 and a special bit set in its header. That is the SYN (synchronize) synchronize The TCP flag bit that marks a connection-establishment segment. Set in the first two segments of the three-way handshake (§3.5.6). introduced in ch. 3 bit, which section 3.5.6 covers properly. The segment also carries a source port the client chose.
-
When the server’s operating system receives that segment, it finds the process waiting to accept connections on port 12000, and that process creates a new socket:
connectionSocket, addr = serverSocket.accept() -
The server’s transport layer notes four values from the request segment: the source port, the source host’s IP address, the destination port, and its own IP address. The new connection socket is identified by those four values, and every later segment matching them is demultiplexed to it.
A server host may have many simultaneous connection sockets, each attached to a process and each named by its own four-tuple.
Two clients, one port
Here is the situation the four-tuple exists to handle. Host C opens two HTTP sessions to server B, and host A opens one. C picks source ports 7532 and 26145 for its two connections. A, choosing independently and with no knowledge of C, also picks 26145.
| Source IP | Source port | Dest. IP | Dest. port | |
|---|---|---|---|---|
| Rows 2 and 3 share a source port. Server B still demultiplexes them correctly, because a TCP socket is named by all four values and the source IP addresses differ. | ||||
Cells marked ⓘ have an explanation — click to read it. Sortable columns have a ↕ in the heading.
Every row has destination port 80. Look at the last two rows: same source port, and still no ambiguity. Click a cell for why.
This is not a problem. B compares four values, and although the two connections share a source port, their source IP addresses differ — so the four-tuples differ and each segment reaches the right socket.
| UDP socketconnectionless | TCP socketconnection-oriented | |
|---|---|---|
| Identified by | ||
| Two segments, same destination pair, different senders | ||
| A server talking to 1,000 clients needs | ||
| How a reply is addressed |
Cells marked ⓘ have a reason behind them — click to read it.
One row explains almost everything else in this section. Click a cell for the consequence.
Web servers and TCP
A last practical note, because it explains something about the web.
Consider a host running a web server, such as Apache, on port 80. Every segment clients send it carries destination port 80 — the initial connection-establishment segments and the segments carrying HTTP requests alike. The server tells its clients apart using their source IP addresses and source ports, exactly as above.
The picture in Figure 3.5 shows the server creating a new process for each connection, and each process owning its connection socket. That is not always how it works. Today’s high-performing web servers often use a single process and create a new thread — a lightweight subprocess — with a new connection socket for each client. If you built the web server in chapter 2’s first programming assignment, you built one of these. Such a server has many connection sockets, with different identifiers, attached to one process.
This is the other cost of non-persistent HTTP
Section 2.2.2 measured non-persistent HTTP in round trips and found it expensive. Here is the second bill.
With persistent HTTP, the client and server exchange every message for the whole connection through the same socket.
With non-persistent HTTP, a new TCP connection is created and closed for every request and response — so a new socket is created and closed for every request and response. On a busy web server that constant churn can severely hurt performance, though operating systems have tricks to soften it.
Focus on security — port scanning
A server process waits patiently on an open port for a client to make contact. Some ports are reserved for well-known applications; others are used by convention by popular ones, such as Microsoft’s SQL Server, which listens on UDP (User Datagram Protocol) User Datagram Protocol A simple transport protocol with no reliability, no flow control and no congestion control. introduced in ch. 1 port 1434. So if you can determine that a port is open on a host, you can often work out which application is running there.
That is genuinely useful to a system administrator, who needs to know what is running on the machines they look after. It is equally useful to an attacker casing a target. If a host is running software with a known flaw, that host is ripe for attack. The SQL Server on port 1434 was once subject to a buffer overflow that let a remote user run code. The Slammer worm exploited exactly that [CERT 2003-04].
Finding out is easy. Programs that do it are called port scanners port scanning Simple Knocking on a host’s ports one by one to see which ones answer. Precise Probing a target host’s ports in sequence to learn which applications are listening. For TCP a scanner sends a SYN segment and reads the reply: a SYNACK means open, an RST means closed, silence usually means a firewall dropped it. The best-known scanner is nmap. System administrators and attackers use the same tool for opposite reasons. introduced in ch. 3 — open in glossary , and the best known is nmap, freely available and included in most Linux distributions. For TCP it scans ports in turn, looking for ones that accept connections; for UDP it looks for ports that answer. Either way it returns a list of open, closed and unreachable ports, and it can be pointed at any host anywhere on the Internet.
Section 3.5.6 returns to nmap once you know how TCP connection management works, and explains how it distinguishes those three answers.
Check yourself
Check yourself
0 of 5 answered1.Two UDP segments arrive at host C. Both carry destination port 6789, but one came from host A and the other from host B. Where does each go?
Count how many values name a UDP socket.
2.Host A and host C each open an HTTP connection to server B, and both happen to pick source port 26145. Is this a problem for B?
3.What is a well-known port number?
4.predictIn the port-inversion ladder, the reply from server B carries source port 46428 and destination port 19157. Why those two numbers in that order?
5.A busy web server switches from persistent HTTP to non-persistent HTTP. What happens to its sockets?
Section 2.2.2 said what a non-persistent connection costs in round trips. This is the other cost.
What to remember
- Demultiplexing delivers an arriving segment’s data to the right socket. Multiplexing gathers data from many sockets into segments. One mechanism, two directions.
- A UDP socket is named by a two-tuple, so segments from different senders to the same pair reach the same socket. A TCP socket is named by a four-tuple, so they reach different sockets.
- The source port is the return address. A UDP server builds its reply’s destination out of the source port of the segment it received.