OSI Model - Seven Layers, Functions & PDUs

▶

Steps

send

Layer 7 - Application: HTTP GET request created

Browser generates an HTTP GET request. This is raw application data - the payload that the user actually wants to send. PDU = Data. Protocol: HTTP.

💡 The Application layer is where user-facing protocols live: HTTP, FTP, DNS, SMTP. It creates the message but has no idea how it will travel across the network.

Line:

# No code - conceptual layer
# HTTP GET /index.html HTTP/1.1
# Host: www.example.com

💡 The Application layer only cares about 'what' to send, not 'how'. It hands the data down to Presentation.

send

Layer 6 - Presentation: encode/encrypt data

Presentation layer handles data formatting, encryption (SSL/TLS), and compression. For HTTPS it would encrypt the HTTP data here. PDU still = Data.

💡 The Presentation layer is the 'translator' - it ensures data is in a format both sides understand. Think of it as converting data to a common language and optionally encrypting it.

Line:

# SSL/TLS encryption happens here for HTTPS
# Data encoding: ASCII, UTF-8, JPEG, MPEG

💡 For plain HTTP the Presentation layer passes data through. For HTTPS it wraps data in TLS encryption here.

send

Layer 5 - Session: manage connection dialog

Session layer establishes, manages, and terminates sessions between applications. It adds synchronization checkpoints for long transfers and manages dialog control (who speaks when). PDU = Data.

💡 Think of the Session layer as the 'meeting coordinator' - it sets up the connection, manages the conversation flow, and tears it down when done.

Line:

# Session establishment, checkpointing
# NetBIOS, RPC operate here

💡 For HTTP, the Session layer is mostly transparent. For longer file transfers it adds checkpoints so transfers can resume after interruption.

send

Layer 4 - Transport: segment into TCP segments, add ports

Transport layer breaks data into segments and adds source/destination port numbers (e.g. src=54321, dst=80 for HTTP). TCP adds sequence numbers for ordering and reliability. PDU changes to Segment.

💡 Port numbers are the key addition at Layer 4. They identify which application receives the data on the destination (port 80=HTTP, 443=HTTPS, 22=SSH). TCP also adds sequence numbers to reassemble segments in order.

Line:

# TCP segment header:
# src_port=54321, dst_port=80
# seq_num=1, ack_num=0
# flags=SYN

💡 The Transport layer is the first layer that creates end-to-end communication between processes. Network layers below only see IP addresses, not ports.

send

Layer 3 - Network: add IP header, create packet

Network layer adds source and destination IP addresses. This is where routing decisions are made - how to get from client IP to server IP across potentially many routers. PDU changes to Packet.

💡 IP addresses are logical addresses that identify devices across different networks. Routers operate at this layer - they read the IP header and decide where to forward the packet next.

Line:

# IP packet header:
# src_ip=192.168.1.10
# dst_ip=93.184.216.34
# TTL=64, protocol=TCP

💡 MAC addresses (Layer 2) only work within a single network. IP addresses (Layer 3) work globally - that's why we need both layers.

send

Layer 2 - Data Link: add MAC addresses, create frame

Data Link layer adds source and destination MAC addresses for the local network segment. Also adds a trailer with CRC error-detection code. PDU changes to Frame.

💡 MAC addresses identify devices on the same local network (like room numbers in a building). The IP address is the city+street address; the MAC is the apartment number within that building.

Line:

# Ethernet frame:
# dst_mac=AA:BB:CC:11:22:33 (next hop router)
# src_mac=FF:EE:DD:44:55:66 (client NIC)
# + CRC trailer for error detection

💡 The MAC destination here is the router's MAC, not the server's MAC. Layer 2 is only for the current network hop; IP handles the full journey.

send

Layer 1 - Physical: convert to bits, transmit

Physical layer converts the Frame into electrical signals (copper cable), light pulses (fiber optic), or radio waves (WiFi). These bits travel across the physical medium to the receiver. PDU = Bits.

💡 The Physical layer has no concept of addresses or structure - it just transmits raw 0s and 1s. The actual voltage levels, frequencies, and encoding schemes are defined here.

Line:

# Electrical signals on copper wire
# Light pulses on fiber optic
# Radio waves on WiFi (802.11)

💡 Every other layer is software/firmware. The Physical layer is hardware - the actual wire, fiber, or air carrying the signal.

receive

Receiver Layer 2 - Data Link: check CRC, extract packet

Receiver's Physical layer collects bits and reconstructs the Frame. Data Link layer checks CRC for errors. If valid, strips the Ethernet header and trailer, extracts the IP Packet, passes it up to Network layer.

💡 This is decapsulation - the receiver undoes what the sender did, layer by layer in reverse order. Each layer removes its own header/trailer.

Line:

# Check CRC: if error → drop frame
# Strip Ethernet header + CRC trailer
# Extract IP packet → pass to Layer 3

💡 Decapsulation is the reverse of encapsulation. The receiver reconstructs the original message by stripping headers from outermost to innermost.

receive

Receiver Layer 3 - Network: read IP, extract segment

Network layer reads the IP header, verifies destination IP matches this host. Strips IP header, extracts TCP Segment, passes up to Transport layer.

💡 The Network layer checks 'Is this packet meant for me?' by comparing the destination IP to its own IP address. If yes, strip the IP header and pass up.

Line:

# Check dst_ip == my_ip
# Strip IP header
# Extract TCP segment → pass to Layer 4

💡 Routers along the path also operate at Layer 3 - they read the IP header, decide the next hop, and forward without going above Layer 3.

receive

Receiver Layer 4 - Transport: reassemble, deliver to port 80

Transport layer reads TCP header. Checks destination port (80 = HTTP server process). Uses sequence numbers to reassemble multiple segments in order. Sends TCP ACK. Strips TCP header, passes Data up.

💡 Port 80 tells the OS which application should receive this data - the web server. Sequence numbers ensure segments are assembled in the correct order even if they arrived out of order.

Line:

# Check dst_port → route to HTTP server process
# Use seq_num to reassemble segments in order
# Send TCP ACK back to sender
# Strip TCP header → extract Data

💡 TCP ACKs are sent back to the sender to confirm receipt. If ACK is not received, the sender retransmits - this is TCP's reliability guarantee.

receive

Receiver Layers 5,6,7 - deliver HTTP request to web server

Session layer manages the ongoing connection. Presentation layer decrypts (for HTTPS) and decodes data. Application layer (web server) receives the HTTP GET request and processes it to send back the webpage response.

💡 The last three layers undo what the sender's layers did: Session tracks the dialog, Presentation decrypts, Application processes the message. The web server now sees the original HTTP GET request.

Line:

# Session: maintain dialog context
# Presentation: decrypt TLS, decode format
# Application: HTTP server processes GET /index.html

💡 The response from the web server travels down all 7 layers on the server side and up all 7 layers on the client side - the exact same process in reverse.

# Python socket = Application/Transport layers
import socket

# Application layer: create HTTP request
request = b'GET /index.html HTTP/1.1\r\nHost: example.com\r\n\r\n'

# Transport + Network layers: handled by OS TCP/IP stack
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)  # TCP socket
sock.connect(('93.184.216.34', 80))  # OS handles TCP handshake (Layer 4) + IP routing (Layer 3)

# Send: OS encapsulates through L4 (TCP) → L3 (IP) → L2 (Ethernet) → L1 (NIC)
sock.send(request)  # Application hands data to Transport layer

# Receive: OS decapsulates from L1 → L2 → L3 → L4 → delivers to socket buffer
response = sock.recv(4096)
print(response.decode())  # Application layer reads the HTTP response

📊

OSI Model - Watch an HTTP Request Flow Through All 7 Layers

The key insight: data goes DOWN the layers on the sender (each layer adds a header), crosses the network as bits, then goes UP the layers on the receiver (each layer removes its header). This is called encapsulation and decapsulation.

Application layer creates HTTP GET request. PDU = Data. Handed to Presentation layer.

Hop: 1

Layer 7: Application (Sender)

Layer 6: Presentation (Sender)

Layer 5: Session (Sender)

Layer 4: Transport (Sender)

Layer 3: Network (Sender)

Layer 2: Data Link (Sender)

Layer 1: Physical (Sender)

Layer 1: Physical (Receiver)

Layer 2: Data Link (Receiver)

Layer 3: Network (Receiver)

Layer 4: Transport (Receiver)

Layer 5: Session (Receiver)

Layer 6: Presentation (Receiver)

Layer 7: Application (Receiver)

📦Packet

↗ fromApp_Tx

↘ toPres_Tx

📄 payloadData (HTTP GET)

🔌 protocolHTTP

Layer 7 (App) → Data created: HTTP GET /index.html

Presentation layer formats and optionally encrypts data. PDU = Data.

Hop: 2

Layer 7: Application (Sender)

Layer 6: Presentation (Sender)

Layer 5: Session (Sender)

📦Packet

↗ fromPres_Tx

↘ toSession_Tx

📄 payloadData (formatted/encrypted)

🔌 protocolSSL/TLS

Layer 7 (App) → Data: HTTP GET /index.html

Layer 6 (Pres) → Data: Encoded/encrypted

Session layer manages connection dialog. PDU = Data.

Hop: 3

Layer 6: Presentation (Sender)

Layer 5: Session (Sender)

Layer 4: Transport (Sender)

📦Packet

↗ fromSession_Tx

↘ toTransport_Tx

📄 payloadData (session-managed)

🔌 protocolNetBIOS/RPC

Layer 7 (App) → Data: HTTP GET

Layer 6 (Pres) → Data: Encoded

Layer 5 (Session) → Data: Session established

Transport layer adds TCP header with port numbers and sequence number. PDU = Segment.

Hop: 4

Layer 5: Session (Sender)

Layer 4: Transport (Sender)

Layer 3: Network (Sender)

📦Packet

↗ fromTransport_Tx

↘ toNetwork_Tx

📄 payloadSegment (TCP header + Data)

🔌 protocolTCP

Layer 6 (Pres) → Data: Encoded

Layer 5 (Session) → Data: Session OK

Layer 4 (Transport) → Segment: src=54321 dst=80 seq=1

Network layer adds IP header with src/dst IP addresses. PDU = Packet.

Hop: 5

Layer 4: Transport (Sender)

Layer 3: Network (Sender)

Layer 2: Data Link (Sender)

📦Packet

↗ fromNetwork_Tx

↘ toDataLink_Tx

📄 payloadPacket (IP header + Segment)

🔌 protocolIP

Layer 5 (Session) → Data: Session

Layer 4 (Transport) → Segment: TCP ports+seq

Layer 3 (Network) → Packet: src=192.168.1.10 dst=93.184.216.34

Data Link adds Ethernet header (MAC addresses) and CRC trailer. PDU = Frame.

Hop: 6

Layer 3: Network (Sender)

Layer 2: Data Link (Sender)

Layer 1: Physical (Sender)

📦Packet

↗ fromDataLink_Tx

↘ toPhysical_Tx

📄 payloadFrame (MAC header + Packet + CRC)

🔌 protocolEthernet

Layer 7→Data | Layer 6→Data:enc | Layer 5→Data:session

Layer 4→Segment:TCP | Layer 3→Packet:IP

Layer 2 (DataLink) → Frame: src_mac+dst_mac+CRC

Physical layer converts Frame to bits and transmits over physical medium. Receiver's Physical layer detects signal.

Hop: 7

Layer 2: Data Link (Sender)

Layer 1: Physical (Sender)

Layer 1: Physical (Receiver)

📦Packet

↗ fromPhysical_Tx

↘ toPhysical_Rx

📄 payloadBits (010110001...)

🔌 protocolEthernet PHY

L4→Segment | L3→Packet | L2→Frame

Layer 1 (Physical) → Bits: transmitted over medium

RECEIVER SIDE: (decapsulation begins)

Data Link layer validates CRC and strips Ethernet header. PDU = Packet passed up.

Hop: 8

Layer 1: Physical (Receiver)

Layer 2: Data Link (Receiver)

Layer 3: Network (Receiver)

📦Packet

↗ fromDataLink_Rx

↘ toNetwork_Rx

📄 payloadPacket (Ethernet stripped)

🔌 protocolEthernet → IP

Receiver L1 → Bits received

Receiver L2 (DataLink) → Frame: CRC OK, MAC header stripped → Packet

Network layer verifies IP and strips header. PDU = Segment passed up.

Hop: 9

Layer 2: Data Link (Receiver)

Layer 3: Network (Receiver)

Layer 4: Transport (Receiver)

📦Packet

↗ fromNetwork_Rx

↘ toTransport_Rx

📄 payloadSegment (IP stripped)

🔌 protocolIP → TCP

Receiver L2 → Frame→Packet

Receiver L3 (Network) → Packet: dst_ip matched, IP header stripped → Segment

Transport layer reassembles segments, sends ACK, strips TCP header. PDU = Data.

Hop: 10

Layer 3: Network (Receiver)

Layer 4: Transport (Receiver)

Layer 5: Session (Receiver)

📦Packet

↗ fromTransport_Rx

↘ toSession_Rx

📄 payloadData (TCP stripped)

🔌 protocolTCP → Session

Receiver L3 → Segment

Receiver L4 (Transport) → Segment: port=80 matched, seq reordered, ACK sent → Data

All 7 receiver layers processed. HTTP GET delivered to application. Full encapsulation/decapsulation cycle complete.

Hop: 11

Layer 4: Transport (Receiver)

Layer 5: Session (Receiver)

Layer 6: Presentation (Receiver)

Layer 7: Application (Receiver)

📦Packet

↗ fromPres_Rx

↘ toApp_Rx

📄 payloadData (HTTP GET request)

🔌 protocolHTTP

SENDER: L7→Data | L6→Data | L5→Data | L4→Segment | L3→Packet | L2→Frame | L1→Bits

RECEIVER: L1→Bits | L2→Frame→Packet | L3→Packet→Segment | L4→Segment→Data

L5→Data (session) | L6→Data (decrypt) | L7 (App) → HTTP GET received by web server

Key Takeaways

✓ Encapsulation (sender): each layer adds its header going DOWN - Data→Segment→Packet→Frame→Bits.

Mnemonic bottom-up: Please Do Not Throw Sausage Pizza Away (Physical, Data Link, Network, Transport, Session, Presentation, Application).

✓ Decapsulation (receiver): each layer removes its header going UP - Bits→Frame→Packet→Segment→Data.

The receiver is a mirror of the sender. Every header added on one side is removed on the other.

✓ PDUs by layer: Bits (L1), Frame (L2), Packet (L3), Segment (L4), Data (L5-L7).

In interviews, if asked 'what PDU at Layer X', recall: 1=Bits, 2=Frame, 3=Packet, 4=Segment, 5-7=Data.

Practice

1. Trace the sequence of DHCP messages exchanged when a client obtains an IP address for the first time. Which message does the client send immediately after receiving an Offer from the server?

easy

A. DHCP Discover

B. DHCP Acknowledgment

C. DHCP Request

D. DHCP Release

Solution

1. Step 1: Recall the DORA sequence

   The client sends Discover, the server replies with Offer, then the client sends Request to accept the offer.

2. Step 2: Identify the message after Offer

   After receiving Offer, the client must send Request to confirm the IP address selection.

3. Step 3: Analyze other options

   Discover is the initial message, Acknowledgment is sent by the server after Request, Release is for freeing the IP.

4. Final Answer:

   Option C -> Option C

5. Quick Check:

   Request follows Offer to finalize IP assignment.

Hint: DORA sequence: Discover -> Offer -> Request -> Acknowledgment

Common Mistakes:

• Thinking client sends Discover again after Offer
• Confusing Acknowledgment as client message
• Assuming Release is part of initial assignment

2. What is a key limitation of Port Address Translation (PAT) when many internal hosts simultaneously initiate outbound connections to the internet?

medium

A. PAT cannot translate destination IP addresses, so inbound connections are impossible

B. PAT requires a unique public IP per internal host, increasing IP address consumption

C. PAT can run out of available source ports, limiting the number of simultaneous connections

D. PAT causes all internal hosts to share the same source port, causing packet collisions

Solution

1. Step 1: Recall PAT function

   PAT maps multiple internal IP:port pairs to a single public IP with unique source ports.

2. Step 2: Identify limitation

   Since TCP/UDP ports are 16-bit, only ~65,000 ports are available per public IP, limiting simultaneous connections.

3. Step 3: Analyze options

   PAT can run out of available source ports, limiting the number of simultaneous connections correctly identifies port exhaustion. PAT requires a unique public IP per internal host, increasing IP address consumption is false; PAT uses one public IP for many hosts. PAT cannot translate destination IP addresses, so inbound connections are impossible is unrelated to PAT's outbound translation. PAT causes all internal hosts to share the same source port, causing packet collisions is false; PAT assigns unique ports to avoid collisions.

4. Final Answer:

   Option C -> Option C

5. Quick Check:

   PAT port exhaustion limits simultaneous connections [OK]

Hint: PAT multiplexes ports but port space is finite

Common Mistakes:

• Thinking PAT needs multiple public IPs
• Confusing PAT with DNAT limitations
• Believing PAT uses the same source port for all hosts

3. If a web application uses a custom API that returns a 4xx status code for rate limiting (too many requests), what is the best practice for the server's response to help clients handle this scenario gracefully?

hard

A. Return a 500 status code to indicate the server is overloaded and cannot process requests.

B. Return a 403 status code without any additional headers to block the client permanently.

C. Return a 429 status code with a Retry-After header indicating when the client can retry.

D. Return a 200 status code with an error message in the response body.

Solution

1. Step 1: Understand rate limiting status codes

   429 Too Many Requests is the standard status code for rate limiting.

2. Step 2: Importance of Retry-After header

   Including Retry-After tells the client when to retry, enabling graceful handling.

3. Step 3: Analyze options

   Return a 429 status code with a Retry-After header indicating when the client can retry. is correct: 429 + Retry-After is best practice.
   Return a 403 status code without any additional headers to block the client permanently. is incorrect: 403 forbids access but does not indicate rate limiting or retry timing.
   Return a 500 status code to indicate the server is overloaded and cannot process requests. is incorrect: 500 indicates server error, not client rate limiting.
   Return a 200 status code with an error message in the response body. is incorrect: 200 means success, which misleads clients about request status.

4. Final Answer:

   Option C -> Option C

5. Quick Check:

   Use 429 with Retry-After for rate limiting to communicate clearly with clients.

Hint: 429 + Retry-After = polite rate limiting

Common Mistakes:

• Using 403 or 500 instead of 429 for rate limiting
• Omitting Retry-After header causing client confusion
• Returning 200 with error message, breaking client logic

4. If you have a network 10.0.0.0/8 and need to create subnets that support at least 1000 hosts each, which subnet mask would be the most appropriate and why?

hard

A. /22 because it provides 1022 usable hosts per subnet, balancing size and address waste

B. /24 because it is the default Class C mask and easy to manage

C. /20 because it provides 4094 usable hosts per subnet, which is more than needed but efficient

D. /30 because it minimizes IP address waste by creating very small subnets

Solution

1. Step 1: Calculate hosts per subnet for candidate masks

   /22 mask -> 32 - 22 = 10 host bits -> 2^10 = 1024 addresses - 2 = 1022 usable hosts

2. Step 2: Check /24 mask

   /24 -> 8 host bits -> 254 usable hosts, insufficient for 1000 hosts

3. Step 3: Check /20 mask

   /20 -> 12 host bits -> 4094 usable hosts, more than needed but wastes addresses

4. Step 4: Check /30 mask

   /30 -> 2 host bits -> 2 usable hosts, far too small

5. Step 5: Choose best fit

   /22 provides just enough hosts with minimal waste, balancing efficiency and requirements.

6. Final Answer:

   Option A -> Option A

7. Quick Check:

   Subnet mask must provide ≥1000 hosts; /22 is minimal mask meeting this [OK]

Hint: Hosts per subnet = 2^(32 - mask) - 2

Common Mistakes:

• Choosing default masks without considering host requirements
• Picking too large subnets causing address waste
• Selecting very small subnets ignoring host count needs

5. If a real-time chat application needs to support thousands of clients with intermittent connectivity and occasional message bursts, which limitation of WebSockets should be considered, and what fallback mechanism is most appropriate?

hard

A. WebSocket cannot handle intermittent connectivity; fallback to opening multiple WebSocket connections per client

B. WebSocket does not support message ordering; fallback to SSE to guarantee ordered delivery

C. WebSocket connections consume significant server resources per client; fallback to HTTP Long Polling to reduce persistent connections

D. WebSocket has high latency for message bursts; fallback to HTTP/2 multiplexing to improve throughput

Solution

1. Step 1: Identify WebSocket resource usage

   Each WebSocket connection requires server resources to maintain persistent connections, which can be costly at scale.

2. Step 2: Consider intermittent connectivity

   Clients with intermittent connectivity may cause connection drops, increasing server load.

3. Step 3: Evaluate fallback options

   HTTP Long Polling can reduce persistent connections by using short-lived requests, making it a suitable fallback.

4. Step 4: Analyze other options

   WebSocket does not support message ordering; fallback to SSE to guarantee ordered delivery is incorrect; WebSocket supports message ordering. WebSocket cannot handle intermittent connectivity; fallback to opening multiple WebSocket connections per client is wrong because opening multiple connections per client worsens resource usage. WebSocket has high latency for message bursts; fallback to HTTP/2 multiplexing to improve throughput misattributes latency issues to WebSocket and suggests unrelated HTTP/2 multiplexing.

5. Final Answer:

   Option C -> Option C

6. Quick Check:

   WebSocket resource cost + intermittent clients -> fallback to Long Polling

Hint: WebSocket scales poorly with many persistent connections; Long Polling reduces connection count

Common Mistakes:

• Assuming WebSocket handles intermittent connectivity gracefully without resource impact
• Believing WebSocket lacks message ordering
• Confusing HTTP/2 multiplexing with WebSocket fallback