tcpdump and Wireshark read the same packets and write the same file format. The difference is where they are meant to run: tcpdump is a command-line capture tool built to be used on the machine where the traffic is, including servers with no desktop; Wireshark is a graphical analyser built to examine a capture in depth once you have it.
In practice they are not alternatives so much as two halves of one workflow.
What each is good at
tcpdump starts instantly, runs over SSH, costs almost nothing in resources and is already installed on most Unix systems. Its filter syntax is precise, and it can run unattended for days writing rotating files. What it cannot do is follow a conversation across packets or decode an application protocol in any depth.
Wireshark does exactly that. It reassembles TCP streams, decodes hundreds of application protocols, colours anomalies, and gives you statistics such as round-trip times and retransmission counts without constructing them by hand. The cost is that it wants a desktop and enough memory to hold the capture.
Capture with one, analyse with the other
The usual pattern is to capture on the server with tcpdump and analyse on a workstation with Wireshark. The file is interchangeable because both use the same PCAP format.
# on the server
tcpdump -i eth0 -w /tmp/capture.pcap 'host 10.0.0.1 and port 443'
# then copy it locally and open it
scp server:/tmp/capture.pcap .
wireshark capture.pcapWireshark also ships tshark, its command-line form, which is useful when you want Wireshark's decoding but no interface.
Why not just capture with Wireshark?
You can, and on a laptop it is often the simpler choice. On a production server it usually is not: installing a desktop package on a trading host is rarely welcome, and the graphical capture buffers in memory in a way that long tcpdump runs do not.
There is also a subtler reason to prefer a minimal capture tool. Anything running on the host competes with the workload and perturbs what it is measuring. The lighter the capture, the smaller that distortion.
Where both stop being enough
Both tools answer questions about traffic you decided to capture, on one host, starting now. Neither helps with a question raised next week about an event that has already passed, because by then nothing was recorded.
That is a different problem, solved by capturing continuously across many links rather than reaching for a tool when something breaks. See what PCAP is, the tcpdump cheat sheet for the commands themselves, and Corvil Network Capture for continuous capture at line rate in trading environments.