We earn commissions using affiliate links.
Quick answer: Use TCP when you need reliability, ordering, and congestion control built-in (web, APIs, email, file transfer). Use UDP when you need low latency and application-defined behavior (real-time voice/video, gaming, custom streaming) — or when using modern protocols built on UDP such as QUIC/HTTP-3 or WireGuard.
UDP vs TCP in 2025: What actually differs?
Both TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) sit above IP and move data as packets (datagrams). The core distinction is where reliability and flow logic live. TCP implements connection setup, reliability, flow control, and congestion control at the transport layer. UDP is minimal: it adds ports and a checksum, then gets out of the way — leaving reliability, ordering, and congestion response to the application (or to a higher protocol layered on top, like QUIC).
How TCP works (mechanics)
- Handshake: 3-way handshake (SYN → SYN-ACK → ACK) establishes state, MSS, window scaling, SACK support, ECN capability, etc. Tear-down uses FIN/ACK or RST.
- Reliability: Byte-stream with sequence numbers and acknowledgments. Lost data is retransmitted. SACK (Selective ACK) lets the receiver report gaps so the sender resends only what’s missing.
- Flow control: Receiver advertises a window (rwnd) to prevent overrun of its buffers.
- Congestion control: Sender adapts its congestion window (cwnd). Common algorithms: Reno, CUBIC (default on most Linux), BBR (Google’s model-based control that tries to match bottleneck bandwidth and round-trip propagation delay).
- Performance knobs: Nagle’s algorithm (coalesces tiny writes; can add latency), Delayed ACKs, TCP Fast Open (reduced handshake, variably supported), ECN (Explicit Congestion Notification) to signal congestion without loss.
- HOL blocking: TCP delivers a strict, ordered stream; loss of one segment stalls delivery of subsequent bytes (“Head-of-Line blocking”) until the gap is filled. (Important for multiplexed application protocols.)
- MTU/MSS: Path MTU Discovery (PMTUD) avoids fragmentation; incorrect MTU can cause black holes when ICMP is filtered. MSS clamping on gateways can mitigate.
How UDP works (mechanics)
- Connectionless: No handshake, no session state in the transport layer.
- Best effort: Each datagram stands alone. If it’s lost or re-ordered, UDP does nothing; the application must decide what to do.
- Checksum: Lightweight integrity check; if invalid, the packet is dropped. No retransmission.
- Broadcast/multicast: Supports one-to-many delivery (subject to network policies). Useful for service discovery and streaming on LANs.
- Extensibility: Higher protocols add reliability and control on top (e.g., RTP/SRTP for media, QUIC for web transport, WireGuard for VPN).
Modern reality: QUIC & HTTP/3 blur the old lines
QUIC runs over UDP but implements its own reliability, congestion control (CUBIC/BBR-like), stream multiplexing, and TLS 1.3 by default. Benefits include 0-RTT/1-RTT connection setup, mobility (connection IDs survive IP changes), and no TCP HOL blocking across streams. HTTP/3 uses QUIC. So although “UDP is unreliable” is still true at the transport layer, application stacks can (and do) add reliability and security above UDP.
Security posture
- TLS: With TCP, HTTPS = HTTP over TLS over TCP. With QUIC, TLS 1.3 is embedded in QUIC over UDP.
- Spoofing & amplification: UDP is easily spoofed (no handshake), enabling amplification DDoS (DNS, NTP, Memcached). Mitigations: source address validation (BCP38), rate limiting, RRL, anycast, and CAPTCHAs at the app layer.
- SYN floods: TCP can be victim to SYN floods; servers use SYN cookies and backlog tuning.
- Middleboxes & DPI: Old NATs/firewalls may mishandle new TCP options or block UDP. QUIC encrypts most headers, frustrating DPI but sometimes triggering blanket UDP throttling on hostile networks.
NAT traversal & mobility
- UDP hole punching: Core to WebRTC (STUN/TURN/ICE) for peer-to-peer media. UDP’s connectionless nature helps establish mappings through NAT.
- Tunneling: VPNs like WireGuard (UDP-only) and OpenVPN UDP traverse NATs well. TCP-over-TCP (e.g., OpenVPN TCP) can cause “meltdown” under loss (two congestion controls fighting each other).
- Mobility: QUIC connection IDs allow path changes (Wi-Fi → LTE) with reduced renegotiation.
Performance characteristics
- Latency: UDP has no handshake → faster first packet. TCP’s handshake adds at least 1 RTT (more with TLS unless TLS 1.3 0-RTT/1-RTT).
- Throughput: Modern TCP with CUBIC/BBR often saturates high-bandwidth links. UDP apps can achieve similar throughput but must implement CC fairly to avoid network harm.
- Jitter sensitivity: Real-time media prefers UDP (or QUIC) with app-level jitter buffers, Pacer, and optional FEC rather than strict retransmission.
Protocol selection by use case
- Web browsing, APIs, email, file sync/transfer: TCP (or HTTP/3 over QUIC transparently).
- Real-time voice/video (VoIP, conferencing), gaming state updates: UDP (RTP/SRTP, custom protocols). Small, timely packets > perfect reliability.
- Live streaming at scale: UDP multicast (LAN) or HTTP(S) over TCP/QUIC with CDN for the public internet.
- DNS: UDP for small queries; fallback to TCP for large responses (and DoT/DoH for privacy).
- VPNs: Prefer WireGuard (UDP) or OpenVPN UDP for performance; use OpenVPN TCP only on very restrictive networks or where proxies are required.
Expanded comparison: TCP vs UDP
| Dimension | TCP | UDP |
|---|---|---|
| Connection model | Connection-oriented (3-way handshake) | Connectionless |
| Reliability/ordering | Built-in reliability, ordered byte stream | None by default (app/upper layer decides) |
| Congestion/flow control | Yes (CUBIC, BBR, rwnd) | No (must be implemented by app) |
| Latency to first byte | ≥1 RTT handshake (+TLS unless 1.3) | Immediate (no handshake) |
| Head-of-Line blocking | Yes at transport (per connection) | No at transport; app may avoid HOL |
| Multicast/broadcast | No | Yes (subject to network policy) |
| Typical uses | HTTP(S), SMTP/IMAP, SSH, SFTP/FTPS, databases | RTP/SRTP, QUIC/HTTP-3, DNS, DHCP, VoIP, games |
| Firewall/NAT traversal | Often allowed; stateful inspection is common | Sometimes blocked/throttled; works well with hole punching (STUN/TURN/ICE) |
When TCP is the right choice
- Integrity matters more than immediacy: Payments, file sync, API calls, database replication.
- Middlebox friendliness: TCP is widely understood by firewalls, proxies, IDS/IPS.
- Simplicity at the app layer: You don’t want to implement your own retransmits, ordering, or congestion logic.
When UDP (or UDP-based stacks) is the right choice
- Real-time traffic: Voice/video where late is worse than lost. Use RTP/SRTP with jitter buffering, FEC, and limited ARQ.
- Low-latency gaming: Frequent small state updates; the app resends only what matters and ignores stale data.
- Modern web transport: HTTP/3/QUIC gives TCP-like reliability without HOL blocking and with faster setup.
- VPN performance: WireGuard (UDP) is fast/lean; OpenVPN UDP generally outperforms TCP.
Practical tuning & troubleshooting
For TCP
- Enable SACK and window scaling (they usually are by default).
- Congestion control: Try BBR for high-bandwidth, long-RTT links; CUBIC remains a solid default.
- Nagle vs latency: Disable Nagle (
TCP_NODELAY) for interactive apps sending small messages. - MSS/PMTUD: Clamp MSS on tunnels/VPNs to avoid black holes if ICMP is filtered.
- Measure: Use
iperf3 -t 30 -P 4(parallel streams),ss -ti,tcpdump, Wireshark for capture analysis.
For UDP
- Implement pacing & congestion response in the app or use a stack that does (QUIC).
- Jitter buffers and adaptive bitrate for media.
- Use STUN/TURN/ICE for NAT traversal (WebRTC).
- Packet size: Keep below path MTU (≈1200 bytes payload is QUIC’s conservative default) to avoid fragmentation.
- Measure:
iperf3 -u -b 50M -l 1200 -t 30, monitor loss/jitter; capture withtcpdump udp.
OpenVPN: UDP vs TCP (common admin question)
- OpenVPN UDP: Lower latency, better throughput, tolerates loss gracefully. Recommended default.
- OpenVPN TCP: Works through restrictive proxies/firewalls but risks “TCP-over-TCP” meltdown under loss (compounded retransmissions & congestion control). Use only when networks force it.
- WireGuard (UDP only): Lean codebase, fast handshakes, excellent roaming — a better first choice when available.
Real-world examples
- Web browsing today: Many sites negotiate HTTP/3 over QUIC (UDP). If blocked, clients fall back to HTTP/2 over TCP.
- DNS privacy: Traditional DNS uses UDP/53 (TCP on truncation). Privacy variants: DoT (TCP/TLS/853) and DoH (HTTPS/TCP or QUIC).
- Voice calls (WebRTC): SRTP over UDP with FEC/PLC; TURN relays when direct NAT traversal fails.
- Gaming: UDP for state updates; reliable semantics for critical data are added at the app layer.
Decision checklist
- Do you require guaranteed in-order delivery? → TCP (or QUIC streams).
- Is latency more important than reliability? → UDP with app-level logic (RTP, custom protocols).
- Are hostile middleboxes an issue? → TCP 443 (fallback) or QUIC with fallback; consider obfuscation.
- Will you run over long fat networks (LFN)? → TCP with BBR or QUIC; tune buffers and pacing.
- Do you need multicast/broadcast? → UDP (LAN contexts).
FAQ
Is UDP always faster than TCP?
Not always. UDP can reduce handshake delay and CPU overhead, but if your app adds reliability or if networks throttle UDP, TCP (or QUIC) may outperform it. On stable, long-lived flows, tuned TCP with CUBIC/BBR is extremely fast.
Can I make UDP reliable?
Yes—at the application or session layer. QUIC, RTP with NACK/FEC, and custom ARQ schemes add ordered, reliable delivery where needed, while still allowing time-sensitive packets to skip retransmission.
Why does TCP sometimes feel “laggy” for interactive apps?
Nagle’s algorithm and delayed ACKs can add small latencies to tiny writes. Disable Nagle (TCP_NODELAY) for interactive RPC/controls, or batch logically at the app layer.
Why does TCP over TCP (tunnels) perform poorly?
Because two congestion controllers interfere. Loss triggers retransmission and window reduction in both layers, causing collapse. Prefer UDP-based tunnels (WireGuard/OpenVPN UDP).
What ports do they use?
They don’t have fixed ports; applications choose them. Common examples: HTTP (TCP/80, TCP/443), HTTP/3 (UDP/443), DNS (UDP/53; TCP on truncation), DHCP (UDP/67/68), QUIC (UDP/443), OpenVPN (UDP/1194 default).
How do I test which is better for my network?
Use iperf3: run a server remote, then test TCP throughput (iperf3 -c host -P 4) and UDP loss/jitter (iperf3 -u -b 50M -l 1200 -t 30). Capture with Wireshark to inspect retransmissions, out-of-order, or PMTUD issues.
Conclusion
TCP remains the default for transactional integrity, with decades of optimizations for fairness and throughput. UDP is the low-latency substrate for real-time and, increasingly, a foundation for modern transports like QUIC that re-implement reliability smarter at the application layer. In 2025, the right choice is less “TCP vs UDP” and more “which stack over which transport”: TCP for classic reliability and broad compatibility, UDP when you control the app layer (RTP, QUIC) and value latency, mobility, or multiplexing advantages.
“UDP doesn’t have any system or mechanism that allows it to check for errors. If the error occurred some implementations of UDP protocol will just discard the corrupted or damaged datagram. Some other implementations send the datagram with a warning that it has been corrupted”
this is a contradictory statement. how does UDP discard corrupted packages if it has no mechanism to check for errors? UDP does have error checking in the form of a checksum. the difference between udp and tcp is that when tcp detects in error it will automatically retransmit where as udp will just drop the packet
Hi, thank you for pointing the error out. It’s worth noting that UDP checksum uses a simple algorithm, which means it won’t always detect all errors. We still updated the article to reflect this statement.