TCP vs UDP: what is the difference?

02TCP vs UDP at a glance

03Handshake versus fire-and-forget

TCP opens every connection with a three-way handshake: the client sends SYN, the server replies SYN-ACK and reserves state, and the client answers ACK. Only then does data flow. Each byte is numbered, acknowledged, and retransmitted if it goes missing, and TCP backs off when the network is congested. That machinery is why a web page or a file arrives intact.

UDP does none of this. A datagram is addressed and sent; there is no setup, no acknowledgement, and no memory of what came before. The 8-byte header carries only source port, destination port, length and checksum. If a datagram is lost, UDP neither notices nor resends — the application decides whether that matters.

The handshake is also the security hinge. Because TCP commits memory after the first packet, it can be attacked with a flood of SYNs that never complete — a SYN flood. Because UDP expects no reply, the sender never has to be reachable, which makes its source address trivial to forge.

There is a performance trade-off too. TCP's ordering guarantee means a single lost segment can hold up everything behind it until it is retransmitted — head-of-line blocking — which is one reason QUIC moved to UDP and rebuilt ordering per stream. UDP never blocks: a lost datagram is simply skipped, which is exactly what a video call or game wants, where a stale packet is worthless the moment it is late.

04When each protocol is used

The choice follows the guarantee the application needs. If every byte must arrive and order matters, TCP. If timeliness beats completeness, UDP.

• TCP for the web (HTTP/1.1 and HTTP/2), email (SMTP/IMAP), and file transfer — completeness is non-negotiable
• UDP for DNS lookups, where a single small query and reply is faster without a handshake
• UDP for online gaming and real-time voice/video, where a late packet is worse than a lost one
• UDP for HTTP/3, which runs over QUIC — a protocol built on UDP that adds its own reliability and encryption
• TCP as a fallback for DNS when a response is too large for one datagram (RFC 7766)

05The security angle: why UDP floods dominate

UDP is the attacker's preferred transport for volumetric DDoS, for two structural reasons. There is no handshake, so a host can emit datagrams at line rate with no bookkeeping. And because no reply is expected, the source address can be spoofed freely, so the flood appears to come from everywhere and offers no useful list to block.

Those same properties enable reflection and amplification. An attacker sends a small request to a public server — a DNS resolver, an NTP or CLDAP server, a memcached instance — with the victim's address forged as the source. The server sends a much larger reply to the victim. The ratio of reply size to request size is the amplification factor, and for some protocols it is enormous.

The arithmetic is unforgiving. A memcached factor near 51,000, from the figures below, means a 10 Mbps stream of forged requests can in principle summon 10 Mbps × 51,000 ≈ 510 Gbps of replies onto the victim, given enough exposed servers — the attacker rents a trickle and delivers a flood. Even DNS at a factor of 50 turns a modest uplink into a serious attack, which is why open resolvers and misconfigured UDP services are hunted and abused at scale.

# All UDP arriving (the raw-flood and reflection transport)
tcpdump -ni eth0 'udp'

# Classic reflection source ports converging on you
# (replies to your own DNS/NTP queries match too: judge by volume)
tcpdump -ni eth0 'udp and (src port 53 or src port 123 or src port 389 or src port 1900 or src port 11211)'

# Pure SYNs (SYN set, ACK clear): a flood of these is the SYN-flood shape
tcpdump -ni eth0 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn'

06How this shapes DDoS protection

The transport decides the defence. TCP services for the web can be fronted by a reverse proxy: the proxy terminates the connection, completes the handshake with the client itself, and only forwards real, established sessions to the origin. SYN floods and malformed TCP never reach the server. This is the heart of DDoS mitigation for websites and APIs.

UDP cannot be proxied the same way because there is no connection to terminate. A service that must keep a UDP port open — a game or voice server — needs the flood filtered by capacity and protocol awareness upstream, ideally close to the sources, so that legitimate datagrams still flow. The naive answer, dropping all UDP, leaves the service exactly as unreachable as the attack intended. The split between packet-level and request-level defence is set out in Layer 3/4 versus Layer 7.

One more consequence: because spoofing drives UDP reflection, the long-term fix is network hygiene. If every network filtered outbound packets with forged source addresses, reflection would largely disappear — the goal of ingress filtering. Until that is universal, capacity and filtering carry the load.