Two ways to transport data
When an application sends data across an IP network, it commonly uses TCP or UDP as its transport protocol. Both use port numbers to help a device deliver incoming traffic to the right application. Neither can guarantee that the underlying network will deliver every packet. The key difference is what each protocol does when packets are delayed, lost or received out of order.
TCP provides an ordered byte stream. To an application reading that stream, bytes arrive in the order they were sent, without duplicates. TCP establishes a connection before exchanging application data and manages acknowledgments, retransmissions and flow control. UDP sends individual messages called datagrams without establishing a transport connection first. A UDP datagram might arrive, arrive late, arrive more than once or never arrive at all. UDP itself does not correct those outcomes.
What reliability costs—and what it saves
TCP’s reliability is useful when missing or reordered bytes would make the result unusable. Think of loading a document, transferring a file or submitting a form: the receiving application needs the complete content, not an approximation. TCP also adjusts how much it sends in response to network conditions, and its flow control helps avoid overwhelming a receiver.
Those mechanisms have costs. Establishing a TCP connection requires an exchange before application data can flow. If data is lost, retransmitting it takes time. Because TCP presents bytes in order, later bytes may be held back while an earlier missing portion is recovered. That behavior is sensible for a file but can be frustrating for information that loses value quickly, such as a player’s position in a live game.
UDP has a smaller transport header and does not require a transport handshake or wait to repair missing datagrams. That does not mean UDP is always faster: network congestion, application processing and any reliability features built on top of UDP still affect performance. It means an application can choose how to handle loss and timing rather than accepting TCP’s ordered-delivery behavior.
How applications use each protocol
Traditional HTTP traffic commonly runs over TCP, often with TLS added for encryption. File transfer and email protocols also commonly use TCP because complete, ordered data matters. A browser does not normally want half a page’s script or an incomplete download treated as a successful result.
UDP often suits short exchanges or time-sensitive updates. DNS queries commonly use UDP, though DNS can also use TCP. Voice calls, live media and multiplayer games may use UDP when a fresh update is more useful than a delayed retransmission of an old one. The application can add features such as sequence numbers, buffering or selective recovery where needed.
These examples are not rigid rules. QUIC, which is used by HTTP/3, runs over UDP but implements its own connection management, congestion control and reliable delivery where required. So “uses UDP” does not necessarily mean “unreliable application.” The behavior users experience depends on the full protocol stack, not just the transport named in a packet.
Packets, messages and practical limits
TCP is a stream, not a message service. If a sender writes two pieces of data, the receiver might read them in one operation or across several. An application protocol must define its own message boundaries, perhaps with a length field or delimiter. TCP preserves byte order, but it does not preserve the sender’s write boundaries.
UDP preserves datagram boundaries: one received datagram corresponds to one sent datagram, if it arrives. That convenience comes with a size consideration. A datagram that exceeds the usable path size may require IP fragmentation or fail to get through. Keeping datagrams appropriately sized, and designing for loss, helps avoid assuming that a message will arrive simply because it was sent.
Choosing the right fit
Start with what the receiving application needs. If every byte must arrive in order and the application can tolerate waiting for missing data, TCP is often the straightforward choice. If updates expire quickly or messages should be handled independently, UDP may offer more flexibility. Then ask who will handle lost messages, congestion, security and connection state. With UDP, those responsibilities may need to be addressed by the application or a higher-level protocol.
A useful mental model is that TCP prioritizes delivering an intact, ordered stream, while UDP prioritizes sending separate datagrams with fewer transport-level promises. Neither protocol can make a slow or overloaded network disappear. The better choice is the one whose behavior matches what the application should do when the network is imperfect.
