If you ever had to acquire packets from a network, you probably used tcpdump. Other tools (Wireshark, dumpcap, snort...) can do the same thing, but none is as widely used as tcpdump. tcpdump is simple to use, fast, and universally available (and free!).
So, let's talk about speed and tcpdump. Everybody knows never to run tcpdump without the "-n" switch. But how do other command line switches affect performances? I did a bit of benchmarking to test different options.
I selected a 127 MByte pcap file (just something I had sitting around) collected on my Mac with tcpdump. Then, I used tcpdump with various command line options to measure the speed using the same system. I used this little test script:
#!/bin/sh
arg="-nvvvvvr"
for b in `seq 1 100`; do
start=$(gdate +%s%N)
tcpdump $arg /tmp/testfile > /dev/null
end=$(gdate +%s%N)
echo $arg $((end-start)) | tee -a tcpdump$arg.out
done
Note that I used "gdate" from homebrew. The default "date" command on MacOS does not have the "%N" option for fractional seconds. The output file was then analyzed with "datamash" (datamash -t ' ' mean 2 min 2 max 2). The data was a bit more noisy than I would have liked. I had to remove some outliers.
Command Line Options | Mean (msec) | Minimum (msec) | Maximum (msec) |
n |
345 |
339 |
382 |
nq |
211 |
205 |
277 |
nt |
263 |
256 |
295 |
ntq |
125 |
123 |
128 |
nv |
472 |
461 |
499 |
nvv |
508 |
473 |
589 |
nvvv |
483 |
475 |
500 |
nvvvv |
489 |
477 |
527 |
nvvvvv |
513 |
499 |
549 |
In addition to the 'n' switch, both 'q' (Quiet) and 't' (suppress timestamps) delivered nice performance gains. In particular, 't' is an option you should consider if post-processing tcpdump files. When summarizing pcap files, the timestamp is often not needed. In particular, note the gain of using 'q' and 't' simultaneously.
Adding verbosity is, of course, slowing things down. How much verbosity you add does not appear to affect the speed significantly.
---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|