TCP vs UDP: What Is the Difference?

Two Transport Protocols, One Job

The transport layer has one job: get data from an application on one machine to an application on another machine. IP handles routing the packet across the network, but IP does not know which application should receive the data. That is the transport layer's problem, and it solves it with port numbers.

TCP and UDP both use port numbers to identify applications. Both sit on top of IP. Both are used every day by every device on the internet. But they make fundamentally different tradeoffs about what matters most.

TCP prioritizes correctness. Every byte arrives, in order, exactly once. If something goes wrong, TCP fixes it automatically. The cost is complexity and latency.

UDP prioritizes simplicity and speed. It sends data and moves on. If a packet is lost, UDP does not care. The application has to deal with it - or not. The benefit is lower overhead and lower latency.

How TCP Works

TCP (Transmission Control Protocol) is a connection-oriented protocol. Before any data is exchanged, TCP establishes a connection using a three-way handshake: the client sends SYN, the server responds with SYN-ACK, and the client sends ACK. Only after this handshake completes can data flow.

TCP connection state machine: a TCP connection transitions through multiple states from establishment (SYN/SYN-ACK/ACK) through data transfer to teardown (FIN/ACK). (Diagram: Wikimedia Commons, CC BY-SA 3.0)

During the connection, TCP provides several guarantees:

• Reliable delivery - every segment is acknowledged. If the sender does not receive an ACK within a timeout, it retransmits the segment.
• Ordered delivery - each byte has a sequence number. The receiver reassembles data in order, regardless of what order packets arrive.
• No duplicates - sequence numbers let the receiver detect and discard duplicate segments that arrive due to retransmission.
• Flow control - the receiver advertises a window size that tells the sender how much data it can accept. This prevents a fast sender from overwhelming a slow receiver.
• Congestion control - TCP adjusts its sending rate based on network conditions, slowing down when packet loss indicates congestion.

The TCP header is 20 bytes minimum (often 32 bytes with options). It contains source port, destination port, sequence number, acknowledgment number, flags (SYN, ACK, FIN, RST, PSH, URG), window size, checksum, and urgent pointer. Each field serves the reliability machinery described above.

How UDP Works

UDP (User Datagram Protocol) is connectionless. There is no handshake. The sender puts data in a UDP datagram and sends it. The receiver either gets it or does not. There is no acknowledgment, no retransmission, no ordering, no flow control.

The complete UDP header: just 8 bytes. Source port, destination port, length, and checksum. No sequence numbers, no acknowledgments, no connection state. (Diagram: Wikimedia Commons, CC BY-SA 3.0)

The UDP header is 8 bytes. It contains source port, destination port, length, and checksum. That is it. Compare that to TCP's minimum 20 bytes of header with sequence numbers, acknowledgments, window sizes, and flags. UDP's simplicity is its entire value proposition.

No connection setup means no latency before data flows. No acknowledgments mean no waiting for responses. No retransmission means no delays from recovery. For applications that can tolerate some data loss, UDP delivers lower latency and higher throughput than TCP.

sequenceDiagram
    participant C as Client
    participant S as Server

    Note over C,S: TCP Connection Setup
    C->>S: SYN
    S->>C: SYN-ACK
    C->>S: ACK
    Note over C,S: Connection established

    C->>S: Data segment (seq=1)
    S->>C: ACK (ack=2)
    C->>S: Data segment (seq=2)
    S->>C: ACK (ack=3)

    Note over C,S: Connection Teardown
    C->>S: FIN
    S->>C: ACK
    S->>C: FIN
    C->>S: ACK

The Tradeoff: Reliability vs Speed

UDP encapsulation: the application data is wrapped with minimal overhead. Each layer adds only essential headers. (Diagram: Wikimedia Commons, CC BY-SA 3.0)

The choice between TCP and UDP comes down to what your application needs:

Property	TCP	UDP
Connection setup	Three-way handshake (adds latency)	None (send immediately)
Delivery guarantee	Yes - retransmits lost segments	No - lost is lost
Order guarantee	Yes - reassembles in sequence	No - application must handle
Header size	20-60 bytes	8 bytes
Flow control	Yes - window-based	No
Congestion control	Yes - adjusts to network conditions	No - sends at application rate
Best for	Web, email, file transfer, SSH	DNS, VoIP, video, gaming, NTP

Neither protocol is universally "better." They solve different problems. A web page that loads with missing chunks is useless - TCP's reliability is essential. A video call where one lost frame causes a 200ms stall while waiting for retransmission is also useless - UDP's speed is essential.

sequenceDiagram
    participant C as Client
    participant S as Server

    Note over C,S: UDP - No Handshake
    C->>S: Datagram 1
    C->>S: Datagram 2
    C-xS: Datagram 3 (lost!)
    C->>S: Datagram 4
    Note over S: No retransmission
Datagram 3 is gone

When to Use Which

TCP is the right choice when:

• Data integrity matters more than speed (file transfers, database queries, API calls)
• The application cannot function with missing or out-of-order data
• The connection is long-lived and bidirectional (SSH sessions, web sockets)
• You need the transport layer to handle reliability so the application does not have to

UDP is the right choice when:

• Low latency matters more than guaranteed delivery (real-time voice, video, gaming)
• The exchange is short - a single request and response (DNS queries, NTP time sync)
• The application implements its own reliability on top (QUIC, custom game protocols)
• Broadcasting or multicasting data to many receivers simultaneously

Some modern protocols blur the line. QUIC (used by HTTP/3) runs over UDP but implements its own reliability, ordering, and congestion control - essentially rebuilding TCP's guarantees in user space while avoiding TCP's head-of-line blocking problem. DNS typically uses UDP for queries under 512 bytes but falls back to TCP for larger responses or zone transfers.

graph LR
    subgraph "TCP"
        T1["3-way handshake"] --> T2["Reliable delivery"]
        T2 --> T3["Ordered segments"]
        T3 --> T4["20-60 byte header"]
    end
    subgraph "UDP"
        U1["No handshake"] --> U2["No guarantees"]
        U2 --> U3["No ordering"]
        U3 --> U4["8 byte header"]
    end

Security Implications

The protocol choice affects the attack surface. TCP's three-way handshake creates opportunities for SYN flood attacks, where an attacker sends millions of SYN packets without completing the handshake, exhausting the server's connection table. UDP has no handshake, so SYN floods do not apply - but UDP's lack of connection tracking makes it easier to spoof source addresses for reflection and amplification attacks (DNS amplification, NTP amplification, memcached amplification).

For wireless security testing, both protocols appear in the traffic the BLEShark Nano monitors. WPA2 handshake capture involves EAPOL frames that carry key negotiation data at Layer 2 - before TCP or UDP even come into play. But once a client is connected and passing data, the transport protocol affects what the traffic looks like and how it can be analyzed. DNS queries over UDP are single-packet exchanges visible in a capture. HTTPS over TCP is a stream of encrypted segments that only reveals metadata (timing, sizes) without the TLS keys.

Get the BLEShark Nano