Chapter 2 ■ UDp
18
Port Numbers
The problem of distinguishing among many signals that are sharing the same channel is a general one, in both computer
networking and electromagnetic signal theory. A solution that allows several conversations to share a medium or
mechanism is known as a multiplexing scheme. It was famously discovered that radio signals can be separated from
one another by using distinct frequencies. In the digital realm of packets, the designers of UDP chose to distinguish
different conversations using the rough-and-ready technique of labeling each and every UDP packet with a pair of
unsigned 16-bit port numbers in the range of 0 to 65,536. The source port identifies the particular process or program
that sent the packet from the source machine, while the destination port specifies the application at the destination IP
address to which the communication should be delivered.
At the IP network layer, all that is visible are packets winging their way toward a particular host.
Source IP ® Destination IP
But the network stacks of the two communicating machines—which must, after all, corral and wrangle so many
separate applications that might be talking—see the conversation as much more specifically being between an IP
address and port number pair on each machine.
Source (IP : port number) ® Destination (IP : port number)
The incoming packets belonging to a particular conversation will always have the same four values for these
coordinates, and the replies going the other way will simply have the two IP numbers and two port numbers swapped
in their source and destination fields.
To make this idea concrete, imagine you set up a DNS server (Chapter 4) on one of your machines with the
IP address 192.168.1.9. To allow other computers to find the service, the server will ask the operating system for
permission to receive packets arriving at the UDP port with the standard DNS port number: port 53. Assuming that a
process is not already running that has claimed that port number, the DNS server will be granted that port.
Next, imagine that a client machine with the IP address 192.168.1.30 wants to issue a query to the server. It
will craft a request in memory and then ask the operating system to send that block of data as a UDP packet. Since
there will need to be some way to identify the client when the packet returns and since the client has not explicitly
requested a port number, the operating system assigns it a random one—say, port 44137.
The packet will therefore wing its way toward port 53 with addresses that look like this:
Source (192.168.1.30:44137) ® Destination (192.168.1.9:53)
Once it has formulated a response, the DNS server will ask the operating system to send a UDP packet in
response that has these two addresses flipped around the other way so that the reply returns directly to the sender.
Source (192.168.1.9:53) ® Destination (192.168.1.30:44137)
Thus, the UDP scheme is really quite simple; only an IP address and port are necessary to direct a packet to its
destination.
But how can a client program learn the port number to which it should connect? There are three general approaches.
• Convention: The Internet Assigned Numbers Authority (IANA) has designated many port
numbers as the official, well-known ports for specific services. That is why DNS was expected
at UDP port 53 in the foregoing example.• Automatic configuration: Often the IP addresses of critical services such as DNS are learned
when a computer first connects to a network, using a protocol such as DHCP. By combining
these IP addresses with well-known port numbers, programs can reach these essential
services.