In this TCP IP tutorial we start by understanding the layering principle, then we examine the most popular protocols that make the TCP IP stack.
TCP IP layering concept
– Each layer delivers a service to the layer above.
– Each layer performs what it is meant to do and does not care about the layers below.
– Each layer on the source host communicates with its peer layer on the destination host → this is called Peer-layer communication
– Communication between layers of a same host is vertical in both directions
– We can change the implementation of a layer, as long as we preserve the inputs and outputs with the upper and lower layers
– A cross-layer implementation is a protocol definition that spans more than one layer. Cross-layer implementations reduce the flexibility of Internet.
Advantage of layering
Layering reduces the complexity of communication by breaking it into smaller pieces. E.g: computer programming (programming language, compiler, linker…). Each layer benefits from the network abstraction of the lower layers. Each layer “does not care” about the lower layers → separation of concerns.
With the early adoption of the internet and the variety of protocols and applications emerging, we needed a common model for communication. The Internet model is the oldest model of network communication. It is older than the OSI model created in the 1980s and taught extensively in computer networking schools.
In my college years, I thought that the OSI model was the most popular model. I was wrong because the OSI model was merely used in the real world in talking about encapsulation and decapsulation.
Internet model, or the TCP/IP model
The TCP/IP model is composed of four layers:
- Link layer
- Network layer, aka Internet layer
- Transport layer
- Application layer
Here is a nice table that compares the OSI model and the TCP/IP model. For each layer, we see a list of popular protocols:
It’s true that the OSI model was a well-layered model. The OSI model is great for academia, but in the real world, it’s better to get used to the TCP/IP model.
Engineers designed the Internet with the End-to-End principle in mind; that is, to place intelligent features on the end hosts, when possible.
The link layer takes datagrams from the network layer and puts them on the path, towards the next router or the end host, one link at a time.
The network layer
The purpose of the network layer is to deliver packets end to end from the source to the destination.
At the heart of the network layer sits IP, or the Internet Protocol. It is the foundational protocol of the Internet. Without it, we can not navigate the Internet. IP runs on thousands and thousands of devices around the globe in 24/7 fashion.
The transport layer
- to ensure the reliable transport of data segments coming from the Application layer
- Congestion management
- retransmission of packets if they were lost
- ordered delivery of packets
- uses port numbers
UDP: User Datagram Protocol
- unreliable transport.
- no congestion management, no packet retransmission
- uses port numbers too
– the combination of layering and packet switching gives encapsulation.
– a TCP segment (or UDP datagram) is encapsulated in an IP datagram which is encapsulated in a link frame
– At the network layer, IP does not care what the encapsulated data contains
– We can write a frame header and trailer from the left to the right (RFC and computer software approach) or from the right to the left (networking hardware approach) . Both approaches are correct
– At each layer, the packet is composed of:
- a header
- a payload
- a trailer
– An end host that receives the recursively encapsulated packet, inspects the payload and processes data accordingly.
– The TLS example:
- TLS operates between the Transport layer and the Application layer
- provides a secure end-to-end communication channel
TCP/IP Encapsulation example
-let’s suppose client A and client B, separated by routers X and Y in their path. If client A wants to send data to client B:
– client A encapsulates the packet into the link frame and send it to router X
– router X receives the frame, decapsulates the IP datagram, reads the destination IP address, encapsulates the IP datagram in a new link frame and puts it on the wire
– router Y receives the frame, decapsulates the IP datagram, reads the destination IP address, encapsulates the IP datagram in a new link frame and puts it on the wire
– client B receives the frame and reads the data up to the application layer
I have dedicated a separate article on the TCP protocol here.
Introduction to UDP
The UDP datagram consists of a header and an optional data field. The format of the datagram is as follows:
Let’s concentrate on the UDP header
UDP header format
The UDP header overhead is usually 8 Bytes while TCP header overhead is typically 20 bytes.
The way to represent that visually (on the UDP header figure above) is by multiplying the number of rows by the size of each row. The number of rows is 2. And the length of each row is 32 bits (from bit number 0 to bit number 31) or 4 bytes. You multiply 2*4 = 8 bytes.
– The UDP header contains four fields:
- source port,
- destination port,
- length: is the size of both UDP header and data.
- Checksum: concerns both header and data integrity. If the sender does not calculate a checksum, then this field will be all zeros.
Both the transmitting and the receiving nodes calculate UDP checksum. The checksum is the sum of 16-bit words. The principle is: if at the receiver the checksum gives an “all-1” binary number, then there are “theoretically” no errors in the segment. If there is any 0 then there is an error. Once an error is detected, the segment is either discarded, or passed with warning to the application layer, depending on the UDP implementation
UDP protocol functions
– provides multiplexing and demultiplexing of applications
– provides integrity verification (checksum)
– does not provide delay guarantees (neither does TCP)
– does not provide retransmission of lost segments or corrupted segments. It does not even know if a segment is lost!
– does not provide any mechanism to verify in-order or out-of-order segments (sequence numbers)
– does not provide flow control: the sender can send at any rate
– used by applications that rely on a request/response model, such as DNS, DHCP, NTP;;; where the request is contained in a single UDP datagram
– used by IP Telephony applications, some routing protocols, broadcast and multicast communications,…
– we can consider it as simply a wrapper and multiplexer/demultiplexer for application data
– to circumvent the lack of reliable transfer, some network developers write network applications that run on top of UDP with their own acknowledging and retransmission mechanisms.
Why does UDP provide an error detection mechanism while there are error detection mechanisms at the Link layer? Because the early network engineers built the Transport layer with the supposition that some links do not have error detection mechanisms, since the Network layer can run on any Link layer.