NetBurner 3.3.4
PDF Version
TCP vs UDP

A very common question that arises when designing a network application is whether to use TCP (Transmission Control Protocol) or UDP (User Datagram Protocol). There are a few guidelines and features that can determine which would be the preferred protocol.

TCP is a point to point stream based protocol. It is used in applications where reliability and data sequencing is needed: acknowledgments, error detection, re-transmission of data, and will guarantee the data received will be sequenced in the same order as it was sent.

UDP is a connectionless protocol that does not guarantee delivery or data packet sequence (although each segment is numbered). It is a send and forget protocol that does not use acknowledgments. A common comparison is that TCP is similar to a phone call and UDP is similar to a post card. With TCP, you connect to a specific destination phone number. When that person answers, they say "hello", you say "Hi, my name is Bob", and then the conversation continues with each side speaking and responding (in a well-behaved conversation!). With UDP you essentially transmit a datagram, like writing on a post card, and send it without verifying it was received.

When choosing between TCP and UDP, some major concerns are the overhead it takes to establish a TCP connection, speed and the reliability of data transmission. For example, SNMP uses UDP. SNMP is used to monitor networks, and many messages are sent and received for status updates and alerts. If TCP were used, the overhead of establishing, maintaining and closing a connection for each message and each host would create a lot of unnecessary traffic. A second example of when UDP is a better choice is when an application handles its own reliability at the application layer. Using TCP in this instance would be redundant.

As mentioned previously, TCP is a stream based protocol and UDP is a datagram based protocol. Let's take an example of an application in which a NetBurner device takes A/D readings and sends them to another network device or host PC. Using UDP, each output operation (i.e. creating and sending a UDP packet) results in exactly one IP packet being created and sent. The result of taking and sending 10 A/D readings is that the host will receive 10 individual packets, each containing one reading.

The host PC can then easily identify each reading, although each reading will have to be sent with a sequence number so that the reading order can be recreated. If TCP is used with a single continuous network connection (i.e. the connection is not closed and reestablished for each reading), you do not have control over how many readings are send with each IP packet. You would need to add start message and stop message identifiers to separate the data from each reading.

Some applications that use TCP are: HTTP, FTP, Telnet and SMTP. Some applications that use UDP are: DHCP, BOOTP, SNMP and DNS.

TCP

TCP is used to create a reliable byte stream connection between two network hosts. The host that listens for incoming connections is referred to as the server, and the host that initiates a connection the client. Although TCP and UDP both use IP, TCP sends information as a stream of data. There are no record markers to delimit the data. For example, if a server is sending analog-to-digital (A/D) readings to a client, the client will see a stream of digits; TCP will not automatically insert delimiters to allow the client to determine where one measurement ends and the next begins. To the client, the stream may look like: 98273129323424. Even if the client knew each reading was 4 digits, it would not know where one ended and the next began. Four parameters are required for a TCP connection: source IP address, source port number, destination IP address, and destination port number.

In contrast to TCP, UDP (covered in the next chapter) is an unreliable, datagram-oriented connectionless protocol. Delivery is not guaranteed, but each output operation creates and sends one UDP datagram. In the above A/D example, each reading (or some number of multiple readings) could be sent as a single datagram and the client could then process one datagram at a time.