TCP delivers application data as a reliable, in-order byte stream; UDP delivers it as individual datagrams without TCP’s built-in reliable ordering. Neither is universally better. The right choice depends on what an application needs from its transport—and whether the application or another protocol supplies capabilities UDP does not.
TCP and UDP at a glance
| Question | TCP | UDP |
|---|---|---|
| What an application receives | A reliable, in-order byte stream. The current TCP specification, IETF RFC 9293 (August 2022), describes TCP as providing “a reliable, in-order, byte-stream service to applications.” | Datagrams. UDP does not itself provide TCP’s reliable, ordered byte-stream service, as defined in IETF RFC 768 (August 1980). |
| What happens when data is lost | TCP detects loss and retransmits data so the stream can be delivered reliably and in order. | UDP does not provide TCP’s retransmission-based ordered-stream guarantee. An application can decide how to handle loss or add its own mechanisms above UDP. |
| How the transport is organized | Connection-oriented. RFC 9293 notes that TCP does not inherently include liveness detection. | Datagram-based. The lack of TCP-style connection setup does not mean UDP applications will always be faster. |
| Main tradeoff | The transport supplies reliable ordering, but a missing earlier segment can delay delivery of later data. | The application gets datagrams and more control over loss handling, but must tolerate loss or provide any additional behavior it needs. |
How TCP’s reliable stream affects delivery
TCP presents data to an application as a continuous byte stream, not as a series of separate messages. It detects delivery problems and retransmits lost data to maintain the stream’s reliability and order.
![Computer Networking Bible: [3 in 1] The Complete Crash Course to Effectively Design, Implement and Manage Networks. Including Sections on Security, Performance and Scalability](https://m.media-amazon.com/images/I/41H4YJnxKgL._SL160_.jpg)
That ordering has a cost when data is lost: later data may arrive, but TCP holds it back from the application until the missing earlier data is retransmitted. This is called head-of-line blocking. It can make waiting worthwhile when the application needs complete, correctly ordered data, but less useful when delayed information has become stale.
TCP is connection-oriented, but a connection is not itself a guarantee that the other endpoint is still responsive. RFC 9293 says TCP does not inherently include liveness detection; an application may need separate logic if it must detect an unresponsive peer.
#1 Best Overall
What UDP leaves to the application
UDP exposes datagrams rather than TCP’s reliable, in-order byte stream. The application must be prepared for the delivery behavior it needs: for example, it can accept datagram loss, arrange retransmission itself, or use another protocol layer that adds reliability and ordering.
This is a division of responsibility, not a rule that every UDP-based application is unreliable. UDP is a suitable foundation when an application can use datagrams directly or has a reason to control transport behavior itself. The application and any protocols layered above UDP determine how missing, delayed, or reordered data is handled.
Examples: streaming, DNS, and QUIC
Streaming and interactive media
It is too broad to say that streaming always uses UDP. With TCP, a lost segment can hold later data back while retransmission occurs. For time-sensitive media, waiting for old data may be less useful than moving on, but using UDP shifts loss handling to the application and its surrounding protocol. UDP traffic can also be blocked on some networks. IETF RFC 9317 (October 2022) discusses these operational tradeoffs and multiple media transport approaches.
DNS
DNS is not UDP-only. IETF RFC 9210 (March 2022) says DNS resolvers and recursive servers must support UDP and should support TCP for non-zone-transfer queries. Larger DNS messages and other operational needs make TCP transactions important to DNS operation.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesQUIC
QUIC shows why “UDP is unreliable” does not describe every protocol built on it. IETF RFC 9000 (May 2021) specifies QUIC as a multiplexed transport over UDP. UDP carries QUIC packets, while QUIC implements transport functions such as stream multiplexing and acknowledgments at its own layer. Those capabilities are not provided by raw UDP itself.
How to choose between TCP and UDP
- Choose TCP when the application needs the transport to provide a reliable, in-order stream.
- Choose UDP when datagrams suit the application and it can tolerate or manage delivery behavior itself, or when a protocol above UDP provides the additional functions it needs.
- Evaluate the whole protocol stack for media, interactive services, and other latency-sensitive uses. Consider what happens under loss, whether delayed data remains useful, and whether UDP traffic is allowed on the networks in question.
Is TCP faster than UDP?
There is no universal speed winner established by these protocol specifications and operational guidance. TCP’s retransmission and ordered delivery can mean waiting after loss; UDP avoids TCP’s built-in ordered-stream behavior, but leaves delivery choices to the application. The result depends on application requirements, network conditions, and any functions implemented above UDP. A claim that UDP is always faster—or that TCP is always slower—leaves out those deciding factors.
Quick Recap
Best Value
- Used Book in Good Condition
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
