October 31, 2001, 11:01 AM — Rob Kolstad, long-time USENIX executive and noted
industry personality, often points out that a good system
administrator is a master of change on many time scales. That
statement is most appropriate in the context of last month's topic,
managing TCP/IP connections. New services appear monthly, new host
entries pop up daily or every few hours, and you can get hit with a
routing table update at least every 30 seconds. The number of moving
parts conspires to keep at least some things broken, some of the time.
Last month we talked about the myriad configuration problems that
interfere early in the process of making a connection. This
month, we'll proceed with our discussion of TCP/IP mechanics by
covering performance and security concerns.
After identifying the remote system's IP address and desired service
port number, the rest of the connection process should be as simple as
knocking on a door when you know the street address and floor number
on which it's located. Nothing in life, electronic or carbon, is that
simple. The door-knocking analogy highlights most of the additional
things that can go wrong in TCP-land: nobody answers the remote door
(performance problem), you are deemed persona non grata and
are turned away at your destination, or you run into troubles getting
out of your own building. To start our journey, we'll look at server
performance limits that create connection bottlenecks, and then
explore the popular TCP wrapper package used to establish access
controls over network services. We'll conclude with an overview of the
SOCKS tools that let you enjoy the security of a well-locked door but
still sneak out for an occasional network snack.
Connection erection
Just because you can name the remote end of a socket with an IP
address and port number pair doesn't mean the other side can or even
wants to talk to you. Making yourself appear interesting (and trusted)
is a security problem we'll cover shortly. Making sure your servers
have sufficient connection management resources is a growing
performance problem. As the use of network services has exploded, many
years-old assumptions about resource allocation have proven far too
restrictive.
A server-side process prepares to accept socket connections by
first calling listen() and then accept().
The first call determines the depth of the incoming connection queue,
while the second call is what actually puts the socket into a
receive-ready state. In the days of pre-Internet boom the default
value of five pending connections was frequently hard-coded in the
implementation of listen(). Current socket interface
code, however, interprets the argument and sets the queue depth. When
the socket in question is owned by httpd, or any other
process that receives a high volume of connection requests, the queue
depth is a critical performance limit.
An embryonic socket connection goes through a three-way handshake
between client and server. The connection stays on the incoming
connection queue until the handshake has been completed. Knowing the
steps involved will help you determine just how long the average
connection dance will take.
- The connecting side (client), sends a connection request to the
server, asking it to synchronize a connection (a so-called SYN packet).
- If there's room in the queue, the server accepts the request, and
returns an acknowledgement with its first sequence number.
- The client acknowledges the server's initial sequence number, and
the connection is established.
The connection remains in the queue for the duration of the last two
packet exchanges, or the total of the round-trip network transfer time
between client and server, plus the time required for the client to
process the server's initial packet.
Once the connection queue is full, further attempts to connect to
the socket are discarded. If you find connections are refused, or if
your browser is complaining that it can't open a URL because the
server isn't responding, you're probably bumping into the backlog
limit.
