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.

The tcp.analysis tool

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

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine