The Linux Programming Interface

1282 Chapter 61

61.12 TCP Versus UDP

Given that TCP provides reliable delivery of data, while UDP does not, an obvious

question is, “Why use UDP at all?” The answer to this question is covered at some

length in Chapter 22 of [Stevens et al., 2004]. Here, we summarize some of the

points that may lead us to choose UDP over TCP:

z A UDP server can receive (and reply to) datagrams from multiple clients, with-

out needing to create and terminate a connection for each client (i.e., transmis-

sion of single messages using UDP has a lower overhead than is required when

using TCP).

z For simple request-response communications, UDP can be faster than TCP,

since it doesn’t require connection establishment and termination. Appendix A

of [Stevens, 1996] notes that in the best-case scenario, the time using TCP is

2 * RTT + SPT

In this formula, RTT is the round-trip time (the time required to send a request

and receive a response), and SPT is the time spent by the server processing the

request. (On a wide area network, the SPT value may be small compared to the

RTT.) For UDP, the best-case scenario for a single request-response communi-

cation is

RTT + SPT

This is one RTT less than the time required for TCP. Since the RTT between

hosts separated by large (i.e., intercontinental) distances or many intervening

routers is typically several tenths of a second, this difference can make UDP

attractive for some types of request-response communication. DNS is a good

example of an application that uses UDP for this reason—using UDP allows

name lookup to be performed by transmitting a single packet in each direction

between servers.

z UDP sockets permit broadcasting and multicasting. Broadcasting allows a

sender to transmit a datagram to the same destination port on all of the hosts

connected to a network. Multicasting is similar, but allows a datagram to be sent

to a specified set of hosts. For further details see Chapters 21 and 22 of

[Stevens et al., 2004].

z Certain types of applications (e.g., streaming video and audio transmission)

can function acceptably without the reliability provided by TCP. On the other

hand, the delay that may occur after TCP tries to recover from a lost segment

may result in transmission delays that are unacceptably long. (A delay in

streaming media transmission may be worse than a brief loss of the transmission

stream.) Therefore, such applications may prefer UDP, and adopt application-

specific recovery strategies to deal with occasional packet loss.

An application that uses UDP, but nevertheless requires reliability, must imple-

ment reliability features itself. Usually, this requires at least sequence numbers,

acknowledgements, retransmission of lost packets, and duplicate detection. An

example of how to do this is shown in [Stevens et al., 2004]. However, if more