TCP vs UDP Compared

TCP vs UDP comes down to one trade-off: choose TCP when every byte must arrive complete and in order, and UDP when speed matters more than occasional data loss, as in a live video call.

Picture two laptops on the same network. One downloads a file and must receive every byte intact. The other runs a video call and only needs the next moment of audio to arrive quickly. That contrast explains most of the TCP and UDP differences below, and it is a core topic for anyone working through how to prepare for ccna.

Decision criteria before the comparison

The right protocol follows from what the application cannot tolerate. Work through these checks in order, and stop at the first one that settles the choice.

Check whether missing or reordered data breaks the result. Without TCP, images or text could be missing or arrive in the wrong order, so web pages, email and file transfers need it.
Check whether some loss is acceptable. UDP suits situations where some data loss is acceptable, such as live video and audio.
Check how much delay the application can absorb. TCP’s checking and resending adds latency, which is a problem when speed matters more than completeness.
Check whether you need connection setup. TCP establishes a connection before any data moves. UDP does not, so it starts sending immediately but offers no delivery guarantee.

If the first check fails, the answer is TCP. If the second and third both apply, the answer is UDP. Mixed cases are covered under edge cases later here.

Where TCP and UDP sit in the protocol stack

TCP and UDP are both major protocols within the internet protocol suite. Applications such as browsers, mail clients and video-call software hand their data to one of the two, and the choice decides how that data is delivered across the network.

Treat them as alternatives for the same job, which is carrying application data between devices. They differ in how much work they do on the way. TCP does more checking and so is more reliable. UDP does less and is much simpler, as freeCodeCamp’s TCP vs UDP explainer puts it.

TCP and UDP differences side by side

The table compares the two protocols on the criteria that most often decide a design or an exam answer.

An ordinary laptop stands in for any end device: both protocols run on the devices at either end of a conversation. The screen is dark, so the photo illustrates hardware only, not captured traffic.

Criterion	TCP	UDP	Planning use
Connection	Connection-oriented: a connection is established before data transfer	Connectionless: no connection beforehand	Pick TCP if both ends must agree before data flows.
Delivery	Lost packets are reported by the receiver so the sender can resend them	No guarantee that all data is successfully transferred	Pick UDP only if the application can live with gaps.
Ordering	Data must arrive in the correct order	No ordering described as a feature	Ordered content such as text and images points to TCP.
Speed and latency	Checking and resending adds latency	Generally the faster protocol	Latency-sensitive traffic points to UDP.
Reliability	Extremely reliable	Less reliable, but much simpler	Reliability needs push toward TCP; simplicity pushes toward UDP.
Typical uses	Web browsing (HTTP), email (SMTP), file transfer (FTP)	Live video and audio, online games	Match the application to its usual transport.

These characterisations follow freeCodeCamp’s comparison of the two protocols.

The table also shows why “faster” does not mean “better”. UDP is quicker because it skips the work that makes TCP dependable. Whether that trade is worthwhile depends entirely on what the application does with the data.

How the TCP three-way handshake works

The three-way handshake is how TCP establishes a connection before any application data is sent. It uses three short messages, each with a name that appears as a flag in a packet capture.

The editor’s file sidebar lists names such as README and arcadia.todo.

SYN from the client. The client device first sends a message called a SYN to the server it wants to reach.
SYN-ACK from the server. The server replies with an acknowledgement message called a SYN-ACK.
ACK from the client. The client sends an ACK acknowledgement back, which establishes the connection.

Only after the third message does data transfer begin. This is the setup cost behind TCP’s reliability. Once the connection exists, TCP lets the receiving device tell the server about any packets lost along the way so the missing data can be resent.

When you open a packet capture in a tool such as Wireshark and filter for TCP, the first three packets of a new conversation show this SYN, SYN-ACK, ACK pattern. Recognising it is a common exam skill and a practical way to confirm that a server is reachable.

A backlit keyboard as a generic workstation image. In a real capture, the handshake appears as three consecutive packets carrying the SYN, SYN-ACK and ACK flags.

How UDP exchanges data without a connection

UDP, the User Datagram Protocol, sends data as datagrams without establishing a connection beforehand. There is no handshake, so the first packet a UDP application sends already carries data.

This is why UDP is also known as the “fire-and-forget” protocol. The sender transmits and moves on, and UDP itself does not guarantee that all data is successfully transferred. In a capture, a UDP exchange therefore looks like data packets alone, with none of the SYN and ACK setup traffic that precedes a TCP conversation.

The simplicity is the feature. Without setup, acknowledgement and resending, UDP adds less delay and asks less of both endpoints. That suits traffic where a late packet is worth less than a missing one.

Which applications use TCP and which use UDP

Applications that need complete, ordered data use TCP, and applications that favour speed over completeness use UDP.

Web browsing, email and file transfer use TCP. HTTP, SMTP and FTP all rely on its reliability.
Streaming video sites use TCP. YouTube and Netflix send data to your devices over TCP.
Video calls use UDP. On Google Meet or Zoom, your video and audio are transmitted over UDP.
Online games and live media favour UDP. UDP is the better choice for live video, audio and online games where speed is more important than perfect delivery.

Illustrative only: a file download on one laptop would travel over TCP, while the media on a call from another would travel over UDP.

Choosing between them: who each suits

TCP suits anything where an error in the data is worse than a short wait, and UDP suits anything where a short wait is worse than an error in the data.

Choose TCP when

You are building or troubleshooting web, email or file-transfer services. Correctness comes first, and the latency from checking and resending is an acceptable price.

Choose UDP when

You are dealing with live audio, live video or games, where the application keeps moving even if a little data is lost. Expect the application, not the protocol, to cope with any gaps.

Edge case: video over TCP

Video is not automatically a UDP workload. YouTube and Netflix deliver video over TCP, while live calls on Zoom or Google Meet use UDP. The difference is liveness. Content that can be delivered ahead of playback tolerates TCP’s overhead, whereas a live conversation cannot wait for resent data.

Frequently asked questions

Question	Answer
What do TCP and UDP stand for?	TCP stands for Transmission Control Protocol, and UDP stands for User Datagram Protocol. A datagram is the unit of data UDP sends.
Why is UDP called fire-and-forget?	UDP sends data without establishing a connection first and without guaranteeing delivery, so the sender does not wait to confirm that anything arrived.
How is a TCP connection closed?	Closing uses FIN and ACK packets, mirroring the acknowledgement style of the opening handshake.
Is UDP always faster than TCP?	In general, UDP is the faster protocol. TCP’s checking and resending of data adds latency, which UDP avoids by doing less.