TCP vs UDP: What's the Difference?
TCP and UDP are two ways computers send data across a network. TCP (Transmission Control Protocol) is reliable and ordered: it confirms every packet arrives and puts them in sequence, making it ideal for web pages, email, and file transfers. UDP (User Datagram Protocol) is fast and connectionless: it fires packets without confirmation, accepting occasional loss in exchange for speed, which suits video calls, live streaming, gaming, and DNS lookups. TCP prioritizes accuracy; UDP prioritizes speed and low latency.
- TCP
- Reliable, ordered, connection-based; confirms delivery (IETF RFC 9293)
- UDP
- Fast, connectionless; no delivery guarantee (IETF RFC 768)
- TCP uses
- Web (HTTP/1.1 and HTTP/2), email (SMTP), file transfer, SSH
- UDP uses
- DNS lookups, video/voice calls, live streaming, online games
- Handshake
- TCP opens with a three-way handshake; UDP just sends
- HTTP/3
- Runs on QUIC, which is built on UDP for lower latency (web.dev)
What these transport protocols are #
TCP and UDP are the two main transport protocols of the internet, the layer that decides how data actually moves between two computers once an address is known. Every time you load a page, watch a video, or send an email, one of these protocols carries the bytes. TCP, the Transmission Control Protocol, is the careful courier: it establishes a connection, numbers every packet, and guarantees the recipient gets them all, in order, resending anything lost. UDP, the User Datagram Protocol, is the fast courier: it throws packets onto the network without setting up a connection or waiting for confirmation, accepting that a few may go missing. Neither is better overall; they are tuned for opposite priorities, reliability versus speed, and applications pick whichever fits. Understanding the split explains why a webpage never arrives half-scrambled but a video call can glitch briefly and keep going. Our /services/managed-hosting and /services/vps-cloud-setup teams configure servers to handle both correctly, since real sites and services depend on each.
How TCP works #
TCP behaves like a phone call: before any data flows, the two computers establish a connection through a three-way handshake, a quick exchange that agrees they are both ready. Once connected, TCP numbers each packet so the receiver can reassemble them in the exact order sent, even if the network delivers them jumbled. Critically, the receiver acknowledges what it gets, and if TCP notices a packet was lost, it resends it, guaranteeing complete, accurate delivery. It also manages flow control and congestion control, slowing down when the network is busy so it does not overwhelm the connection. This reliability is why TCP underpins the web, email, and file transfers, anywhere a single missing byte would corrupt the result. A half-downloaded file or a webpage with random gaps would be useless, so accuracy must come first. The cost is overhead: the handshake, acknowledgments, and retransmissions add latency and work. For most everyday internet tasks that trade is entirely worth it, which is why TCP carries the majority of web traffic.
How UDP works #
UDP behaves like shouting across a room: there is no handshake, no connection, and no confirmation. A computer simply sends packets, called datagrams, toward a destination and moves on, never checking whether they arrived or in what order. This sounds reckless, but it is exactly right for certain jobs. In a live video call, if one frame's worth of data is lost, resending it would be pointless; by the time it arrived, the conversation would have moved on, so UDP just skips it and keeps going, producing a brief glitch instead of a growing delay. That is the core insight: for real-time media, timely delivery matters more than perfect delivery. UDP's lack of overhead makes it fast and lightweight, ideal for DNS lookups, where a tiny query and reply need to be as quick as possible, and for online games and streaming, where low latency wins. The trade-off is that reliability, if needed, must be handled by the application itself, which is precisely what newer protocols built on UDP do.
Reliable versus fast in code #
At the programming level the choice is a single flag when opening a network socket, which cleanly captures the philosophy of each protocol.
# TCP: reliable, ordered stream (web, email, file transfer)
socket(AF_INET, SOCK_STREAM) # SOCK_STREAM = TCP
# UDP: fast, connectionless datagrams (DNS, video, games)
socket(AF_INET, SOCK_DGRAM) # SOCK_DGRAM = UDP
# Typical ports reflect the split:
# HTTPS 443/tcp SSH 22/tcp SMTP 25/tcp
# DNS 53/udp QUIC/HTTP3 443/udpHead-to-head comparison #
Laid side by side, the differences are consistent and predictable. On reliability, TCP guarantees delivery and resends lost packets, while UDP offers no guarantee and drops what is lost. On ordering, TCP reassembles packets in sequence, while UDP may deliver them out of order or not at all. On connection, TCP requires a handshake before sending, while UDP just fires datagrams immediately. On speed and latency, UDP is lighter and faster because it skips all that bookkeeping, while TCP trades some speed for certainty. On overhead, TCP's headers and acknowledgments are heavier; UDP's are minimal. The result is a clean rule of thumb: if losing any data would break the result, use TCP; if timeliness beats completeness, use UDP. This is why a downloaded invoice must arrive intact over TCP, but a live sports stream tolerates a momentary blur over UDP rather than freezing to wait. Applications rarely make you choose manually; the protocol is baked into the service you use, but knowing the trade explains a lot of everyday internet behavior.
Where each shows up on the web #
You use both protocols constantly without realizing it. When you load a website, the HTML, CSS, images, and scripts arrive over TCP, because a page must be complete and correct. Email delivery, file downloads, and secure shell connections all rely on TCP for the same reason. UDP, meanwhile, quietly powers the plumbing and the real-time layer: nearly every DNS lookup, the step that turns a domain name into an IP address before anything else happens, uses UDP for speed, a process our /services/domains-dns-email work manages. Video conferencing, voice-over-IP calls, live streaming, and online games lean on UDP so a lost packet becomes a brief hiccup rather than a mounting delay. Even ad-hoc network discovery and time synchronization use it. So a single session of browsing, calling, and streaming touches both protocols dozens of times. The internet is not TCP or UDP; it is both, each carrying the traffic it is best suited to, often within the very same application at different moments.
The QUIC and HTTP/3 twist #
The neat TCP-versus-UDP divide has an interesting modern wrinkle. For decades the web ran on TCP because reliability was essential, but TCP's handshake and its habit of stalling all data when one packet is lost, called head-of-line blocking, added latency. Engineers wanted TCP's reliability with less of its delay, so they built QUIC, a new protocol that runs on top of UDP. QUIC adds its own reliability, ordering, and encryption in software, getting the guarantees of TCP while using UDP's lightweight, connectionless base to reduce latency and handle packet loss per stream. HTTP/3, the newest version of the web's core protocol, runs on QUIC, meaning cutting-edge web traffic now travels over UDP rather than TCP, reversing the old assumption. This does not make TCP obsolete; it still carries most traffic today. But it shows the categories are tools, not dogma: reliability can be layered onto UDP when latency matters enough. Our /services/speed-optimization team tracks these shifts so client sites benefit from lower-latency delivery as HTTP/3 adoption grows.
Ports, protocols, and how services find each other #
TCP and UDP do not work alone; they pair with port numbers to direct traffic to the right service on a machine. An IP address gets data to the correct computer, and the port number, combined with the protocol, gets it to the correct program on that computer. Web servers listen on TCP port 443 for HTTPS and 80 for plain HTTP, mail servers on TCP port 25, and DNS on UDP port 53, so the same server can run many services at once without confusion. This is why a firewall rule is written as a combination of protocol, port, and direction, and why opening the wrong port, or leaving one open, has security implications our /services/website-security reviews check. When a service seems unreachable despite the server being online, a blocked or misconfigured port for the relevant protocol is a frequent culprit. Understanding that TCP and UDP each carry many numbered services explains how one machine juggles web, mail, and DNS traffic simultaneously without the streams ever getting tangled or misdirected.
What this means for your website #
For a business owner, TCP and UDP operate far below anything you configure, but their behavior explains real experiences and occasional problems. Your website's pages, forms, and downloads ride TCP, which is why they arrive intact; if DNS, which uses UDP, is misconfigured, your site may fail to resolve at all even though the server is fine, a common cause of mysterious outages our /services/domains-dns-email team diagnoses. If you run video, voice, or live chat features, those depend on UDP, and firewalls that block UDP can silently break them. You will never choose a protocol by hand, but knowing the distinction helps you ask the right questions when something misbehaves and understand why a live stream tolerates a glitch while a page never loads half-broken. If your site or its supporting services are acting up in ways that point to networking, a /free-website-audit can help pin down whether the issue lies in DNS, hosting, or the application layer built on top of these protocols.
FAQ
Is TCP or UDP faster?
UDP is faster because it skips the handshake, acknowledgments, and retransmissions that TCP performs. It simply sends packets without waiting for confirmation, giving lower latency and less overhead. The trade-off is reliability: UDP does not guarantee delivery or order. TCP is slightly slower but ensures every packet arrives correctly, which most everyday internet tasks require.
Why does the web use TCP?
The web uses TCP because pages, files, and emails must arrive complete and in order; a single missing byte could corrupt them. TCP guarantees delivery by confirming packets and resending lost ones. That reliability outweighs the small speed cost. Newer HTTP/3 uses QUIC over UDP but rebuilds reliability itself, keeping the guarantees the web needs.
What uses UDP?
UDP powers DNS lookups, video and voice calls, live streaming, and online games, tasks where speed and low latency matter more than perfect delivery. In real-time media, resending a lost packet is pointless because the moment has passed, so UDP skips it and keeps going. Modern QUIC and HTTP/3 traffic also run on UDP.
Can UDP be made reliable?
Yes, by adding reliability in the application layer on top of UDP. This is exactly what QUIC does: it uses UDP's fast, connectionless base but adds its own delivery confirmation, ordering, and encryption. That gives TCP-like guarantees with lower latency. So UDP itself is unreliable, but software built on it can provide reliability when needed.
Does UDP work through firewalls?
It can, but firewalls sometimes block or restrict UDP more aggressively than TCP because UDP is connectionless and harder to track. This can silently break UDP-based features like video calls or certain streaming. If a real-time service fails while web pages load fine, an overly strict firewall blocking UDP ports is a common cause worth checking.
Which should I choose for my application?
Choose TCP when losing any data would break the result, such as forms, downloads, or transactions. Choose UDP when timeliness beats completeness, such as live video, voice, or gaming. Most web applications use TCP by default. In practice the protocol is dictated by the service you build, so the decision is usually made for you.
How Local Web Advisor checks this for you
Is your own website getting web tech right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web tech and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?