Network Layers and Encapsulation (OSI and TCP/IP)

By the end of this lesson you will be able to

• Explain why networking is split into layers and what each layer promises the one above it.
• Name all seven OSI layers with their job, an example protocol and their unit of data (bits, frame, packet, segment, datagram), and map them to the four TCP/IP layers.
• Explain how the physical layer turns bits into signals on copper, fibre and radio, and why switches made Ethernet collisions (CSMA/CD) history.
• Say what the session and presentation layers really do on today’s internet: where sessions, character encoding (ASCII, UTF-8), compression and TLS actually happen, and why text turns into mojibake.
• Describe exactly what is inside a TCP/IP packet: the Ethernet frame, IP header, TCP or UDP header and TLS record, field by field.
• Follow encapsulation on the sender, decapsulation on the receiver, and what switches and routers open and rewrite at every hop.
• Work out header overhead, explain MTU, MSS and fragmentation, and recognise failures such as FCS errors, TTL expiry and MTU black holes.

#Why networking is built in layers

Sending a web page from a server to your phone involves dozens of separate problems: turning bits into radio waves, deciding which device on the Wi-Fi gets a frame, finding a path across 15 networks run by different companies, recovering lost data, encrypting it, and finally speaking HTTP. No single program could solve all of that, and nobody would want to rewrite a browser every time a new kind of cable is invented.

Strip any network conversation down, even a one-word “Hello” on Messenger, and you find the same five parts: a sender (your phone), a receiver (your friend’s phone), the message (“Hello”), a medium that carries it (Wi-Fi radio, then fibre and copper across the internet), and a protocol: the rules both sides agreed on, like a shared language, so the receiver can make sense of what arrives. A real network needs dozens of protocols, one for each problem above. Layers are how those protocols are organised.

So the work is split into layers. Each layer:

• does one job and offers it as a service to the layer above (“give me bytes and a port, I will deliver them in order”);
• uses only the layer directly below it, without knowing how that layer works inside;
• talks to its peer layer on the other machine through a header that only that peer reads.

This brings real benefits:

• Swap one layer without touching the others. Your browser works the same on Wi-Fi, Ethernet or 5G; HTTP/3 was deployed by building QUIC on top of UDP without changing a single router.
• Independent teams and standards. Cable makers, router vendors, operating system developers and web developers each work on their own layer.
• Easier troubleshooting. “Is it the cable (L1), the Wi-Fi (L2), routing (L3), a closed port (L4) or the app (L7)?” is how engineers narrow a problem down.

The cost is some overhead: every layer adds a header, and some work (such as checksums) is repeated at several layers.

#The OSI model: seven layers

The OSI (Open Systems Interconnection) model is a 7-layer reference model published by ISO in 1984. The internet does not actually run OSI protocols, but everyone uses its layer numbers as a shared vocabulary: “that’s an L2 problem”, “an L7 load balancer”.

PDU (Protocol Data Unit) is the name for “the chunk of data at this layer, header included”. Using the right word tells people which layer you mean: a router forwards packets, a switch forwards frames.

Common memory aids: top to bottom, “All People Seem To Need Data Processing”; bottom to top, “Please Do Not Throw Sausage Pizza Away”.

#Layer 1 up close: bits become signals

Everything in the layers above ends up as a stream of 1s and 0s. The physical layer decides how those bits cross a real cable or the air. It does not know about frames or addresses; it only promises “the bits I receive are, almost always, the bits you sent”.

What the physical layer has to specify:

• Signal encoding. How a 1 and a 0 look on the medium. The simplest scheme, NRZ (non-return-to-zero), uses one level for 1 and another for 0. Its weakness: a long run of identical bits is a flat line, and the receiver loses count of how many bits went by. Manchester encoding, used by the original 10 Mbps Ethernet, puts a transition in the middle of every bit (low-to-high for 1, high-to-low for 0), so there is always an edge to sync on, at the price of twice the signalling rate. Faster Ethernet and Wi-Fi use cleverer codes (several voltage levels or phase shifts per symbol), but they solve the same two problems: packing more bits into each symbol and keeping both sides in step.
• Bit synchronisation. The receiver must know where each bit starts. The Ethernet preamble you will meet in the frame table below exists for exactly this.
• Data rate. 100 Mbps, 1 Gbps, 10 Gbps: fixed by the standard (IEEE 802.3 for Ethernet, IEEE 802.11 for Wi-Fi) and negotiated by both ends when the link comes up.
• Transmission mode. Simplex: one direction only (a television broadcast). Half-duplex: both directions, but one at a time (a walkie-talkie, a Wi-Fi channel, an old hub). Full-duplex: both directions at once (a phone call, every modern switched Ethernet link, which has separate paths for sending and receiving).
• Topology and line configuration. The physical layout: bus (everyone taps one shared cable, early Ethernet), star (every device has its own cable to a central box, today’s Ethernet and Wi-Fi), ring (each device connects to two neighbours, old Token Ring and some fibre rings), mesh (many redundant links, the internet backbone and data-centre fabrics) and tree (stars of stars, a building’s network). A link is point-to-point when exactly two devices share it (a switch port and one PC) and multipoint when many do (a bus, a Wi-Fi channel).
• Physical characteristics. Voltages, light wavelengths, radio frequencies, pin layouts and maximum lengths. Other physical-layer standards you will see: Bluetooth, USB and RS-232 (old serial ports, still used for the console cable of routers and switches).

Devices that live only here are the repeater (regenerates a weak signal) and the hub (repeats every bit out of every port). Network cards, antennas and cables are physical-layer hardware too. A switch has physical ports, but its real job is Layer 2.

#Shared medium, collisions and CSMA/CD

On a bus or a hub, every device shares one medium. If two of them transmit at the same moment, their signals add up into garbage and both frames are lost: a collision. Classic Ethernet handled this with CSMA/CD (carrier sense multiple access with collision detection):

1. Carrier sense: listen first; if someone is transmitting, wait.
2. Multiple access: when the line is quiet, anyone may start.
3. Collision detection: keep listening while sending. If what is on the wire does not match what you are sending, two signals collided; send a short jam signal so every station notices.
4. Backoff: wait a random number of slot times and try again. After the nth collision in a row the random choice is between 0 and 2ⁿ − 1 slots (capped at 1023), and after 16 failed attempts the frame is dropped.

Two stations can both hear silence and start together because a signal takes time to travel down the cable, which is why collisions cannot be avoided, only detected. The more busy devices share a hub, the more time is wasted in collisions and backoff, and useful throughput collapses well below the link speed.

Switches made CSMA/CD history. Each switch port is its own point-to-point, full-duplex link with separate send and receive paths, so there is nobody to collide with. Full-duplex Ethernet switches CSMA/CD off completely, and Ethernet from 10 Gbps upwards does not even support half-duplex. The radio channel of Wi-Fi is still shared, so Wi-Fi uses a cousin, CSMA/CA (collision avoidance); Network Devices explains it along with hubs and switches.

#When layer 1 breaks

Physical problems look like: no link light, “network cable unplugged”, an interface stuck down, a link that comes up at 100 Mbps instead of 1 Gbps (often one damaged wire pair), a rising count of frames with bad FCS (noise, a bent cable, a dirty fibre connector), or a weak Wi-Fi signal. Tools: the port’s link light, ip link and ethtool eth0 on Linux (speed, duplex and error counters), a cable tester, a multimeter, an OTDR for fibre (it times light reflected back from a break to say how many metres away the fault is) and a Wi-Fi analyser app. In the cloud you never see layer 1: the provider runs it for you.

#Layers 5 and 6: what they really do today

In the OSI table, Session and Presentation look like two layers with their own protocols. On the internet they are not separate layers at all: the TCP/IP model folds both into the application. The jobs are real, and every web request needs them; they are simply done by protocols and libraries inside your program (and by TLS). Knowing where each job really happens is what lets you debug garbled text, logins that keep expiring and downloads that restart from zero.

#Session (L5): keeping a conversation going

A session is a conversation that lasts longer than one message: a Remote Desktop connection to an office PC, or your login on a banking site across many pages. OSI gives the session layer these jobs:

• Establish, maintain and terminate the session.
• Dialog control: who may talk when, in turns (half-duplex dialog) or both at once (full-duplex dialog).
• Synchronisation: put checkpoints into a long transfer.
• Recovery: after an interruption, continue from the last checkpoint instead of starting again.
• Token management: only the side holding a token may send, or perform a critical operation.

Textbooks list NetBIOS session service, RPC, SMB sessions and PPTP (an old VPN protocol, now insecure and obsolete) as session-layer protocols. Modern TCP/IP has no session layer, so here is where each job lives today:

Take the notes’ banking example. You log in; the server checks your password and creates a session; you open your balance, then a statement, then a transfer page, and each request carries the session cookie so the server knows it is still you; you log out and the server invalidates the session. That is session management, built by the application on top of HTTP, not by a separate layer in the network stack.

When session handling goes wrong you see: a dropped session (Remote Desktop disconnects when Wi-Fi blips), a timeout (idle too long), “your login has expired” in the middle of a form, a reconnect that fails because the server forgot the session (a restart wiped in-memory sessions), or two sides that disagree about where a transfer had reached.

#Presentation (L6): making bytes mean the same thing on both sides

The presentation layer (also called the translation or syntax layer) makes sure the receiver understands the data in the same way the sender meant it. It has three jobs: translation (character encoding and data formats), compression and encryption.

Character encoding: from letters to bytes

A network carries bytes, not letters. Both sides must agree which bytes mean which characters.

Before Unicode, every region had its own 8-bit “code page” that used the values 128–255 differently, so the same byte showed a different letter on different computers. Unicode with UTF-8 is why Bengali, Arabic and emoji now display correctly almost everywhere.

Mojibake (Japanese for “character transformation”) is what you see when bytes written in one encoding are read as another. The word বাংলা is 5 characters but 15 bytes in UTF-8 (E0 A6 AC E0 A6 BE …). Read those bytes as Windows-1252, a Western code page, and each byte turns into its own Latin letter: বাংলা. Nothing is damaged: the right bytes are being decoded with the wrong table, and decoding them as UTF-8 brings the word back. Two related symptoms are worse: ? marks or the replacement character � mean a conversion step already threw the real bytes away, and the original text is lost.

How to prevent it: label and agree. Send Content-Type: text/html; charset=utf-8 (or application/json, which is always UTF-8), put <meta charset="utf-8"> in HTML, save source files as UTF-8, and check the database. MySQL’s old utf8 type stores at most 3 bytes per character, so an emoji (4 bytes) fails to save or gets cut; use utf8mb4.

Compression: fewer bytes on the wire

• Lossless compression gives back every original bit: ZIP, gzip, Brotli and zstd for text and files, PNG for images, FLAC for audio. Use it whenever every byte matters (code, JSON, documents).
• Lossy compression throws away detail people will not notice to get much smaller: JPEG photos, MP3 and AAC audio, almost all video. You cannot get the original back.

The notes’ arithmetic: a 100 MB file compressed to 60 MB saved 40 MB, a 40% reduction (a ratio of 100 ÷ 60 ≈ 1.67 : 1). On the web, the browser says which methods it understands (Accept-Encoding: gzip, br, zstd) and the server says which one it used (Content-Encoding: br); text such as HTML, CSS, JavaScript and JSON often shrinks by 70% or more. Already-compressed files (JPEG, MP4, ZIP) barely shrink again, so servers skip them.

Order matters: compress first, then encrypt. Good encryption makes bytes look random, and random bytes cannot be compressed. (Compressing secrets together with attacker-controlled text inside one encrypted response can leak those secrets; chapter 2 covers that attack and the fix.)

Data formats and encryption

On the web the Content-Type header tells the receiver which format it is getting (image/jpeg, application/json). The notes’ example: you send a photo on WhatsApp. It is a JPEG (already lossy-compressed), it is encrypted before it leaves your phone, and your friend’s phone decrypts it, decodes the JPEG and draws it. Encoding problems, garbled characters, an image or video that will not decode, a decryption failure and “unsupported file format” are all presentation-layer failures.

#Where it all happens in one HTTPS request

So when a page shows বাংলা, you look at headers and code, not at cables; when users are logged out every few minutes, you look at cookies, session storage and load-balancer stickiness, not at a “session layer”.

#The TCP/IP model: four layers that actually run the internet

The internet was built on the TCP/IP model (also called the Internet protocol suite), which has four layers:

Some textbooks split the link layer into Data Link and Physical and call it the 5-layer model. In daily work, people mix the two: they use TCP/IP protocols but OSI numbers.

OSI is more detailed because it was designed on paper to describe every possible network; TCP/IP is leaner because it grew out of protocols that already worked. Each layer also has its own kind of address: MAC at Layer 2, IP at Layer 3, port at Layer 4. Layer 1 has none: it only carries signals.

A key distinction from the notes: in the TCP/IP model, the IP layer’s job is to move a packet towards its destination, hop by hop, with no promises (packets can be lost, duplicated or reordered). The TCP layer’s job is reliable transport on top of that: ordering, retransmission and flow control between two programs.

#Which device reads which layer

A device can only decide based on the headers it opens. The devices scenario above shows this, and the notes give a classroom picture of the first three:

Some textbooks add a “session gateway” at L5 and an “SSL/TLS gateway” at L6. In practice the box that ends TLS is the L7 proxy or load balancer in the last row, and most real devices span several layers (a home router is a switch, a router, a NAT box and a DHCP server at once).

#What is inside a TCP/IP packet

Now the most important networking part: when your browser sends an HTTPS request to a server, how is the data wrapped in header after header? The simplified structure from the notes, innermost first:

This process is called encapsulation: each layer treats everything it receives from above as an opaque payload and adds its own header (and sometimes a trailer). On the receiving side the layers process the information in reverse, which is called decapsulation.

#The Ethernet frame, field by field

The FCS is how a frame damaged by noise is caught. The receiver recomputes the CRC over the bytes it received; if the result differs from the FCS, the frame is dropped silently. Nobody is told. Ethernet does not resend (Wi-Fi retries a few times itself), so recovery is left to TCP, which notices the missing ACK and retransmits. Try the Corrupted frame scenario above.

The minimum Ethernet frame is 64 bytes (header + payload + FCS), which is why tiny payloads get padding.

#The IPv4 header

The IPv6 header is a fixed 40 bytes and simpler: version, traffic class, flow label, payload length, next header (like Protocol), Hop Limit (the same idea as TTL), and 128-bit source and destination addresses. It has no header checksum, and routers never fragment IPv6 packets.

#The TCP and UDP headers

TCP (20 bytes minimum, up to 60 with options): source port, destination port, sequence number, acknowledgment number, header length, flags (SYN, ACK, FIN, RST and a few more), window size (flow control), checksum, urgent pointer, and options such as MSS, window scaling, selective ACK and timestamps.

UDP (always 8 bytes): source port, destination port, length, checksum. That is all, which is why UDP is fast and simple and why everything else (ordering, retries) is up to the application. Lesson 1.9 covers TCP and UDP behaviour in depth.

#Hop by hop: decapsulation along the path

Encapsulation is not done just once at the sender and undone once at the receiver. Every router along the path partly unwraps and re-wraps the data:

1. The switch reads the destination MAC and forwards the frame unchanged.
2. The router checks the FCS, removes the frame, reads the IP header, looks up the next hop, decrements TTL, recomputes the header checksum, and builds a brand-new frame with new source and destination MACs for the next link.
3. This repeats at every router. The IP addresses and ports stay the same end to end (unless NAT rewrites them, lesson 1.7), while the MAC addresses change on every link.
4. Only the destination host unwraps all the way to the application.

This is the meaning of the notes’ line: MAC addresses are used on the local link, IP addresses identify the end-to-end destination. Lesson 1.6 looks at this from the addressing side.

When TTL reaches 0, the router drops the packet and returns an ICMP Time Exceeded message. Without TTL, a routing mistake would let packets circle forever. The traceroute tool turns this into a feature: it sends packets with TTL 1, 2, 3… so each router reveals itself in turn.

#MTU, MSS and fragmentation

Every link has a MTU (Maximum Transmission Unit): the largest IP packet it can carry in one frame. For Ethernet and Wi-Fi it is 1500 bytes. Other common values: 1492 on PPPoE broadband, around 1400 or less inside VPN tunnels (the tunnel adds its own headers), and 9000 “jumbo frames” inside data centres.

From the MTU, TCP derives its MSS (Maximum Segment Size), the most application data one segment can carry:

• IPv4: 1500 − 20 (IP) − 20 (TCP) = 1460 bytes
• IPv6: 1500 − 40 − 20 = 1440 bytes

The two sides announce their MSS during the TCP handshake. A 10 KB response is therefore cut by TCP into 7 segments, each sent as its own packet.

What if a packet is larger than the next link’s MTU?

• IPv4 with Don’t Fragment off: the router splits it into fragments, each with a copy of the IP header, the same Identification, an offset and a “more fragments” flag. Only the destination reassembles them. Losing one fragment loses the whole packet, and firewalls dislike fragments, so this is avoided.
• IPv4 with Don’t Fragment on (what TCP does): the router drops it and returns ICMP “Fragmentation needed” with the smaller MTU. The sender lowers its packet size for that destination. This is Path MTU Discovery.
• IPv6: routers never fragment; they return ICMPv6 “Packet Too Big” and the sender adapts. Every IPv6 link must carry at least 1280 bytes.

#Overhead in numbers

For one full-size TCP/IPv4 packet on Ethernet:

Efficiency is 1460 ÷ 1538 ≈ 95 %. With TCP timestamps (12 more header bytes, common on Linux) and TLS (about 21 bytes per record), useful data drops to roughly 93 %. For a 1-byte payload the picture flips: 84 bytes on the wire to deliver 1 byte. Play with it:

#Layers in system design

• Load balancer choice is a layer choice. An L4 load balancer (for example AWS Network Load Balancer) forwards TCP/UDP by IP and port: very fast, protocol-agnostic, but blind to URLs. An L7 load balancer (AWS Application Load Balancer, Nginx, Envoy) terminates TLS and routes by path, header or cookie, at a higher processing cost.
• Where TLS terminates decides who can read the traffic: at the load balancer (it sees plain HTTP behind it) or at the application (end-to-end encryption, but the load balancer can only do L4).
• Small messages are expensive. Every request pays the header tax and a round trip. Batching, keeping connections open and HTTP/2 multiplexing exist partly for this reason.
• MTU matters in the cloud. Inside an AWS VPC jumbo frames (9001) are allowed, but traffic leaving through a VPN or the internet drops to 1500 or less. Mismatched MTUs produce exactly the black-hole symptoms above.
• Debug by layer. Link up? (L1/L2) Can I ping the gateway? (L3) Is the port open? (L4) Does the app answer correctly? (L7) Lesson 1.14 turns this into a checklist.

#Try it yourself

# See your interface MTU
ip link show            # Linux: look for "mtu 1500"
netsh interface ipv4 show subinterfaces   # Windows

# Find the path MTU: send a packet that must not be fragmented
ping -M do -s 1472 example.com    # Linux: 1472 + 8 ICMP + 20 IP = 1500
ping -f -l 1472 example.com       # Windows equivalent
# If 1472 fails with "Frag needed" / "needs to be fragmented", lower the size until it works.

# Watch TTL-based hop discovery
traceroute example.com    # macOS / Linux
tracert example.com       # Windows

To see encapsulation with your own eyes, open Wireshark, capture on your Wi-Fi interface and load any website. Click one packet: the middle pane lists the layers exactly as in this lesson, Ethernet → Internet Protocol → Transmission Control Protocol → Transport Layer Security, and you can expand each header field.

#Summary

Key takeaways

• Networking is split into layers so each one does one job, uses only the layer below and talks to its peer through its own header. Layers can be swapped independently.
• OSI (7 layers): Physical (bits), Data Link (frame, MAC, switch), Network (packet, IP, router), Transport (segment/datagram, ports), Session, Presentation, Application. TCP/IP (4 layers): Link, Internet, Transport, Application.
• Encapsulation: Application data → TLS record → TCP segment → IP packet → Ethernet/Wi-Fi frame → bits. The receiver decapsulates in reverse.
• The IP layer moves packets towards the destination; the TCP layer makes transport reliable. MAC addresses work on one local link and change at every router; IP addresses identify the end-to-end destination.
• Switches read L2, routers read L3 and rewrite TTL and the frame, L7 devices read HTTP (and must terminate TLS).
• Physical layer: bits become voltages on copper, light in fibre or radio waves, using an encoding (NRZ, Manchester and faster codes) that also keeps sender and receiver in sync. Shared media (bus, hub) collide and need CSMA/CD; switches give every port its own full-duplex link, so collisions are gone.
• Session and presentation jobs are real but live inside the application today: sessions in TCP, TLS and cookies; checkpoints in resumable uploads; encoding (UTF-8), compression (gzip, Brotli) and formats in the app and HTTP; encryption in TLS. Mojibake is correct bytes decoded with the wrong table; label every text with its charset.
• FCS catches damaged frames, which are dropped silently; TTL kills looping packets; MTU (1500) limits packet size, MSS (1460) limits TCP data per segment, and blocked ICMP causes MTU black holes.

Self-check: network layers and encapsulation32 questions