October 19, 2001, 11:00 AM — Networking has become key to many business
processes. Keeping that network running smoothly falls into the domain
of mission-critical functions. Now that the Internet has exploded onto
the front pages of USA Today and has references sprinkled
through the Wall Street Journal, the amount of work created
for system administrators who run sites, fix configuration problems,
and resolve user complaints has also increased in magnitude.
This month, we're going to look at the business of making connections
between TCP/IP end-points. It's a small subset of the broader
network-administration problems of performance, security, and
controlled-growth management, but it's also the most fundamental. If
you can't get connected or you can't keep unwanted network entities
from connecting to you, then the big picture gets obscured by the pile
of complaints reading "the network is down."
Making TCP/IP connections appears to be fairly simple: You identify
the other host, specify a service you want to use, and blast data down
the wire, hoping that you'll enjoy some semblance of good performance
and reliable security all the while. Meeting those expectations is
what makes TCP/IP connection management an interesting problem. We'll
review the mechanics of TCP/IP connections and service location and
go through the details of linking two end-points over a socket.
Junction introduction: Getting linked
The first requirement for establishing a TCP/IP connection is the name
of the other end. That name consists of two parts: the remote IP
address and a port number. IP addresses are obtained through the Domain
Name Service (DNS), Network Information Service (NIS), or the local
/etc/hosts file, all of which map hostnames to IP addresses.
The port number is a bit trickier because it depends on the service
being used. Each host numbers ports starting at 1, with a separate set
of ports for TCP and the User Datagram Protocol (UDP). Since each IP
packet contains information about the higher-level protocol it is
carrying, the two port sets cannot be confused. Port numbers below 1024
are known as reserved ports and can be opened only by
processes running as root; port numbers 1024 and above are
unrestricted.
One way a budding TCP/IP connection determines the remote port
number is to look in the /etc/services file (or the
services.byname NIS database). This file correlates the
well-known name of a service, the port number, and the protocol used
for that service. Not every service is listed in
/etc/services, since some connections are made to well-known
(or hard-coded) port numbers. The X Window System, for example, uses
port 6000 for its default window server. If you see cryptic port
numbers floating around your network, use RFC
1340 to decipher them. This list of well-known port numbers will
tell, for example, that port 119 is used for the Server Message Block
(SMB) protocol of Lan Manager, even though this doesn't appear in most
/etc/services files.
Every TCP/IP connection is uniquely identified by the local and
remote IP addresses and the local and remote port numbers. Let's say
you have five ftp sessions going at once, all connected to port 21 on
your public ftp server from your desktop. How are the five
distinguished, since they all connect to the same remote IP address and
port number? The differentiator is the local port number, which is
assigned by the local TCP/IP stack when the connection is made.
To get a list of active TCP/IP connections, use netstat:
-a
