TCP vs UDP: The Complete Guide to Network Protocols (2026)
TCP and UDP are the two transport-layer protocols that power virtually every networked application on the internet. Choosing between them, or knowing when to use both, directly determines whether your application feels fast and responsive or reliable and accurate. This guide covers how each protocol works at a technical level, when to use each one, real-world examples from companies like Google, Netflix, and Microsoft, performance benchmarks, modern hybrid protocols like QUIC, and how to tunnel both TCP and UDP traffic through NAT and CGNAT using Localtonet.
TCP vs UDP: Quick Answer
The One-Paragraph Difference
TCP (Transmission Control Protocol) is a connection-oriented protocol that guarantees every packet arrives in order and without errors. It is slower because of this guarantee. Use TCP when losing a single byte would break your application: file transfers, web pages, email, banking.
UDP (User Datagram Protocol) is a connectionless protocol that sends packets with no delivery guarantee. It is fast because it skips all the overhead of confirmation. Use UDP when a brief loss is acceptable but delay is not: online games, live video, voice calls, DNS.
How TCP Works
TCP is defined in RFC 793, published in 1981, and remains one of the most fundamental protocols on the internet. Before any data is sent, TCP requires both sides to establish a connection through a process called the three-way handshake.
SYN (Synchronize)
The client sends a SYN packet to the server saying "I want to start a connection." The packet contains the client's initial sequence number, which is used to track packet order.
SYN-ACK (Synchronize-Acknowledge)
The server responds with SYN-ACK, saying "I received your request and I am ready." It also sends its own initial sequence number.
ACK (Acknowledge)
The client acknowledges the server's response. The connection is established. Data transfer begins only after this third step is complete.
After the connection is established, TCP uses several mechanisms to guarantee reliable delivery:
If a single TCP packet is lost in transit, the entire stream stalls until that specific packet is retransmitted and acknowledged, even if many later packets have already arrived and are waiting in the receiver's buffer. This is called head-of-line blocking and is one of the primary motivations for QUIC, which was designed to eliminate this problem.
How UDP Works
UDP is defined in RFC 768, published in 1980 and only 3 pages long, compared to TCP's 85-page RFC. Its simplicity is its strength. The entire UDP header is just 8 bytes and contains only four fields: source port, destination port, length, and checksum.
When an application sends data via UDP, the operating system wraps it in a UDP datagram and sends it out. There is no connection to establish, no acknowledgment to wait for, no retransmission if the packet is lost, and no ordering mechanism. The receiver either gets the packet or it does not. If it gets it, the checksum is verified and the data is delivered. That is the entire protocol.
What UDP Gains from Its Simplicity
- No round-trip delay for connection establishment
- No head-of-line blocking between independent messages
- 8-byte header vs TCP's 20-60 bytes
- No retransmission delays when packets are lost
- Supports multicast and broadcast natively
- Application controls its own reliability logic
What UDP Gives Up
- No guaranteed delivery
- No ordering guarantees
- No congestion control (can flood the network)
- No built-in flow control
- Firewall and NAT traversal is harder
- Application must handle reliability if needed
TCP vs UDP: Full Technical Comparison
| Property | TCP | UDP |
|---|---|---|
| Connection model | Connection-oriented (3-way handshake) | Connectionless (no setup) |
| Delivery guarantee | Guaranteed (retransmits lost packets) | Best-effort (no retransmission) |
| Packet ordering | Ordered (sequence numbers) | Unordered (application must handle) |
| Error checking | Full (checksum + retransmission) | Checksum only (no retransmission) |
| Header size | 20-60 bytes (variable) | 8 bytes (fixed) |
| Speed | Slower (due to overhead) | Faster (minimal overhead) |
| Latency | Higher (ACK round trips) | Lower (no ACK waits) |
| Flow control | Yes (window-based) | No |
| Congestion control | Yes (slow start, CUBIC, BBR) | No (application responsible) |
| Broadcast/Multicast | No | Yes |
| NAT traversal | Easier (stateful connection tracking) | Harder (requires hole punching) |
| Head-of-line blocking | Yes (all streams block) | No (independent datagrams) |
| RFC | RFC 793 (1981) | RFC 768 (1980) |
When to Use TCP
Use TCP whenever losing or reordering a single byte would break your application's correctness. TCP's reliability mechanisms exist precisely for these cases.
🌐 Web Browsing (HTTP/HTTPS)
Every web page is delivered over TCP. A missing byte in a JavaScript file could cause a syntax error and break the entire page. A missing CSS rule could corrupt the layout. TCP guarantees that the full content arrives before the browser renders it. HTTP/1.1 and HTTP/2 both run over TCP. Only HTTP/3 (which uses QUIC over UDP) breaks this pattern.
📧 Email (SMTP, IMAP, POP3)
Email protocols require reliable delivery because a missing header, attachment byte, or MIME boundary would make the message unreadable. SMTP runs on TCP port 25 (or 587 for submission). IMAP runs on port 143. POP3 runs on port 110. All three have TLS variants that add encryption on top of TCP.
📁 File Transfers (FTP, SFTP, SCP)
File transfer protocols use TCP because a single missing or corrupted byte in an executable, compressed archive, or encrypted file renders it unusable. FTP uses TCP on ports 20 and 21. SFTP and SCP run over SSH on TCP port 22. If a single block of a ZIP archive is corrupt, the entire file fails to extract.
💳 Financial Transactions and APIs
Banking, payment processing, and financial APIs use TCP because every transaction record must be complete and in order. A missing byte in a payment amount or account number field would cause a catastrophic data error. HTTPS (TCP + TLS) is the foundation of all financial API communication.
🗄 Databases
Database protocols like MySQL (port 3306), PostgreSQL (port 5432), and Redis (port 6379) all use TCP. Query results must arrive complete and in order. A missing byte in a query result would produce corrupt or incorrect data in your application.
💬 Chat Applications (non-real-time)
Text messaging, group chat, and notification delivery use TCP because messages must arrive in order and completely. Slack, Discord (for text channels), and most chat APIs use HTTPS over TCP for message delivery even when voice uses UDP.
When to Use UDP
Use UDP whenever your application can tolerate occasional packet loss but cannot tolerate delay. Real-time applications fall into this category almost universally.
🎮 Online Gaming
Competitive multiplayer games (first-person shooters, battle royale, MOBAs) send position updates, player inputs, and world state 30-128 times per second. If a position update from 33 milliseconds ago is lost, retransmitting it is worse than ignoring it: the player has already moved. Games use UDP and implement their own delta compression and interpolation to handle loss. TCP's retransmission would cause input lag that makes games unplayable at high skill levels. Games like Counter-Strike, Fortnite, and League of Legends use UDP for gameplay traffic.
📹 Video Conferencing (Zoom, Teams, Meet)
Voice and video data is inherently time-bound. A voice packet from 200 milliseconds ago is worthless. Retransmitting it via TCP would cause the audio to fall behind. All major video conferencing platforms use UDP (typically via WebRTC) for media streams. A small gap in audio is far less disruptive than the audio falling 1-2 seconds behind the video due to TCP retransmission.
📡 Live Streaming (Twitch, YouTube Live)
Live stream viewers accept brief quality drops but not buffering. If a video frame is lost, displaying a slightly degraded frame is better than pausing the stream to wait for retransmission. Live streaming often uses UDP-based protocols such as RTP (Real-time Transport Protocol) or proprietary adaptations like RTMP-over-UDP or SRT (Secure Reliable Transport).
🔍 DNS Queries
DNS lookups use UDP on port 53 because they are typically a single small request and response (under 512 bytes). If a DNS query is lost, the client simply sends it again. The overhead of a TCP handshake for such a tiny, one-shot transaction would be excessive. DNS falls back to TCP only when the response exceeds 512 bytes, such as for large zone transfers or DNSSEC-signed records.
📡 IoT Sensor Data and Telemetry
Sensors that broadcast temperature, humidity, accelerometer, or GPS data benefit from UDP because readings are continuous and a missed reading is simply replaced by the next one. Protocols like CoAP (Constrained Application Protocol), used in IoT networks, are built on UDP because IoT devices have limited memory and power, and TCP's overhead is too costly.
🔊 VoIP (Voice over IP)
VoIP protocols like RTP (Real-time Transport Protocol) and SIP media streams use UDP. A dropped voice packet produces a brief audio artifact (a click or 20ms of silence) that human ears easily tolerate. A 200ms delay from TCP retransmission completely disrupts conversation flow. Cisco phones, SIP trunks, and protocols like WebRTC all use UDP for the actual voice stream.
🕹 Game Server Discovery and LAN Broadcasting
UDP's native support for broadcast and multicast makes it ideal for service discovery. When a game client looks for servers on a LAN, it broadcasts a UDP packet and servers reply. With TCP, you would need a central discovery server because TCP does not support broadcast. mDNS (Multicast DNS), used by Apple Bonjour and Linux Avahi for local network discovery, also runs entirely over UDP.
How Big Tech Chooses Between TCP and UDP
Google: QUIC over UDP for Chrome, YouTube, and Search
Google developed QUIC (Quick UDP Internet Connections) in 2012 and standardized it as HTTP/3 in 2022 (RFC 9000). QUIC runs entirely over UDP and reimplements TCP's reliability, flow control, and congestion control at the application layer, while eliminating head-of-line blocking between independent streams. A single lost packet in QUIC only blocks the specific stream it belongs to, not all streams sharing the connection. Google reported 8% reduction in video rebuffering on YouTube and 3% improvement in Google Search latency after deploying QUIC. As of 2024, over 25% of all internet traffic uses HTTP/3 over QUIC.
Microsoft Teams: UDP for media, TCP for everything else
Microsoft Teams uses a deliberate split-protocol architecture. Voice and video streams use UDP via RTP (Real-time Transport Protocol), tolerating occasional packet loss in exchange for the low latency that makes conversations natural. Text chat messages, file transfers, presence updates, and meeting control signals all use HTTPS over TCP for guaranteed delivery. Teams clients first try UDP on port 3478 for media and fall back to TCP on port 443 only when UDP is blocked by a firewall, with a known quality penalty.
Netflix: TCP for VOD, UDP-based for live events
Netflix uses HTTPS over TCP for on-demand content via MPEG-DASH (Dynamic Adaptive Streaming over HTTP), relying on TCP's reliability because buffering a few seconds ahead is acceptable and perfect quality is expected. For live events (sports, concerts, award shows), Netflix and similar platforms use UDP-based low-latency protocols because live viewers will not tolerate being 10 seconds behind the real world, even at the cost of occasional brief quality dips.
Cloudflare: Anycast UDP for DDoS absorption and DNS
Cloudflare's public DNS resolver (1.1.1.1) serves billions of queries per day over UDP port 53. Cloudflare also uses UDP for its proprietary Cloudflare Tunnel protocol (previously Argo Tunnel), which is built on QUIC. When absorbing large DDoS attacks, UDP's stateless nature (no connection tracking) allows Cloudflare's network to process and drop malicious packets at line rate without maintaining state for millions of fake connections, which is what makes TCP-based DDoS mitigation much more resource-intensive.
Modern Protocols: QUIC, WebRTC, and SCTP
⚡ QUIC (HTTP/3)
QUIC is the most significant transport-layer innovation since TCP itself. Running over UDP, QUIC provides: 0-RTT connection establishment on resumption (vs TCP's 1-RTT + TLS's 1-2 RTT), multiplexed streams without head-of-line blocking, built-in TLS 1.3 encryption (no separate TLS handshake), and connection migration (your download continues seamlessly when you switch from Wi-Fi to mobile data because QUIC connections are identified by connection ID, not IP/port). QUIC is now used by Chrome, Firefox, Cloudflare, Google, Meta, and Akamai for the majority of their traffic.
🎥 WebRTC
WebRTC (Web Real-Time Communication) is the protocol that powers in-browser video calls, screen sharing, and peer-to-peer file transfers without plugins. It uses UDP for media (via SRTP, the encrypted version of RTP) and SCTP over DTLS for data channels. WebRTC includes its own NAT traversal via ICE (Interactive Connectivity Establishment), STUN, and TURN servers, allowing direct peer-to-peer UDP connections even through NAT. Google Meet, Jitsi, and all browser-based video call tools use WebRTC.
🔐 DTLS (Datagram TLS)
TLS encrypts TCP streams. DTLS (Datagram Transport Layer Security) is the equivalent for UDP. It provides the same certificate-based authentication and symmetric encryption as TLS but handles the stateless, out-of-order nature of UDP datagrams. WebRTC uses DTLS for encrypting its signaling and data channels. DTLS is also used in IoT protocols and VPN implementations that run over UDP.
🎯 SCTP (Stream Control Transmission Protocol)
SCTP is a lesser-known third transport protocol that combines features of both TCP and UDP. It provides reliable, ordered delivery like TCP but supports multiple independent streams within a single connection (no head-of-line blocking between streams). It also supports multi-homing (a connection can use multiple IP addresses simultaneously). SCTP is used in telecommunications signaling (SS7 over IP) and was adopted by WebRTC for its data channel. It is not widely used in general internet applications due to NAT traversal challenges.
Tunneling TCP and UDP Traffic with Localtonet
When you build an application that uses UDP (a game server, a VoIP service, a real-time data feed) and want it accessible from the internet without port forwarding or a static IP, you need a tunnel that supports UDP natively. This is where many tunnel services fall short. Ngrok's free tier does not support UDP. Cloudflare Tunnel does not support UDP. Localtonet supports both TCP and UDP tunnels natively.
Tunneling UDP is fundamentally harder than tunneling TCP. A TCP tunnel can maintain a persistent connection and forward packets reliably. A UDP tunnel must handle stateless, unreliable packets across a reliable transport, managing packet timing, ordering, and loss in a way that preserves the application's expected behavior. Localtonet's native UDP tunnel support handles this transparently.
Creating a TCP or UDP Tunnel with Localtonet
Install and authenticate Localtonet
# macOS:
brew tap localtonet/tap && brew install localtonet
# Linux:
curl -fsSL https://localtonet.com/install.sh | sh
# Authenticate:
localtonet --authtoken YOUR_TOKEN_HEREGo to the TCP-UDP tunnel page
Select the protocol and configure
Choose TCP, UDP, or TCP-UDP Mixed (for applications that use both). Enter IP 127.0.0.1 and the port your application uses. Select your AuthToken and server. Click Create, then Start.
Use the public endpoint
The dashboard shows your public address (e.g., us1.localtonet.com:34521). Point any client at this address to reach your local application.
TCP Tunnel Use Cases
| Application | Default Port | Why TCP |
|---|---|---|
| SSH access to home server | 22 | Reliable shell session, file transfer via SCP/SFTP |
| Database access (MySQL, PostgreSQL) | 3306 / 5432 | Query results must arrive complete and in order |
| Remote ADB debugging | 5555 | ADB uses TCP for reliable device communication |
| Minecraft Java Edition server | 25565 | World data and inventory must be reliable |
| Custom TCP API server | Any | Protocol relies on stream ordering |
UDP Tunnel Use Cases
| Application | Default Port | Why UDP |
|---|---|---|
| Game server (CS2, Valheim, Rust) | 27015-27020 | Position updates are time-sensitive, loss is tolerable |
| Voice chat server (Mumble, TeamSpeak) | 64738 / 9987 | Audio is real-time, latency matters more than perfection |
| WireGuard VPN | 51820 | WireGuard is designed exclusively for UDP |
| DNS server | 53 | Single-packet request/response, retries are fast |
| IoT sensor data collector | Any | Continuous readings, missed one is replaced by next |
| SRT live stream ingest | Any | Low-latency live video requires UDP |
TCP-UDP Mixed Tunnel Use Cases
Some applications use both TCP and UDP simultaneously, for different types of traffic within the same service. The Localtonet TCP-UDP Mixed tunnel creates a single public endpoint that accepts both protocols on the same port.
| Application | TCP Used For | UDP Used For |
|---|---|---|
| Minecraft Bedrock Edition | Login, inventory sync | World movement and gameplay |
| VoIP server (FreeSWITCH, Asterisk) | SIP signaling | RTP voice media |
| Game server with chat | Chat, authentication | Gameplay state updates |
| WebRTC server | HTTPS signaling | DTLS media streams |
TCP and UDP Tunnel Support: Localtonet vs Alternatives
| Service | TCP Tunnel | UDP Tunnel | TCP-UDP Mixed | HTTP Tunnel |
|---|---|---|---|---|
| Localtonet | ✓ | ✓ | ✓ | ✓ |
| ngrok (free) | ✓ | ✕ | ✕ | ✓ |
| ngrok (paid) | ✓ | ✕ | ✕ | ✓ |
| Cloudflare Tunnel | HTTP/HTTPS only | ✕ | ✕ | ✓ |
| Tailscale Funnel | HTTPS only | ✕ | ✕ | ✓ |
| Pagekite | ✓ | ✕ | ✕ | ✓ |
Frequently Asked Questions
What is the main difference between TCP and UDP?
TCP (Transmission Control Protocol) guarantees that every packet arrives in order and without errors, using acknowledgments and retransmission. This makes it slower but reliable. UDP (User Datagram Protocol) sends packets with no delivery guarantee, no ordering, and no retransmission, making it faster but unreliable. TCP is used for web browsing, email, and file transfers. UDP is used for gaming, video calls, live streaming, and DNS.
Is UDP faster than TCP?
Yes, for latency-sensitive traffic. UDP has a fixed 8-byte header (vs TCP's 20-60 bytes), no connection setup delay, no ACK round trips, and no retransmission stalls. For applications like online gaming, UDP can provide 20-50 ms latency while TCP might add 100-200 ms due to acknowledgments and error correction. For bulk data transfer over a reliable network, throughput differences are smaller because TCP's congestion control algorithms (like BBR) are highly optimized.
Why do online games use UDP instead of TCP?
Games send position updates and input events 30-128 times per second. If a packet from 33 milliseconds ago is lost, retransmitting it via TCP would cause the stream to pause and wait, introducing noticeable input lag. With UDP, a missed packet is simply skipped and the next update provides the current state. Games handle packet loss with interpolation and delta compression at the application layer. The occasional missing frame is invisible to players, while TCP-caused delays directly ruin gameplay.
What is QUIC and how does it relate to TCP and UDP?
QUIC is a transport protocol developed by Google and standardized as HTTP/3 (RFC 9000). It runs over UDP but reimplements TCP's reliability features (ordering, retransmission, flow control, congestion control) at the application layer, while fixing TCP's core weakness: head-of-line blocking. In QUIC, multiple independent streams share a connection, and a lost packet only blocks its own stream, not all streams. QUIC also includes mandatory TLS 1.3 encryption and supports 0-RTT resumption. Chrome, Firefox, and major CDNs use QUIC for over 25% of internet traffic.
Can I tunnel UDP traffic over the internet?
Yes, with the right tunnel service. Localtonet supports native UDP tunnels, TCP tunnels, and TCP-UDP mixed tunnels. Create a UDP tunnel at localtonet.com/tunnel/tcpudp, select UDP as the protocol, enter your local port, and start the tunnel. You get a public hostname and port that forwards UDP traffic directly to your local application. Most other tunnel services (ngrok, Cloudflare Tunnel, Tailscale Funnel) do not support UDP tunneling.
Why is UDP harder to traverse NAT than TCP?
NAT (Network Address Translation) routers maintain state tables that map internal IP/port pairs to external ports. For TCP, the three-way handshake creates a clear session that the NAT can track. For UDP, there is no handshake, so NAT routers must guess when to create and expire entries. Inbound UDP packets (from a server to a client) must arrive while the NAT entry is still active. This window is typically 30-180 seconds for UDP vs 2-7 days for established TCP connections. Solutions include UDP hole punching (used by WebRTC), STUN/TURN servers, or a tunnel service like Localtonet that handles NAT traversal automatically.
Does DNS use TCP or UDP?
DNS primarily uses UDP on port 53 for standard queries because requests and responses are small (under 512 bytes) and a single round trip is sufficient. If a DNS response exceeds 512 bytes (common for DNSSEC-signed records or zone transfers), the resolver falls back to TCP on port 53. DNS over HTTPS (DoH) and DNS over TLS (DoT) use TCP exclusively and add encryption. DNS over QUIC (DoQ) uses UDP via QUIC. The short answer for everyday DNS queries: UDP, on port 53.
Tunnel Both TCP and UDP from Your Local Machine
Localtonet is the only major tunnel service with native UDP support. Expose game servers, VoIP services, IoT devices, and any TCP or UDP application to the internet without port forwarding. Free to start.
Get Started Free →