1. Introduction
User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) are the two most important data transmission protocols over computer networks.
In this tutorial, we’ll analyze them in detail. Then, we’ll compare them and discuss crucial differences.
2. UDP
2.1. Core Properties
David P. Reed designed the UDP protocol in 1980 and documented it in RFC 768. UDP is a simple protocol that works in a transport layer of the OSI model. Applications can use UDP to send data to other hosts over Internet Protocol. Messages sent with UDP are called datagrams. Let’s analyze the core properties of the UDP protocol.
Firstly, the UDP protocol is connectionless. In simple words, that means that it lacks the mechanisms of starting, maintaining, or ending the conversation. Moreover, there aren’t any techniques of flow control or retransmission. Thus, there is no guarantee that the receiver will obtain all datagrams or that they will come in a valid order. Hence, UDP is sometimes called an unreliable delivery protocol.
UDP’s lack of connections and reliability mechanisms has a specific reason. There is no need to store additional bytes of security data in the datagrams. Therefore, UDP transmission is lightweight and fast. Consequently, UDP is often used in applications where transmission speed is crucial, e.g., online games, video conferencing, or music streaming software.
Furthermore, UDP is stateless and enables multicast. Hence, it’s a good choice for sending messages to great numbers of hosts. It’s especially useful in streaming applications, such as IPTV (Internet Protocol Television) or live streaming services. As we mentioned earlier, datagrams sent using UDP are lightweight. In the next subsection, we’ll specify a UDP’s datagram structure.
2.2. Datagram Composition
The datagram is a self-contained, basic unit of data transferred via a packet-switched network. Datagrams usually consist of a header and a payload. The UDP header contains four fields, and each field is 4 bytes. The payload stores data transferred between hosts. Let’s analyze the datagram structure in detail:
The source port number identifies a port of a sender host. When used, it’s a port to which a reply should be sent if needed. However, the field is optional, and its value is 0 if not used.
The destination port number identifies a port of a receiver, and it’s a required field.
Length is a field that specifies a length of a datagram (its header and payload) in bytes. The header’s length is 8 bytes. So, it’s also the minimum length of a datagram. Theoretically, the maximum length of a single datagram is 65527 bytes. However, there are ways to extend that limit, e.g., using IPv6 jumbograms.
Finally, the checksum is used to validate the correctness of the header and payload and it’s 16 bytes long. It’s the only mechanism in UDP that checks if the datagram hasn’t been damaged. Although, the checksum is an optional field.
3. TCP
Similar to UDP, Transmission Control Protocol operates in a transport layer of the OSI model, and it transfers data between hosts. However, it works in a completely different way than the User Datagram Protocol. The specification of TCP protocol was published in 1974 in RFC 675. Let’s describe the core concepts of the Transmission Control Protocol.
First and foremost, TCP is connection-oriented. In simple words, that means the sender and the receiver must establish a connection and agree to transfer the data. For that purpose, TCP uses a technique called a three-way handshake. We’ll describe it in detail in the next subsection.
Secondly, the Transmission Control Protocol is reliable. It provides an error-checked, ordered stream of data. Transported packets can be lost in other layers of the protocol stack. TCP is able to detect such problems. In cases like this, it requires retransmission of the lost packets. Moreover, it can rearrange out of order packets. If it’s unable to complete or order the packets, it notifies the sender about the problem,
Thirdly, TCP transmission is unicast and bidirectional. It’s a result of the required one-to-one handshake. The TCP isn’t capable of handling multiple hosts. Even if it were possible to implement, it would make TCP too complex. Thus, there aren’t any multicast TCP based solutions on the market.
Altogether, TCP provides reliable, error-checked, and bidirectional transmission. Numerous internet application that needs such attributes uses TCP, including World Wide Web, secure shell, File Transfer Protocol (FTP) and more.
3.1. Connection Establishment
We already mentioned that TCP uses a three-way handshake mechanism to establish a connection between the client and the server. Below, we can see a flowchart presenting the mentioned technique:
The process looks as follows:
- SYN. The client begins the process by sending the SYN segment to the server. Before, it assigns to the segment’s sequence number a random value (e.g., 100). After the SYN is sent, the client goes into the SYN-SENT state.
- SYN-ACK. The server receives the SYN segment and goes into the SYN-RECEIVED state. As a response, it sends the SYN segment with its sequence number (e.g., 300) and the ACK segment. The ACK segment’s sequence number value is set to the client’s sequence number + 1. In our example, it would be 101.
- The client receives the SYN-ACK and goes into the ESTABLISHED state. It sends back the ACK segment with the sequence number set to the server’s sequence number + 1. For the sake of our example, it would be 301. The server receives the ACK segment and also goes into an ESTABLISHED state. Finally, data transfer can occur.
We’ve described how the three-way handshake works in case of a successful connection. Situations exist where one of the hosts will close the connection. Both hosts can initiate connection closing. It can be done by sending the segment with a FIN flag. The FIN request must be confirmed by an ACK segment. However, there is also an RST flag that performs an emergency shutdown without confirmation.
3.2. Packet Structure
The source port identifies the sender’s port, while the destination port identifies the receiver’s port.
The sequence number specifies the location of the file on disk before the data defragmentation. Thus, it allows putting the file together from respective packets.
The acknowledgment number confirms that the other host receives the packet.
The data offset represents the header length. It describes the number of the 32 bits long header’s rows. Consequently, it’s necessary to determine the beginning of the data.
The reserved field is space reserved for eventual future purposes. Therefore, filled with zeros at the moment.
Flags provide information about the purpose of the packet. Thew windows size informs about the size of data that the host is willing to receive and checksum validates data integrity.
Finally, the urgent pointer indicates how much of the packet’s data is considered urgent, while the options field (0-320 bits, a multiple of 32 bits) contains possible additional options and instructions. To ensure that the options are 32 bits of unit data, the field can be padded with zeros if necessary.
4. UDP vs TCP
So far, we’ve analyzed in detail the UDP and TCP protocols. Therefore, to sum things up, let’s compare them and see how their core concepts differ from each other:
5. Conclusion
In this article, we discussed UDP and TCP protocols in detail. Firstly, we discussed UDP’s core feature, and we analyzed the datagrams build. Then, we described TCP’s crucial attributes. Moreover, we characterized the TCP’s three-way handshake. Following, we described TCP’s packets format. Finally, we compared both protocols.