OSI and TCP/IP models — theory with layers, envelopes inside envelopes and a switch that doesn’t know your IP (and the assignment I uploaded at 11:57 p.m.)

Sunday, 11:57 p.m. Three minutes before the IC2 assignment deadline closed, and the progress bar on the campus portal froze on “Uploading…”. The class group chat filled up with diagnoses: “it’s the Wi-Fi”, “it’s the switch in the classroom”, “it’s the faculty router”, “it’s the campus server, it’s down”. We all had an opinion and none of us really knew what each device does or what each one looks at in what we send. (It arrived at 11:59, in case you were wondering.)

That night I understood what this topic is for. When you upload a file, your laptop does not just throw the bytes into the air: it puts them in an envelope, that envelope in another one and that one in another, and every device on the way opens only the envelopes that concern it. Today you will see what a protocol is, what a protocol architecture is, the three-layer model, PDUs and encapsulation, the TCP/IP architecture, the OSI model and, what comes up most in the exam, which layer the switch and the router work at in each model. If you come from the Introduction to networks, you already know what a switch, a router and packet switching are; today we give them layers. And when you finish, the exam-style exercises for this topic are waiting for you.

The example that runs through the whole article: you upload your IC2 assignment to the campus portal from your laptop, connected to the faculty Wi-Fi. The laptop has the IP 10.110.7.24, the campus server has 10.200.1.80, and in between there is a switch and the faculty router.

What a protocol is

Before the layers, the word everything rests on. Two programs on different machines (your browser and the campus server) only understand each other if they follow the same rules. It is just like a conversation between people: if I say “hi” and you answer with a phone number, something has gone wrong.

A protocol is the set of rules that define how two entities communicate: the format, the meaning and the timing of the messages they exchange.

Look at the drawing: on the left, a human conversation (greeting, question, answer); on the right, what your laptop does when it uploads the assignment: it asks for a TCP connection, the server replies, the laptop sends POST /submit with the file and the server answers 200 OK. Both follow a script. If the laptop sent the file without asking for the connection first, the server would not know what to do with it.

Entities and systems

The course notes distinguish two words that sound alike and show up in the test:

Concept	What it is	Examples
Entity	What communicates: the software that sends and receives	The browser, the email program, a terminal, a file transfer application
System	Where that entity lives: the device	Your laptop, the server, a terminal, a remote sensor

In other words: the browser (entity) lives on your laptop (system). A protocol is used to make entities in different systems communicate.

The three key points of a protocol

Any protocol is described with three questions, and this is classic fill-in-the-gaps material:

Key point	Answers…	What it covers	In our example
Syntax	What does the message look like?	Data format and signal levels	The TCP header is 20 bytes long and starts with the ports
Semantics	What does it mean?	Control information and error handling	A code meaning “this chunk arrived damaged, send it again”
Timing	When and in what order?	Speed matching and sequencing	The server does not receive faster than it processes, and the chunks are put back in order

Protocol architecture: divide to understand each other

Uploading a file involves lots of things at once: understanding what a file is, splitting it, numbering the pieces, knowing which machine it goes to, turning it into signals… Cramming all that into one giant protocol would be unmanageable. The solution is the usual one in computing: split the problem into modules.

A protocol architecture is the layered organisation of several protocols: it states what each layer does, how the layers interact and what information each one adds to the message so that it can be transmitted correctly.

The classic example in the notes is a file transfer split into three modules:

1. File transfer application: knows about files and commands (“upload this file”).
2. Communication service module: makes sure the data reaches the right application on the other side correctly.
3. Network access module: talks to the specific network the computer is attached to.

None of them needs to know how the others work: only what the one above asks for and what the one below offers. Those three modules are precisely the three-layer model.

The three-layer model

It is the simplified version the notes use to grasp the idea before TCP/IP. Your laptop (computer X) and the campus server (computer Y) have the same three layers.

Look at the dashed arrows in the drawing: each layer “talks” to its peer on the other machine using its protocol (application with application, transport with transport). But the real data does not travel horizontally: it goes down your laptop, across the network and up the server.

Layer	What it does	Detail that comes up in the exam
Application	Lets programs use the network without knowing how it works underneath	Supports several applications at once (email, file transfer)
Transport	Delivers the data to the right application: end-to-end communication between applications on different machines	Identifies the destination application (ports or SAP), segments and reassembles, controls errors and order. It is independent of the application and of the network
Network access	Data exchange between the computer and the network it is attached to	The sender gives the network the destination address and may request services (priority). It depends on the type of network (LAN, packet switching…)

Why is transport independent and network access not? Imagine you swap the Wi-Fi for an Ethernet cable halfway through the upload. Transport keeps splitting and numbering exactly the same: it does not know or care where the data goes out. Network access, on the other hand, is the one talking to the Wi-Fi or the cable, so it is the one that changes.

PDUs and encapsulation: envelopes inside envelopes

This is the heart of the topic. At each layer a protocol is used, and each protocol adds control information (a header) to the data it receives from the layer above.

A PDU (protocol data unit) is the block a layer builds: the data it receives from above plus the control information it adds itself.

In the three-layer model, the process when sending is this:

1. The application hands over the data (your assignment).
2. Transport may split it. It gives each chunk a transport header with three things: the destination SAP or port, the sequence number and an error detection code. The result is the transport PDU.
3. Network access adds its header, with the address of the destination computer and the request for resources from the network. The result is what travels: a network packet.

Each header answers a different question, and this is what helps most to keep things straight:

Header	Question it answers	Data it carries
Transport	Which service or application inside the host is it for?	Destination port or SAP (DSAP)
Network access	Which device (next hop) do I deliver this to?	Destination host address (DHost)

In TCP/IP the envelope has one more layer: the Internet layer adds the IP address in between. This is how it looks with the real data from this article’s simulator, which splits the assignment into chunks of at most 1460 bytes:

Notice that the data box never changes (1460 B in every row): only the envelopes on the left grow. The sums add up: 1460 + 20 (TCP) = 1480 B of segment; 1480 + 20 (IP) = 1500 B of datagram; 1500 + 14 + 4 (Ethernet and its FCS, a check code at the end) = 1518 B of frame; and 1518 × 8 = 12,144 bits through the air.

Layer (TCP/IP)	Name of its PDU	What it adds
Application	Data (message)	—
Transport	Segment	Ports, sequence number, error detection
Internet	Datagram (IP packet)	Source and destination IP addresses
Network access	Frame	Source and next-hop MAC addresses (and the FCS)
Physical	Bits	Nothing: it turns the frame into signals

On reception the reverse path is followed (decapsulation): each layer strips its header, checks its part and passes the rest up, until the campus server has your whole assignment.

The TCP/IP architecture

Now the real model, the one the Internet uses. The TCP/IP architecture came out of ARPANET, an experimental packet-switching network funded by DARPA (the US Defense Advanced Research Projects Agency), and it has become the Internet standard. A detail they ask about: there is no official TCP/IP model, but there is a functional one. In the course that model has five layers.

The drawing sums up what each layer does and which address it adds. Let’s go one by one, top to bottom, with our upload:

• Application: enables user applications. Your browser speaks HTTPS with the campus server (other examples: HTTP, SMTP for email).
• Transport (host-to-host): end-to-end communication between the two applications. With TCP, the exchange is reliable and the data arrives in the same order it was sent. The ports go here: the browser uses 51234 and the server listens on 443.
• Internet (IP): lets hosts be on different networks: it handles routing across several networks. It is implemented both in end hosts and in intermediate routers. The IP address is added here (10.110.7.24 → 10.200.1.80). There are two versions, IPv4 and IPv6.
• Network access: the data exchange between the host and the network it is attached to. It must give the network the destination address and involves services such as requesting a priority. The MAC address is added here.
• Physical: the physical interface between the host and the transmission medium. It specifies the characteristics of the medium, the nature of the signals and the data rate.

TCP and UDP, the two transport protocols

The transport layer has two protocols, and they often ask how they differ:

	TCP	UDP
Connection	Connection-oriented (first it is requested and accepted, as in the protocol drawing)	Connectionless
Guarantees	Reliable, ordered delivery without duplicates; acknowledges with ACK	Guarantees neither delivery nor order
Cost	More overhead and more latency	Little overhead, lower latency
When	Uploading the assignment, a web page, email	Video calls, games, real time

Your upload goes over TCP: not a single byte of the file can be missing. A tutoring video call prefers UDP: if a piece of the picture is lost, better to carry on than to freeze waiting for the resend.

The OSI model

OSI (Open Systems Interconnection) is the reference model developed by ISO (the International Organization for Standardization). It has seven layers:

No.	Layer	What it does
7	Application	Interaction with the user: applications access network services
6	Presentation	Makes sure the data is in a usable format; this is where it is encrypted
5	Session	Keeps connections alive; controls sessions
4	Transport	Transmits using transport protocols and guarantees that what is received is identical to what was sent
3	Network	Manages data addresses and the passage between networks
2	Data link	Defines the data format on the network, watches for format errors and controls the flow
1	Physical	Defines the network hardware and transmits the raw bit stream

And the historical fact that comes up in true/false questions: the seven-layer model as a whole never caught on as a real protocol stack; the TCP/IP architecture became dominant. OSI is still used a lot, but as vocabulary: when a technician says “it’s a layer 2 problem”, they are speaking OSI.

OSI versus TCP/IP

This comparison is one of the most repeated open questions, so it pays to have it drawn in your head:

The bottom four layers match one to one (physical with physical, data link with network access, network with Internet and transport with transport). The top three OSI layers, in coral, merge into the TCP/IP application layer: what OSI spreads over session, presentation and application, TCP/IP leaves to the application itself (for example, HTTPS encryption is done by the browser).

	OSI	TCP/IP
Origin	ISO, as a reference model	ARPANET, funded by DARPA
Layers	7	5 (in the course)
Top	Separate session, presentation and application	A single application layer
Bottom	Physical, data link, network, transport	Physical, network access, Internet, transport
In practice	Theoretical model, reference vocabulary	The real Internet standard
They are alike in…	Both are organised in layers and each layer adds its header

Switch and router in each model

And now the short questions that come up again and again. Back to the 11:57 p.m. upload: your frame goes first through the classroom switch and then through the faculty router. What does each one open?

The drawing shows how high each device “climbs”. The switch only has physical and network access: it receives the frame, looks at the destination MAC address and forwards it through the port where that host is. It does not open the datagram, so it knows nothing about your IP. The router climbs one layer more: it opens the frame, reads the destination IP address of the datagram and decides where to go next.

	Switch	Router
Address it uses	MAC (physical)	IP
What it joins	Hosts on the same network	Different networks
Layer in TCP/IP	Network access	Internet
Layer in OSI	Data link (layer 2)	Network (layer 3)
PDU it handles	Frame	Datagram
Extra	—	At home it usually also does NAT and DHCP

And the datagram, which they also ask about separately, lives in the Internet layer of TCP/IP, which is the network layer in OSI.

The MAC changes at every hop; the IP does not

There is a detail that explains why the router “sees the next hop”. The MAC address only works for one hop: from one device to the next within the same network. When your frame reaches the router, the router takes it apart, reads the IP and builds a new frame for the next hop, with new MACs.

Compare the two cards: on hop 1, the destination MAC is the router’s (00:1b:21:aa:10:01), not the server’s, because the router is the next hop. On hop 2 both MACs have changed. The IPs (10.110.7.24 → 10.200.1.80) and the ports (51234 → 443), however, travel untouched end to end. If there were five routers in between, the MAC would be rewritten five times and the IP not once.

Common mistakes

Check it with Python

To see encapsulation in numbers, here is a simulator that does what your laptop does with the assignment: it splits 3000 bytes of data into segments of at most 1460 bytes (the most that fits in a normal Ethernet frame) and adds the three headers to each chunk, counting how many bytes and bits come out at the end. The data is fixed, so there is nothing to type in.

# Encapsulation simulator: submitting the IC2 assignment to the campus portal
# Each TCP/IP layer wraps what the layer above hands it in its own header.

DATA = 3000                           # bytes the application (HTTPS) wants to send
MSS = 1460                            # maximum data per TCP segment over Ethernet
CAB_TCP, CAB_IP, CAB_ETH = 20, 20, 18  # minimum headers; Ethernet = 14 + 4 of FCS

source = {"port": 51234, "ip": "10.110.7.24", "mac": "3c:52:82:1a:7e:04"}
destination = {"port": 443, "ip": "10.200.1.80"}
next_hop_mac = "00:1b:21:aa:10:01"    # the faculty router's MAC, NOT the server's

# Transport: splits the data into chunks of at most MSS bytes
chunks, rest = [], DATA
while rest > 0:
    chunks.append(min(MSS, rest))     # the last chunk takes whatever is left
    rest -= chunks[-1]

print(f"Application data: {DATA} B -> {len(chunks)} segments")
print(f"{'No':>2} {'seq':>5} {'data':>6} {'segment':>9} {'datagram':>10} {'frame':>6} {'bits':>6}")
total, seq = 0, 1                     # seq = sequence number (first byte of the chunk)
for n, data in enumerate(chunks, start=1):
    segment = data + CAB_TCP          # + ports, sequence no. and error code
    datagram = segment + CAB_IP       # + source and destination IP
    frame = datagram + CAB_ETH        # + source and next-hop MAC
    print(f"{n:>2} {seq:>5} {data:>6} {segment:>9} {datagram:>10} {frame:>6} {frame * 8:>6}")
    total += frame
    seq += data                       # the next chunk starts where this one ended

overhead = total - DATA
print(f"Bytes on the wire: {total} (headers: {overhead} B, {100 * overhead / total:.1f} %)")
print(f"Port:   {source['port']} -> {destination['port']}  (read by the server: which service?)")
print(f"IP:     {source['ip']} -> {destination['ip']}  (read by the router: which network?)")
print(f"MAC:    {source['mac']} -> {next_hop_mac}  (read by the switch: which LAN port?)")

The real output of its single run:

Application data: 3000 B -> 3 segments
No   seq   data   segment   datagram  frame   bits
 1     1   1460      1480       1500   1518  12144
 2  1461   1460      1480       1500   1518  12144
 3  2921     80       100        120    138   1104
Bytes on the wire: 3174 (headers: 174 B, 5.5 %)
Port:   51234 -> 443  (read by the server: which service?)
IP:     10.110.7.24 -> 10.200.1.80  (read by the router: which network?)
MAC:    3c:52:82:1a:7e:04 -> 00:1b:21:aa:10:01  (read by the switch: which LAN port?)

Three segments, two full ones and a small one, and at the end the three addresses that travel with each chunk. Let’s go part by part.

The splitting, loop by loop

The while loop is the transport layer segmenting:

# Transport: splits the data into chunks of at most MSS bytes
chunks, rest = [], DATA
while rest > 0:
    chunks.append(min(MSS, rest))    # the last chunk takes whatever is left
    rest -= chunks[-1]

Each pass takes min(MSS, rest): 1460 bytes while there is plenty left, and whatever remains on the last one. Why min and not always subtract 1460? Because on the third pass only 80 bytes remain, and subtracting 1460 would leave rest negative and an invented chunk.

Pass	rest before	Chunk	rest after
1	3000	1460	1540
2	1540	1460	80
3	80	80	0 → leaves the loop

Check: 1460 + 1460 + 80 = 3000. Not a single byte is lost or invented.

The envelopes

The for loop encapsulates each chunk, from the inside out:

for n, data in enumerate(chunks, start=1):
    segment = data + CAB_TCP        # + ports, sequence no. and error code
    datagram = segment + CAB_IP     # + source and destination IP
    frame = datagram + CAB_ETH      # + source and next-hop MAC
    print(f"{n:>2} {seq:>5} {data:>6} {segment:>9} {datagram:>10} {frame:>6} {frame * 8:>6}")
    total += frame
    seq += data                     # the next chunk starts where this one ended

Each line is a layer: the segment adds the TCP header, the datagram adds the IP header on top of the segment (not on top of the data) and the frame adds Ethernet on top of the datagram. That is why they are chained: if you always added the three headers to data, the code would produce the same numbers, but you would lose the “envelope inside envelope” idea. The variable seq is the sequence number: the first byte of each chunk (1, 1461, 2921), which TCP uses to put them back in place at the destination even if they arrive out of order.

What to watch:

1. The data does not change, the headers add up. In row 1: 1460 → 1480 → 1500 → 1518. They are exactly the numbers in the encapsulation diagram.
2. The last segment is small. It only carries 80 bytes of data, but pays the same 58 bytes of headers: 80 + 58 = 138 B. With small chunks, the percentage of headers shoots up.
3. The total overhead. 1518 + 1518 + 138 = 3174 bytes on the wire for 3000 of data: 174 of headers (3 × 58), 5.5 % of what travels.
4. Three addresses, three readers. The server uses the port to know which service it is for; the router, the IP; the switch, the MAC. And the destination MAC is the router’s, not the server’s.
5. Try it yourself: change DATA = 3000 to DATA = 100 and see how much the headers weigh now (58 out of 158 bytes, more than a third).

Summary

Concept	What you need to know
Protocol	Rules between entities: format, meaning and timing (syntax, semantics, timing)
Protocol architecture	Several protocols in layers: what each does, how they interact and what each adds
Three-layer model	Application, transport (independent, ports) and network access (depends on the network)
PDU	Data + control information of one layer: segment, datagram, frame, bits
TCP/IP	ARPANET and DARPA; 5 layers: application, transport, Internet (IP), network access (MAC), physical
OSI	ISO; 7 layers: physical, data link, network, transport, session, presentation, application; never caught on as a real stack
Switch	MAC, same network; network access (TCP/IP), data link, layer 2 (OSI)
Router	IP, different networks; Internet (TCP/IP), network, layer 3 (OSI)

Three ideas to take away:

1. Each layer puts what comes from above into a new envelope, and each device opens only the envelopes that concern it.
2. The port says which service it is for, the IP which network and host, and the MAC which device on the LAN on this hop.
3. OSI has seven layers and TCP/IP five: the bottom four match and the top three OSI layers fit into the TCP/IP application layer.

Now it is time to prove it: in the exam-style exercises on the OSI and TCP/IP models you have an interactive quiz with every exam format and the four open questions with their model answers. And in the next topic we go inside the Internet layer: IP, addressing, subnets and routing.

Next step: exercisesOSI and TCP/IP models — exam-style exercises with layers, PDUs, switches and routers (and the “network layer” that cost me half a mark)

Did this article help you? Here is how you can support SergioLearns →