TCP vs UDP: differences and when to use each

TCP (Transmission Control Protocol) opens a connection with a handshake, then delivers a reliable, ordered stream of bytes. It resends lost data and slows down when the network is congested. UDP (User Datagram Protocol) sends independent messages called datagrams and leaves reliability to the application.

Both run on top of IP, both use port numbers to reach the right program, and both carry a checksum to catch corrupted data. Anything else TCP does, an application on UDP has to build for itself if it needs it.

Before sending data, TCP runs a three-way handshake. The client sends SYN, the server answers SYN-ACK and the client replies ACK, which agrees on starting sequence numbers in both directions. That costs one round trip before the client can send its request.

HTTPS adds a TLS handshake on top: one more round trip with TLS 1.3, two with TLS 1.2. Closing a connection takes its own exchange of FIN messages.

UDP has no handshake. An ordinary DNS query is one datagram out and one back, which is why DNS uses UDP for most lookups. The server never confirms who sent a datagram, though, so attackers can forge source addresses and point large replies from DNS or NTP servers at a victim.

TCP numbers every byte it sends. The receiver acknowledges what has arrived, and the sender retransmits anything not acknowledged in time. Data reaches the application complete and in order, or the connection fails with an error.

Two mechanisms set the sending rate. Flow control protects the receiver: it advertises a window, the amount of data it can buffer, and the sender stays within it. Congestion control protects the network: the sender starts slowly, speeds up while data gets through and backs off when it sees loss or rising delay.

UDP has none of this. RFC 8085 asks applications that send a lot of data over UDP to add their own congestion control, so they do not swamp shared links.

Because TCP delivers bytes strictly in order, one lost segment holds back everything behind it until the retransmission arrives, including data that already reached the receiver. This is head-of-line blocking.

For a single file download it barely matters. It matters when one connection carries many independent things: HTTP/2 multiplexes many requests over one TCP connection, so a single lost packet stalls all of them.

For live audio and video, a packet that arrives late is as useless as a lost one. A call is better off skipping it and playing the next. QUIC, which carries HTTP/3, runs over UDP for a related reason: it recovers lost data for each stream separately.

Most applications should start with TCP, or with QUIC through a library. Choose raw UDP when timeliness matters more than completeness, and accept that loss handling, congestion control and security become your job. Some networks also block most UDP traffic, which is one reason browsers keep HTTP/2 as a fallback for HTTP/3.