TCP vs UDP — Side by Side
| Feature | TCP | UDP |
|---|---|---|
| Connection | Connection-oriented (3-way handshake) | Connectionless (no handshake) |
| Reliability | Guaranteed delivery + retransmission | Best-effort, no guarantee |
| Ordering | Packets delivered in order | May arrive out of order |
| Error checking | Checksums + acknowledgements | Checksum only (no ACK) |
| Speed | Slower (overhead from reliability) | Faster (minimal overhead) |
| Header size | 20–60 bytes | 8 bytes |
| Flow control | Yes (sliding window) | No |
| Congestion control | Yes | No |
| Use cases | HTTP, email, file transfer, SSH | DNS, video streaming, gaming, VoIP |
The TCP Three-Way Handshake
TCP must establish a connection before sending data. This costs one round trip:
This handshake adds ~1 RTT of latency before any data flows. On a London-to-Singapore connection (150ms RTT), you pay 150ms just to open the connection. HTTP/2 reuses connections to amortise this cost; HTTP/3 (QUIC) eliminates the handshake entirely on resumed connections.
UDP — Fire and Forget
UDP sends packets (datagrams) directly with no setup:
If a packet is lost, it is gone. The application must decide whether to retransmit, skip it, or interpolate. This gives applications full control over the reliability trade-off.
When to Use TCP
- HTTP/HTTPS: Web pages, REST APIs — data must be complete and correct
- Email (SMTP, IMAP): Messages must arrive intact
- File transfer (FTP, SFTP): Every byte must be delivered
- SSH: Terminal commands must arrive in order
- Database connections: Queries and results must be reliable
When to Use UDP
- DNS: Small query/response — speed matters, retransmit is easy
- Video streaming (WebRTC, RTP): Latency > reliability — drop a frame, not the call
- Online gaming: Position updates — old data is worthless, just send the latest
- VoIP: A 20ms audio glitch is better than a 500ms freeze
- DHCP, TFTP: Simple protocols where reliability is handled at the application layer
- Broadcast/multicast: UDP supports sending to multiple recipients simultaneously
QUIC — The Best of Both
QUIC (Quick UDP Internet Connections) is the transport protocol underlying HTTP/3. It is built on UDP but implements reliability, ordering, encryption, and multiplexing at the application layer. This lets it:
- Avoid head-of-line blocking (one lost packet doesn't stall other streams)
- Establish connections in 0 RTT on resumed sessions
- Encrypt by default (TLS 1.3 built in)
- Migrate connections when the client's IP changes (mobile networks)
💡 Protocol Port Numbers
TCP: HTTP 80, HTTPS 443, SSH 22, FTP 21, SMTP 25, MySQL 3306, PostgreSQL 5432.
UDP: DNS 53, DHCP 67/68, NTP 123, SNMP 161, QUIC/HTTP3 443.
How We Research and Update This Guide
We test the underlying formula or workflow, compare outputs with reliable references, and revise examples whenever the page content changes.
- The workflow or formula is tested directly in the tool and compared against independent reference examples.
- Examples are kept practical so readers can verify the result without hidden assumptions.
- Pages are revised whenever the interface, calculation flow, or surrounding guidance materially changes.
Frequently Asked Questions — TCP vs UDP
TCP (Transmission Control Protocol) is connection-oriented — it establishes a connection before sending data, guarantees delivery and order, and retransmits lost packets. UDP (User Datagram Protocol) is connectionless — it sends packets without establishing a connection, with no guarantee of delivery, order, or duplicate prevention. TCP is reliable but slower; UDP is fast but unreliable.
DNS responses are small (usually under 512 bytes) and fit in a single UDP packet. UDP is much faster because there is no connection overhead — no 3-way handshake, no acknowledgements. If a DNS response is lost, the client simply resends the query after a timeout. DNS uses TCP as a fallback for large responses (DNSSEC, zone transfers) or when the UDP response exceeds 512 bytes.
Video calls prioritise low latency over perfect reliability. With TCP, if a packet is lost, the stream stalls waiting for retransmission — this causes noticeable freezes. With UDP, a lost packet (a fraction of a second of audio/video) is simply skipped and playback continues. A brief glitch is far less annoying than a freeze. WebRTC (used by Google Meet, Zoom) uses UDP with its own application-level reliability layer (SRTP/RTCP).
Before TCP can send data, it establishes a connection via a 3-way handshake: (1) SYN — client sends a synchronise packet to the server. (2) SYN-ACK — server acknowledges and sends its own synchronise. (3) ACK — client acknowledges. Now the connection is established and data can flow. This handshake adds one round-trip of latency before any data is sent, which is why QUIC/HTTP3 eliminates it.
QUIC is a new transport protocol (the foundation of HTTP/3) built on top of UDP. It combines TCP's reliability (acknowledgements, retransmission, ordering) with UDP's speed (no OS-level handshake, connection establishment in 0 RTT on resumed connections). QUIC also encrypts the transport layer by default. It delivers TCP-like reliability without TCP's head-of-line blocking problem — one lost packet does not block other streams.
Yes. UDP packets are independent datagrams — each is routed separately and may take different paths through the network. They can arrive out of order, be duplicated, or be lost entirely. Applications that use UDP and need ordering (like video streaming) must implement their own sequence numbers and reordering logic at the application layer. TCP handles all of this automatically.