If you are just starting with TCP/IP then you are probably wondering why there are two transport layer protocols- ( TCP and UDP ).
Why don’t we just have one? After all TCP seems to be the best option anyway.
The aim of this short introductory tutorial is to explain the basic differences between the two and why each protocol is needed, and when they are used.
Both TCP and UDP sit at the transport layer of the TCP/IP protocol stack and both use the IP protocol.
Applications are designed to use one or the other protocol depending on their requirements.
TCP- Transmission Control Protocol
TCP is a connection orientated protocol with built in error recovery and re transmission.
You can liken a TCP connection to a telephone connection.
With a telephone connection you first need to setup the connection by dialing the number, and once the calling party answers you have a both way communications channel.
You then proceed to speak and once done you hang up the connection.
With TCP you set up the connection using the 3 way handshake as shown below:
The TCP transport takes care of errors on the link, and the application can be confident that the data received is error free.
TCP is used by application protocols that need guaranteed message delivery.
HTTP,FTP, SMTP, POP3, IMAP4 and many other common Internet application protocols use TCP.
UDP- User Datagram Protocol
UDP is a connectionless protocol.
You can liken UDP to email or the normal post.
With email or a written message you send your message, but have no idea whether or not that message was received.
UDP does not correct or recover errors in the message. Any error detection and recovery is the responsibility of the receiving application.
Because there is no connection setup, UDP is faster than TCP and results in less network traffic.
In addition it doesn’t consume resources on the receiving machine as it doesn’t hold a connection open.
Utility applications like DNS, DHCP, RIP and others use UDP.
The use of UDP is expected to increase with IOT as sensor type data is ideal for sending via UDP vs TCP.
For more details there is a very useful side by side TCP/UDP comparison .
TCP and UDP Headers
The UDP header (8 bytes) is considerably much smaller than the TCP header (20 bytes). Both the UDP and TCP header contain 16 bit source and destination Port fields.
The source port field is used to reply to the message.
There is a good diagram of both headers here.
TCP and UDP ports
Both TCP and UDP protocols use ports. You can have an application running on a computer using TCP port 80 and another application using UDP port 80.
An application address is effectively:
IP address + protocol (TCP or UDP) + port number.
The diagram below is meant to illustrate this:
Common Questions and Answers
Q- Can I change what protocol my application uses?
A- No the choice of transport protocol is done by the application developer.
Q- Does UDP have an Handshake mechanism?
Q- Are TCP ports different than UDP ports?
A- Yes a machine can be communicating on UDP port 2000 and TCP port 2000 at the same time.
Q- What is an ephemeral port?
A- It is a port that is only used for short period. An ephemeral port is typically used by a client when it connects to a server. The range is usually 49152 through 65535 but does vary see Wiki
TCP and UDP are both transport layer protocols. TCP is a connection orientated protocol and provides reliable message transfer. UDP is a connection less protocol and does not guarantee message delivery.
The choice of TCP vs UDP is made by the application developer in accordance with the application connection requirements.
- Understanding the TCP/IP Protocol suite
- Understanding TCP/IP ports and sockets
- IP Multicasting For Beginners
- An Introduction to the HTTP Protocol for beginners
Excellent explanation Steve.
One question, since UDP is transport layer, for a large message, sending side will break it into a few segments. Does the receiving side reassembly them into the original one large message, and only after that, notify application layer?
You get the entire message passed to the app and not fragments as stated here
Fragmentation and Reassembly.
The internet identification field (ID) is used together with the
source and destination address, and the protocol fields, to identify
datagram fragments for reassembly.
The More Fragments flag bit (MF) is set if the datagram is not the
last fragment. The Fragment Offset field identifies the fragment
location, relative to the beginning of the original unfragmented
datagram. Fragments are counted in units of 8 octets. The
fragmentation strategy is designed so than an unfragmented datagram
has all zero fragmentation information (MF = 0, fragment offset =
0). If an internet datagram is fragmented, its data portion must be
broken on 8 octet boundaries.
This format allows 2**13 = 8192 fragments of 8 octets each for a
total of 65,536 octets. Note that this is consistent with the the
datagram total length field (of course, the header is counted in the
total length and not in the fragments).
When fragmentation occurs, some options are copied, but others
remain with the first fragment only.
taken from rfc 791
very clear! Thank you