May 08, 2001, 9:46 AM —
Q: How can I figure out what's really happening to TCP/IP so I can tell
what needs to be tuned on my Web server?
A: I've been using a really
cool tool as my secret weapon for some time, now it is available as
a free download, and I'll illustrate how it can be used to see
things that you can't figure out from a snoop listing or packet
analyzer.
Steve Parker created this tool a year or two ago and has recently
made it available for download over the Internet. The basic tool is
a language called the packet shell (psh) which understands protocols
like TCP/IP over Ethernet. Coupled with the Tcl/Tk toolkit and a
simple X-based plotting utility a GUI-based tool can be constructed.
The tool provided is called tcp.analysis. It reads a snoop file,
sorts the packets into TCP sequences, and lets you pick one to
graph.
A screenshot is shown below. The data shown on each line starts with the
source IP address and port number, then the destination IP address and
port number. The total number of bytes in the sequence and the number of
segments (Ethernet packets) is followed by the TCP sequence numbers and
any flags seen in the sequence. If there is a SYN, then you have captured
the start of a sequence in the snoop file.
Collecting a snoop sequence
You must have superuser permissions to run snoop. You should also be
careful about the security of traffic on your network -- and don't
provide read permission for others on collected snoop files. You can
cut down the size of a snoop file by truncating saved packets to 128
bytes. This captures most higher-level protocol headers (like HTTP
and NFS). If you just want the TCP header truncate to 54 bytes. The
tcp.analysis tool slows down if there are too many packets in the
file. I would suggest 1000 packets on a lightly loaded network, and
no more than 10000 on a busy one. If possible collect using a
separate system, which has no traffic of its own to get in the way
and no other jobs running to steal CPU time. If you have to, it is
all right to collect on an active server as long as there is some
spare CPU time. If the collecting system is too busy, you may drop
some packets.
You must also avoid generating more packets with snoop. Don't write
the output file over NFS or run snoop from an rlogin session over the
same network without redirecting the stderr output to /dev/null.
I always write the output to /tmp, as it is memory based. You can either
monitor every packet that goes by, or use snoop's filtering capabilities
to look for a particular host or protocol. While it is running, snoop
counts out the packets to stderr.
# snoop -s 128 -c 1000 -o /tmp/test.snoop Using device /dev/le (promiscuous mode) 1000 #
I collected some snoop data on Web servers, both on the Internet and on
a local high-speed connection. I sat down with Steve Parker and Bruce
Curtis of SunSoft's Internet Engineering Group, and we looked through the
data. I wanted to see if the data was random or could be characterized into
common sequences. We found about 10 different looking plots overall, and
gave up after everything else we looked at matched one of the categories.
The results are shown below.
Tiny HTTP transfer -- HTTP GET incoming request and acks
This trace shows the sequence number up the side, and time along the
X axis. The upper line is the advertised receive window; the lower
line is the acknowledged data. In this case they are eight kilobytes
apart which is the default for Solaris 2. This trace shows the
Solaris server receiving on port 80 and a remote client sending on
port 1145. The server gets a 243-byte incoming GET request marked
by a vertical bar with arrows at each end. It then gets acks for the
data it is sending, which is shown in another graph.
