← Back to all posts
Article

TCP vs UDP Through a Small Packet Capture

Author:

Generate one local TCP request and one UDP datagram, then use a loopback capture to compare setup, payload and reply behavior.

One blue packet follows a short linked path while another stands alone

TCP and UDP both carry data between applications, and both use port numbers. In a packet capture, the useful beginner distinction is what happens before data is delivered. A TCP client establishes a connection; a UDP sender can transmit a datagram without a TCP-style connection setup. The receiving application still decides whether to respond.

The TCP specification, RFC 9293, describes the three-way handshake. RFC 768 defines UDP datagrams. Build one local example of each so the protocols are observed at the same capture point. This exercise uses services on your own machine and no external target.

Prepare the capture point

Open Wireshark and choose the interface that captures traffic to 127.0.0.1. That is usually the loopback interface, not your Wi-Fi or Ethernet adapter. Wireshark’s loopback capture guide describes platform differences. Capture access may require OS permissions or a configured capture helper. Start capturing before the client commands below.

After collecting traffic, apply this Wireshark display filter:

tcp.port == 18081 or udp.port == 18082

A display filter narrows what is shown from an existing capture. It cannot recover packets missed because the wrong interface was selected; see the Wireshark filter guide.

Send one TCP request

In a terminal, create a disposable page and start a loopback HTTP server:

mkdir -p /tmp/transport-capture-demo
printf 'tcp-reply\n' > /tmp/transport-capture-demo/index.html
python3 -m http.server 18081 --bind 127.0.0.1 --directory /tmp/transport-capture-demo

In another terminal, make one request:

curl -fsS http://127.0.0.1:18081/

Look for the TCP SYN, SYN/ACK and ACK that establish the connection, followed by the HTTP request and response. The capture may show additional acknowledgments or connection-closing packets; do not use a fixed packet count as the lesson. Stop the HTTP server with Ctrl-C when done.

Send one UDP datagram

Start a receiver in a terminal. It accepts one datagram and prints its contents and sender address:

python3 -c 'import socket; s=socket.socket(socket.AF_INET, socket.SOCK_DGRAM); s.bind(("127.0.0.1", 18082)); print(s.recvfrom(1024)); s.close()'

From another terminal, send the message:

python3 -c 'import socket; s=socket.socket(socket.AF_INET, socket.SOCK_DGRAM); s.sendto(b"udp-message", ("127.0.0.1", 18082)); s.close()'

Find the UDP datagram to port 18082 in the capture. There is no preceding TCP handshake for it. The receiver prints the message, but that printout is application behavior, not a UDP delivery guarantee. This small receiver sends no reply. In other exercises, an application can add its own acknowledgments, retries or session behavior on top of UDP.

What to inspect TCP request UDP datagram
Before application data Connection-establishing exchange No TCP-style connection setup
Unit visible in this exercise TCP segments carrying an HTTP exchange One application datagram
Proof of useful result HTTP response body and status Receiver’s printed payload

If the Wireshark list is empty, check the loopback interface, capture permissions, filter and whether the client commands actually ran. A missing packet in your view is not evidence that the protocol skipped it. For further practice, LabEx lists a Network Interface and Basic Capture lab and a Wireshark capture-and-analysis lab; check the current lab pages for their environment requirements.

References