TCP/IP Model: User Datagram Protocol
To properly learn something, we have to start at the beginning. We will be learning one concept at a time, process it, and move to the next.
The goal is consistent learning and absorbing information while feeling engaged and not overwhelmed.
I have divided the transport layer articles into three parts.
I will be discussing the user datagram protocol in the transport layer of the TCP/IP Five-layer network model.
UDP does just about as little as a transport protocol can do. It does multiplexing/demultiplexing function and some light error checking and adds nothing to IP.
UDP takes messages from the application process, attaches source and destination port number fields for the multiplexing/demultiplexing service, adds two other small fields, and passes the resulting segment to the network layer.
The network layer encapsulates the transport-layer segment into an IP datagram and then makes a best-effort attempt to deliver the segment to the receiving host.
If the segment arrives at the receiving host, UDP uses the destination port number to deliver the segment’s data to the correct application process.
UDP is connectionless because there is no handshaking between sending and receiving transport-layer entities before sending a segment.
When a UDP socket is created, the transport layer automatically assigns a port number to the socket from 1024 to 65535, currently not being used by any other UDP port in the host.
It is important to note that a UDP socket is fully identified by a two-tuple consisting of a destination IP address and a destination port number. As a consequence, if two UDP segments have different source IP addresses or source port numbers, but have the same destination IP address and destination port number, then the two UDP segments are directed to the same destination process via the same destination socket.
Suppose a process in Host A, with UDP port 15190, wants to send a chunk of application data to a process with UDP port 41430 in Host B. The transport layer creates a transport-layer segment that includes the application data, the source port number (15190), the destination port number (41430), and two other values.
The transport layer then passes the resulting segment to the network layer. The network layer encapsulates the segment in an IP datagram and makes a best-effort attempt to deliver the segment to the receiving host. If the segment arrives at the receiving Host B, the transport layer at the receiving host examines the destination port number in the segment (41430) and delivers the segment to its socket identified by port 41430. As UDP segments arrive from the network, Host B directs (demultiplexes) each segment to the appropriate socket by examining the segment’s destination port number.
In the A-to-B segment, the source port number serves as part of a return address when B wants to send a segment back to A, the destination port in the B to A segment will take its value from the source port value of the A to B segment. (The complete return address is A’s IP address, and the source port
Some applications are better suited for UDP for the following reasons:
Finer application-level control over what data is sent, and when
When the application process passes data to UDP, it will package the data inside a UDP segment and immediately pass the segment to the network layer.
Real-time applications often require a minimum sending rate, do not want to delay segment transmission overly, and can tolerate some data loss.
Applications can use UDP and implement any additional functionality as part of the application that is needed beyond UDP’s segment-delivery service.
Example: The QUIC protocol (Quick UDP Internet Connection) used in Google’s Chrome browser uses UDP as its underlying transport protocol and implements reliability in an application-layer protocol on top of UDP.
No connection establishment
- UDP does not introduce any delay in establishing a connection that is probably the principal reason DNS runs over UDP.
No connection state
- UDP does not maintain a connection state and does not track any of the parameters of the connection state like receive and send buffers, congestion control parameters, and sequence and acknowledgment number.
Small packet header overhead
- The TCP segment has 20 bytes of header overhead in every segment, whereas UDP has only 8 bytes of overhead.
The UDP header has only four fields, each consisting of two bytes.
- The application data occupies the data field of the UDP segment.
- Example - DNS: the data field contains either a query message or a response message.
- Example - Streaming audio application: audio samples fill the data field.
Source and Destination Port
- The port numbers allow the destination host to pass the application data to the correct process running on the destination end system to perform the demultiplexing function.
- The length field specifies the number of bytes in the UDP segment (header plus data).
- An exact length value is needed since the size of the data field may differ from one UDP segment to the next.
- The length field specifies the length of the UDP segment, including the header, in bytes.
- The Checksum is used by the receiving host to check whether errors have been introduced into the segment.
- UDP at the sender side performs the 1s complement of the sum of all the 16-bit words in the segment, with any overflow encountered during the sum being wrapped around. This result is put in the checksum field of the UDP segment.
- Although UDP provides error checking, it does not do anything to recover from an error. Some implementations of UDP discard the damaged segment; others pass the damaged segment to the application with a warning.
I would be grateful if you let me know by sharing it on Twitter!
Follow me @ParthS0007 for more tech and blogging content :)