Transport Layer in the Internet
The network layer uses IP (Internet Protocol) which provides best-effort delivery between hosts. IP does not guarantee delivery, order, or integrity (unreliable service). Each host on the Internet has at least one IP address.
The Internet provides two primary transport-layer protocols: TCP and UDP.
Application developers must choose one of these two when creating network applications (socket), as each offers a different balance of reliability, speed, and complexity.
Connectionless Transport: User Datagram Protocol (UDP)
Defined in RFC 768, the User Datagram Protocol (UDP) is a minimal, "no-frills" transport protocol which provides no additional service beyond what IP does.
The key principle is that a UDP socket in host system is identified by a two-tuple: (destination IP address, destination port number)
.
When a host receives a UDP segment, its transport layer performs demultiplexing by looking only at the segment's destination port number. It delivers the segment to the socket bound to that port, regardless of the source IP or source port.
The source IP and source port in the segment simply act as a return address, which the receiving application can use to send a reply.
UDP uses a simple and efficient method for directing traffic to the correct application process. It is connectionless, does not establish a connection before sending data. This provides a fast but unreliable communication channel like direct communication between an application and the network layer (IP).
UDP working on the sender side:
The application process passes a message to UDP.
UDP adds:
- Source port number and destination port number (for multiplexing/demultiplexing).
- Two small additional fields (like length and checksum).
This UDP segment is then passed to the network layer, which encapsulates it in an IP datagram for delivery.
UDP working on the receiver side:
The network layer delivers the IP datagram containing the UDP segment to UDP.
UDP looks at the destination port number to determine which socket (and therefore which application process) should receive the data.
UDP Segment Structure
UDP's primary responsibilities are multiplexing/demultiplexing and basic error checking. This functionality is achieved with a lean 8-byte header containing just four fields:
Source Port (16 bits): Identifies the sending application process. It acts as the "return address."
Destination Port (16 bits): Identifies the receiving application process. This is essential for demultiplexing.
Length (16 bits): Specifies the total length of the UDP segment (header + data) in bytes.
Checksum (16 bits): An optional field used to detect bit errors that may have occurred during transmission.
The absence of sequence numbers, acknowledgment fields, and flow-control windows in the header is what makes UDP simple and fast.
UDP (User Datagram Protocol)
UDP provides an unreliable, connectionless service. It's a "fire-and-forget" protocol designed for speed and simplicity. Extends delivery from host-to-host (IP) to process-to-process. Multiplexing and demultiplexing to deliver data to the correct application process using port numbers.
Connectionless: It sends packets without establishing a prior connection or performing handshakes.
The sender creates segments and sends them immediately. Each segment is handled independently (no sequence).
Unreliable Service: UDP makes a "best effort" to deliver data but offers no guarantees. Packets can be lost, corrupted, or arrive out of order.
Minimal Overhead: It doesn't have the complex mechanisms of TCP (like acknowledgments, setup, tear-down or flow control), or maintaining state. This makes UDP very fast and lightweight.
No Regulation: UDP does not have built-in reliability, flow and congestion control, meaning a UDP application can send data at any rate it chooses.
Provides light integrity checking / error checking using a simple checksums.
Best for: Speed-sensitive applications that can tolerate some packet loss, such as live video streaming, online gaming, and DNS lookups.
Advantages of UDP
Applications choose UDP over TCP for several key reasons:
No Connection Delay: UDP skips the three-way handshake required by TCP, allowing data to be sent immediately. This reduces latency. (TCP has delay due to congestion control or re-transmissions)
Fine-Grained Sending Control: Data is transmitted as soon as the application passes it to the socket. It is not delayed by congestion control algorithms.
No Connection State: A server doesn't maintain state (like buffers or sequence numbers) for each client. This allows a UDP server to support a massive number of clients with minimal memory overhead . No send/ recieve buffer or congestion parameter.
Small Header Overhead: The UDP header is only 8 bytes, whereas TCP's header is 20 bytes or more.
Use Cases and Drawbacks
Common Applications
UDP is ideal for applications where speed is more critical than perfect reliability.
DNS: Queries need a fast response, and connection setup delay is undesirable. (Delay in TCP due to handshake)
Real-Time Applications: VoIP, online gaming, and live video streaming can tolerate minor packet loss but are highly sensitive to delays (jitter).
Network Protocols: Routing protocols like RIP and network management tools like SNMP use UDP for periodic, lightweight updates.
Drawbacks and Considerations
Unreliability: UDP offers no guarantees on delivery, order, or data integrity beyond the optional checksum.
No Congestion Control: This is UDP's biggest weakness. A poorly designed application can easily flood a network with traffic, causing severe packet loss for itself and unfairly drowning out other well-behaved (TCP) traffic.
Application-Layer Reliability: If an application needs reliability but wants UDP's speed, it must implement its own acknowledgment and re-transmission logic.
Heavy UDP use can overload routers, increasing losses and unfairly pushing down TCP traffic, this can cause serious network congestion.
Many multimedia apps tolerate some loss and use UDP to avoid delays from TCP congestion control. TCP is also increasingly used for streaming, especially when packet loss is low or UDP is blocked.
Reliability can still be built on top of UDP by the application itself, using acknowledgments and re-transmissions, though it .
UDP Client-Server Communication with Python
Let's see how this works with a client and a server.
1. The Server
A UDP server application creates a socket and binds it to a specific, well-known port. It then waits for incoming data.
# Server creates a socket and binds it to port 46428
server_socket = socket(AF_INET, SOCK_DGRAM)
server_socket.bind(('', 46428))
2. The Client
A client application creates a socket but typically lets the operating system automatically assign a temporary (ephemeral) port from the high range (1024–65535). Let's say the OS assigns port 19157
.
# Client creates a socket; the OS assigns an available port like 19157
client_socket = socket(AF_INET, SOCK_DGRAM)
3. Data Flow
When the client sends a message to the server:
It creates a UDP segment with Source Port: 19157 and Destination Port: 46428.
The server's transport layer receives this segment. It checks the destination port (
46428
) and delivers the data to the server socket bound to it.The server application uses a function like
recvfrom()
to read the data and also retrieve the client's return address (client_IP
,19157
).
4. The Reply
When the server sends a response:
It creates a new segment with the source and destination ports swapped: Source Port: 46428 and Destination Port: 19157.
This ensures the reply goes directly back to the correct client process that initiated the communication.