In our last blog in this series, we talked about TCP/IP and its applications. Today we are going to dive deeper into the TCP/IP stack and talk about the differences between TCP and UDP.
What are the functions of TCP and UDP?
TCP and UDP are two transport protocols located at Layer 4 (Transport) of the OSI Model and Layer 3 (host-to-host) of the TCP/IP model. They are responsible for transmitting data between two hosts, but they do this differently depending on the application or needs of the user.
TCP (Transmission Control Protocol) is great for sending and receiving files over the internet, or a local network. It will reliably transfer from the source every bit of the file and reconstruct them at the destination, verifying the integrity of the data. TCP implements a flow control method where each data segment sent by the source must be acknowledged by the destination. Unacknowledged data within a certain period of time is retransmitted by the source. This protocol is, for this reason, used for file transfer (e.g. FTP) or web browsing (e.g. HTTP).
UDP (User Datagram Protocol) does not ensure that all the bits transmitted from the source are received at the destination, because its goal is to transfer bits as fast as possible to the destination host. For this reason, UDP is often used for VoIP and video streaming where the data must be transmitted in the lowest amount of time possible. In fact, for voice and video applications, reconstructing data at destination would add too much delay, degrading the calls.
The following table summarizes the characteristics and differences between the two protocols. We’ll cover each of these concepts in the following sections of the article.
| TCP | UDP |
|---|---|
| Sequenced | Unsequenced |
| Reliable | Unreliable |
| Virtual Circuit | No virtual circuit |
| Higher overhead | Low overhead |
| Acknowledgements | No Acknowledgements |
| Flow Control | No Flow Control |
Well-known TCP and UDP ports
With the exception of DNS, which can use both TCP and UDP protocols, generally an application uses the TCP or UDP protocol. In the previous blog post on TCP/IP applications, we covered well-known ports and applications. Here below is a quick reference chart on the most common ones:
| TCP Ports | UDP Ports |
|---|---|
| Telnet – Port 23 | SNMP – Port 161 |
| SMTP – Port 25 | TFTP – Port 69 |
| HTTP – Port 80 | DNS – Port 53 |
| FTP – Port 20 & 21 | BOOTPS/DHCP – Port 69 |
| DNS – Port 53 | |
| HTTPS – Port 443 | |
| SSH – Port 22 | |
| POP3 – Port 110 | |
| NTP – Port 123 | |
| IMAP4 – Port 143 |
Transmission Control Protocol (TCP)
Put simply, what TCP does is take data or a file from the application layer, break it down in chunks, and assign each chunk a number for identification during transmission. This is done because today’s networks are packet-switched, meaning that information is transmitted in small chunks of data (generally 1500 or 9000 bytes). As data is being received at the destination host, it has to be rebuilt in the exact same order for file integrity.
A good example of a TCP connection is the process of downloading a file via FTP. Our computers can’t send a 2GB file as one large packet over the internet, but they rather have to break it down into smaller “bits” and transmit it that way. The bits of data sent have to be received by the destination host and rebuilt in the exact same order following the numbering system implemented or the file will be corrupted.
TCP is a full duplex protocol with built-in error checking. This introduces a bit of overhead on the network, due to the extra information included in the header section of each packet sent, and packet retransmissions, should data get lost on its way. Differently from UDP, TCP has to execute a three-way handshake in the initial phase of a connection, or transfer between two hosts. Let’s cover that now.
Three-Way Handshake
The purpose of the three-way handshake is to establish connection between two hosts and define parameters and variables that will rule the sending and receiving process. This step is known as establishing a virtual circuit. With the handshake, the sender, which could be an application client, transmits a packet with the SYN flag set, which includes the sequence number that will be used as the starting value to mark all successive packets sent. This is step one (SYN).
The receiver, which could be an application server, then replies back with a different sequence number that will be used to number the packets it sends (remember, it’s a full-duplex channel) as well as an acknowledgement (ACK) that confirms the receipt of the first SYN packet from the sender. The ACK value is equal to the sequence number included in the SYN packet received plus one. This is step two (SYN/ACK).
Finally the sender transmits an ACK to the receiver which is the SYN value transmitted by the receiver plus one. This is step three (ACK). If we look at the TCP header, we can find relevant fields on which this mechanism is based. For example, SYN and ACK are binary flags set to 1 and included in the TCP header (see section Flags below).
The two hosts that went through a three-way handshake establish a TCP socket and can communicate with each other in full-duplex mode, where each can send and receive data from the other peer.
User Datagram Protocol (UDP)
UDP is a connectionless internet protocol where error-checking and recovery is not included. It also used to be called a “thin protocol” and put far less strain on legacy networks, as mentioned above, this is no longer a concern. UDP is great for a connection that does not require reliable delivery. UDP also does not require a virtual circuit (three-way handshake) to establish a connection. The sender sends, and the receiver receives (one way).
TCP Window Size (Window Flow Control)
The TCP window size determines the amount of data that a TCP sender can transmit without receiving acknowledgement. This mechanism ensures that a TCP socket can transfer more than one packet at the time, yielding higher throughput. In fact, the maximum achievable throughput achievable in a connection is equal to:
[TCP Window Size in bits] / [Latency in seconds] = [Throughput in bits per second]
For example, in Windows the TCP window size is by default 64Kb. With a modest latency of 10 ms, the maximum bandwidth that you can obtain is 52.43 Mbits/sec. For 500 ms, the maximum is 524 Kbits/sec. In some cases, users may want to change the window size value depending on the connection and bandwidth desired. Panos gives a perfect example of how this can be done in the blog post he wrote, “Adjusting the TCP Window Size Limit on Linux”.
If you want to dive deeper into TCP performance and network performance metrics, check out our white paper on Network Performance and End-User Experience.
Conclusion
TCP and UDP are two other building blocks of today’s networks, so it’s important to be familiar with the topics described here.
If you want to test what we learned today about TCP, you can override the default window size in an iperf test, and see if changing that improves, or reduces, throughput. In NetBeez, you can do that easily when you run an iperf test, as shown in the screenshot below:
