TCP vs UDP: differences, handshakes and when each is used

Every packet you capture at the transport layer is almost certainly TCP or UDP. Knowing how they differ tells you what "normal" looks like in a capture, and makes odd traffic stand out.

The short version

TCP: a reliable byte stream

TCP makes an unreliable network look like a reliable pipe. To do that it numbers every byte and tracks acknowledgements.

The three-way handshake

Before any data flows, the client and server agree on starting sequence numbers:

Client                              Server
  | ---- SYN (seq=x) --------------->  |
  | <--- SYN, ACK (seq=y, ack=x+1) --  |
  | ---- ACK (ack=y+1) ------------->  |
  |        connection established      |

In Wireshark the first three packets of a connection look like this (simplified):

No.  Source          Destination     Protocol  Info
1    192.168.1.20    203.0.113.10    TCP       51514 → 443 [SYN] Seq=0
2    203.0.113.10    192.168.1.20    TCP       443 → 51514 [SYN, ACK] Seq=0 Ack=1
3    192.168.1.20    203.0.113.10    TCP       51514 → 443 [ACK] Seq=1 Ack=1

Wireshark shows relative sequence numbers starting at 0 to make captures readable; the real numbers are random. A connection ends with FIN packets from both sides, or abruptly with an RST.

What TCP adds

• Retransmission: unacknowledged data is sent again.
• Ordering: segments arriving out of order are reassembled.
• Flow control: the receiver's window stops a fast sender from overwhelming it.
• Congestion control: the sender slows down when the network shows signs of loss.

The price is extra round trips at the start and delay when a lost segment holds up everything behind it (head-of-line blocking).

UDP: send and forget

A UDP datagram has just four header fields: source port, destination port, length and checksum. There is no handshake and no acknowledgement. Each datagram stands alone.

That is exactly right when:

• Late data is useless. In a voice call, a packet that arrives after 300 ms is worse than a packet that never arrives.
• The exchange is one question, one answer. A DNS lookup fits in two small packets; setting up a connection would double the time.
• The application wants its own rules. QUIC builds reliability, ordering and TLS 1.3 encryption on top of UDP, per stream, which is why HTTP/3 uses it.

Ports

Both protocols use 16-bit port numbers (0 to 65535) to deliver data to the right application. TCP port 53 and UDP port 53 are different endpoints. Some well-known examples:

Security notes

• SYN floods abuse the handshake by sending many SYNs and never completing them, filling the server's table of half-open connections. SYN cookies are a standard mitigation.
• Spoofing is easier over UDP, because there is no handshake to prove the sender's address. Attackers send small requests with a victim's spoofed address to services that reply with large answers: a reflection and amplification attack.
• Neither protocol encrypts. Confidentiality comes from TLS (over TCP) or QUIC (over UDP), or from VPN tunnels.

Useful Wireshark filters

tcp.flags.syn == 1 && tcp.flags.ack == 0    # new TCP connection attempts
tcp.flags.reset == 1                         # connections that were reset
udp.port == 53                               # classic DNS
tcp.analysis.retransmission                  # lost and resent segments

Try them in the lab Watch a TCP handshake in Wireshark, using only traffic from your own machine.

Summary

• TCP: connection, reliability, ordering, congestion control; costs extra round trips.
• UDP: minimal, connectionless datagrams; the application decides what reliability it needs.
• Modern protocols blur the line: QUIC brings reliability and encryption to UDP.