ISO/OSI and TCP/IP: the network map

Devices from different vendors understand each other

Welcome to the ISO/OSI course. In the first course you saw how data travels. Now we give it a system and names. We start with a question: how can a router from one maker, a PC from another and a phone from a third all talk without trouble? Because they all follow the same rules – protocols – and split the work into layers, each doing one job. That is the layered model. The two most important are ISO/OSI (7 layers, a map for understanding) and TCP/IP (4 layers the internet actually runs on). This whole course walks through them from the bottom up.

The layered model: each part does one job

At home your router is from one maker, your PC from another and your phone from a third – and they all understand each other without any trouble. How is that possible? They agreed on shared rules (called a protocol) and split the work into layers – each layer has one job and passes its result to the layer above and below. The postal system works the same way: you write a letter, put it in an addressed envelope, hand it to the post office, which uses transport (vans, planes). Each link does only its part and talks only to its neighbor. That is the point of layers: each part does only its own job. Your browser does not need to know whether you are on Wi-Fi or a cable – the lower layer handles that.

OSI and TCP/IP: two maps of one network

The ISO/OSI model is a shared map of a network. It was drawn up by ISO – the International Organization for Standardization – as a common agreement so devices from different vendors understand each other and faults can be pinned down layer by layer (its ISO authorship is why it is called ISO/OSI). It splits communication into 7 named layers, from the physical signal (1) up to the app you actually see (7). You have already met things that belong to some of these layers (MAC addresses, IP, cables and Wi-Fi) in the first course – now we give them names and place them. Click any layer to see an example. In practice a simplified TCP/IP model with 4 layers is also used; ISO/OSI is just a better map for understanding. Why two models? TCP/IP ran in practice first (ARPANET, the 1970s); OSI came later as a standard, but the internet already ran on TCP/IP – so they never merged, and today OSI serves mainly as a teaching and diagnostic framework.

Each layer has its own name for the unit of data:

What L1 does: signal, medium, bits

From the first course you already know that data, at its lowest level, is just bits – ones and zeros. Now it is the turn of layer 1 – the physical layer: its only job is to get a bit from one place to another as a physical signal over some medium. Copper carries it as voltage (high = 1, low = 0), fiber as light (flash = 1, dark = 0) and Wi-Fi as a radio wave (transmitting = 1, silent = 0). L1 does not care what the bits mean or whose they are – it just pushes them down the wire, fiber or air. Try flipping the bits below – watch how the same data is encoded into three different signals.

Interference: when noise talks into the signal

No medium is perfect. Along the way the signal picks up noise – interference from motors, a microwave, other transmitters, or crosstalk from a neighboring cable. As long as there is far more signal than noise, the receiver tells 1 from 0 with no trouble. But as interference grows, the signal gets jittery and the receiver may misread a bit – a 1 becomes a 0 or vice versa. That is how transmission errors happen. This is why every transmitted block of data carries a checksum: the transmitter computes a check number from the frame’s bits (typically a CRC) and appends it; the receiver computes the same and compares – a mismatch means corruption, so the frame is discarded. Getting it resent is up to a higher layer (typically TCP). And it is why shielded cabling (STP) is used in noisy places and Wi-Fi struggles in a congested band. Drag the slider below to add interference and watch the received signal and bits degrade.

Bandwidth, throughput, latency

At L1 three terms get confused. Bandwidth is the link’s capacity – how many bits the medium could carry per second (Mbps/Gbps), like the width of a motorway. Throughput is how much data actually flows – often less than the bandwidth (congestion, overhead, weak signal). Latency is something else entirely: the delay, how long data takes to get there and back – like travel time, not the number of lanes. A fast link can have huge bandwidth but poor latency (say over satellite) and still ruin a game or a call.

What L2 does: frames and local delivery

Layer 2 – data link handles delivery within one local network. It wraps data into a frame: it puts the destination and source MAC addresses at the front and a checksum (FCS) at the end, by which the receiver tells whether the frame got corrupted on the way. L2 does not think about reaching another network – that is L3’s job. It only handles one "hop": device to device (or to the gateway) within the same network, by MAC. Typical L2 devices are the switch and the access point.

Hub: sends to everyone — why that is not enough

The oldest device for joining stations is the hub – and note, it works only at L1 (it blindly repeats the electrical signal to all ports – it never reads the frame the signal carries). It is plain "dumb": whatever you send, it repeats to everyone. When a frame arrives it copies it to all ports (except the one it came from) – no memory, it never learns who is where. Crucially: the hub decides nothing. The "is this for me?" decision is made by the end station – its network card checks the destination MAC, keeps its own frame and drops the rest. But the foreign frame still arrived, so a curious host can read it (eavesdrop) – a serious security weakness. On top of that everyone shares one medium and easily talks over each other (collisions). Today the hub is essentially obsolete – the smarter switch replaced it (next up).

Switch and the MAC table

The switch is the smart successor to the hub. It learns: for every frame it remembers the source MAC and the port it came in on, into a MAC table. Next time it sends the frame to only the right port, not to everyone. That saves bandwidth, limits eavesdropping, and each port is its own collision domain. When it does not yet know the target, it floods like a hub – but only once, then it remembers. A table entry has a timer (typically ~300 s) and expires without traffic; when a device is moved to another port, the switch relearns it on the first frame from there (covered in detail in the Switch in depth course). The switch works at L2: it understands MAC, not IP – it will not carry you between different networks; that is the router (L3).

WAP: the wireless access point at L2

An access point (AP, sometimes WAP) is really a switch for the air. It works at L2: it takes wireless devices over Wi-Fi and bridges them onto the wired network it is cabled into. From the network’s point of view a wireless client behaves as if cabled into a switch – it gets an address from the same network the SSID maps to. The AP does not decide IP and does not route – the router does that. At home the AP is part of an all-in-one router; in an office it is a separate device – you have probably seen them as white discs mounted on the ceiling in offices or schools.

What L3 does: routing between networks

L1 carries the signal, L2 delivers a frame within one network. But how does data reach a different network? That is the job of layer 3 – network. L3 works with IP addresses and can route: by the destination IP it decides which way to send the packet next. The key difference: L2 handles one hop within a network (MAC), L3 handles the path across many networks (IP). The device that does this is the router (and its relative the L3 switch). Without L3 every local network would be an island – the internet is really one giant jigsaw of L3 routing.

Router and the routing table

The router is the main L3 device. For every packet it looks at the destination IP and in its routing table – a list of "destination network → the way out" – finds which interface to send it out to get closer to the target. Each pass through a router is one hop. So a packet does not wander the network forever, it carries a TTL (Time To Live) – a hop counter: every router lowers it by 1, and when it reaches zero the packet is dropped. Step through the decision.

NAT in practice: one address for the whole network

In the first course (How networks work) you saw the router swap your private address for its single public one (that is NAT). But then how does it know whose reply a packet is, when the whole household hides behind that one public IP? It uses port numbers and a translation table. This common variant (port-based NAT) is called PAT – and it is exactly why a single public address is enough for a whole network. Don’t confuse the NAT table with a stateful firewall’s connection table: the NAT table translates addresses and ports, while the connection table only permits return traffic that was requested from inside. A NAT router is usually also a stateful firewall, which is why the two functions often blur together. Step through the packet’s trip there and back.

L3 switch: when a switch can route

What if you want a switch’s speed and the ability to send data between different networks (VLANs), all in one box? That is the L3 switch: it does both. Within one network (a VLAN – a logically separated network on a single switch) it behaves like a blazing-fast L2 switch; between VLANs it routes like a router. In companies it is a backbone device – instead of a tangle of cables to one router, inter-VLAN routing is done right on the switch. The difference from an ordinary router: an L3 switch is tuned for high speed inside the company, a router for connecting to the internet (NAT, WAN). In practice, though, their roles increasingly overlap. (VLANs are covered in detail in the Switching and VLANs course.)

Bits and numbers: how 8 bits become 0–255

Before we split a network into smaller subnets, we need to understand what an IP address is made of. Under the hood it’s just bits (0 and 1). How do eight ones and zeros become a number like 192? An address is shown in octets (groups of 8 bits), e.g. 192.168.1.10. Each bit in an octet has a fixed weight – from the left 128, 64, 32, 16, 8, 4, 2, 1. The number is then simply the sum of the weights of the bits that are 1. Step through it (‹ / ›) – the next module builds subnetting on top of this.

Subnetting: how to split a network

In this lesson you saw how a router moves traffic between networks by IP. Now we look at how you split such a network into smaller parts. Why split a network into smaller subnets? To separate groups of devices (departments, guests, servers), cut down broadcast traffic and make it easier to manage and secure. The tool for it is how an address splits into a network and a host part. Remember the postal address from the first course? Every IP address has two parts: the NETWORK (like the city – shared by a whole group of devices) and the HOST (like the house number – one specific device in that network). But how do you tell where one part ends and the other begins? That is what the prefix is for (written e.g. /24). It is not another part of the address – it is just a marker of how many leading bits belong to the network (and reading an address in bits you already know from the previous page); all the rest belong to hosts. The exact same thing written differently is the mask (e.g. /24 = 255.255.255.0). Two addresses are never given to a device: the first is the name of the whole network and the last is the broadcast – a single message "to everyone in this network" at once. Drag the prefix and change the IP, and watch the network address, the broadcast, and how many devices fit.

What L4 does: end-to-end delivery

L3 delivers a packet to the right device. But that target device runs many apps at once – which of them is the packet for? That is handled by layer 4 – transport. It takes care of app-to-app delivery (end-to-end) and tells them apart by ports. This happens with everything you do online – browsing the web, downloading a file, a video call, messaging or sending email. It has two main flavours: TCP (reliable, with a connection and acknowledgements) and UDP (fast, no guarantee). Where L3 handles the path between devices, L4 handles the conversation between two specific apps at the ends. The next two modules cover TCP and UDP in depth.

TCP in depth: handshake and acknowledgements

You already met ports and TCP/UDP at a basic level in the How networks work course – here we go deeper. A device has one IP, but it runs many things at once – a browser, email, a game. To tell them apart there is the port: a service number (like an apartment number in a building). The server listens on a fixed, well-known number (web = 443, email…). For its own end the client uses any free port the system hands it – that is how the reply comes back to exactly this client. The second thing is reliability – and here there are two options. TCP is like registered mail: it agrees first (the three-way handshake) and resends what is lost. UDP is a postcard: it just fires the data and does not wait for confirmation – fast, but no guarantee. An app deliberately picks one based on what it needs (it is not random or alternating). Use the TCP/UDP toggle below to compare both step by step (‹ / ›).

Common ports: web HTTPS 443, older web HTTP 80, DNS 53, SSH 22.

UDP: when speed beats reliability

UDP is the opposite of TCP: no connection setup, no acknowledgements, no reordering. It just sends a packet and moves on – if it is lost on the way, nothing is resent. That sounds worse, but for many things it is better: in a live call, video or game there is no point resending data that should have arrived long ago – the delay would hurt more than a single dropped frame. So UDP is fast and overhead-free. DNS uses it too (a short query and reply). How does an app’s developer decide? If it needs certainty, they pick TCP; if it needs speed and freshness, they pick UDP.

L5 session: set up and keep the connection

Right above the transport layer sits layer 5 – session. It is in charge of a session – a continuous "conversation" between two apps. It does three things: it sets up the connection (both sides agree they are talking), then maintains it for the whole exchange (keeping order and continuity), and at the end closes it cleanly. Picture a phone call: you dial, the other side picks up, you talk for a while, then you hang up. In practice this is your login that "holds" until you log out, or resuming an interrupted download from where it stopped. Unlike the one-off TCP handshake (a transport agreement about a single connection), a session is an application conversation that can outlive several TCP connections – a login happily runs across dozens of separate requests. In the TCP/IP model the session layer has no place of its own – the application itself handles it (a web page manages your login session).

L6 presentation: the form of the data (encoding, encryption)

Layer 6 – presentation handles the form of the data – so both sides understand it the same way. It does three things. Encoding: it turns letters into bytes (groups of 8 bits – those ones and zeros from the first lesson) and back, so an "á" or an emoji looks the same everywhere – this rule is e.g. UTF-8 (an agreement on which number means which character). Compression: it shrinks the data so it takes less space and travels faster (zip, image and video codecs). Encryption: it locks the content, so only the two ends can read it on the way – this is exactly what TLS does, the "padlock" in your browser you know from the first course. In the TCP/IP model the presentation layer has no place of its own either – the application itself takes care of it (the browser picks the encoding and sets up TLS).

TCP/IP model: 4 layers in practice

ISO/OSI has 7 layers and is a great map for understanding how a network works. But the internet actually runs on the simpler TCP/IP model with just 4 layers – it merges some OSI layers. Application (merges OSI 5–7: app, format, session) → Transport (= OSI 4: TCP/UDP) → Internet (= OSI 3: IP, routing) → Link (merges OSI 1–2: frame + signal). Why know both? OSI is better for learning and troubleshooting ("which layer is it stuck at?"), TCP/IP describes how it really is. When you hear "an L3 problem" or "the application layer", you now know what people mean.

Application layer: where DNS, HTTP and TLS live

At the very top is the application layer – what the app you use (browser, email) actually works with. This is where the protocols you already know from the How networks work course "live": DNS (name resolution), HTTP/HTTPS (the web), TLS (encryption), DHCP (address assignment). In the TCP/IP model everything from OSI layers 5–7 lands here at once. Important: the application layer need not care whether you are on Wi-Fi or a cable, what your IP is or how TCP is set up – the lower layers did that for it. That is why a web developer can write an app and never think about how the data physically flows.

How to read documentation and certifications

Why know the layers at all? Because you will see them everywhere. Device docs, manuals, job ads and certifications (CompTIA Network+, Cisco CCNA…) are built on layers. When you read "an L3 device", "works at layer 2" or "an L7 firewall", you instantly know what it means: L2 = MAC/switch/VLAN, L3 = IP/router/routing/NAT, L4 = TCP/port/PAT, L7 = app/HTTP/TLS. Layers are the shared language of the whole field: "which layer is it stuck at?" is the first troubleshooting question, and "what layer does it work at?" the first question about any device. This course gave you exactly that map.

Why a firewall does not fit in one layer

A firewall is a security gateway between networks – it lets only allowed traffic through and blocks the rest. Some devices do not fit a single layer, and the firewall is the flagship: it decides using information from several layers at once. It can filter by L3 (source/destination IP), by L4 (port and protocol – "allow 443, block 23"), and the more advanced ones by L7 too (the content itself – "block this attack in HTTP"). So it makes no sense to ask "what layer is the firewall at" – it depends on what it is doing. That is also why we left the firewall until here, at the end of the layers: now that you know L3, L4 and L7, its behavior makes sense. The next two modules show how it actually decides.

Packet filter and stateful firewall

A firewall lets through only what it should and blocks the rest – unsolicited or dangerous traffic from outside. But how does it decide? The simplest is a packet filter: it judges each packet on its own by rules (source, destination, protocol, port). It works, but knows nothing about context – the reply to your request is just a foreign packet from outside to it. That is why a stateful firewall is used: it remembers established connections. Its connection table only permits the return – unlike the NAT table (Lesson L3), which also translates addresses and ports. Step through how it does that. In the simulator, return traffic is stateful as well.

Zones: inside, outside, DMZ

So you do not write rules per cable, a firewall groups interfaces into zones by trust level. The three classic ones: inside (your internal network – trusted), outside (the internet – untrusted) and DMZ (demilitarized zone – where you put public servers, e.g. a web server). (In practice there are usually more – covered in detail in the Network security course.) The logic is simple: from the internet you may reach only the DMZ and only on allowed ports (443); nobody reaches inside from outside. And crucially: even if an attacker compromises a server in the DMZ, they cannot get into the internal network from there – the DMZ is a buffer. You try exactly this in the task "Expose the web, protect the internal network". Zones are the practical payoff of everything the course taught: layers, addresses, ports and trust together.

Each layer adds its own header

Now you know what each layer does. The last question: how do the layers work together on one piece of sent data? The answer is encapsulation – "wrapping". When you send something, data goes down the stack and each layer wraps its own header around it: transport adds ports (a segment), network adds IP addresses (a packet), data-link adds MAC and a checksum (a frame), physical sends it as bits. It is like an envelope inside an envelope. At the receiver the whole thing is unwrapped in reverse – each layer reads and peels its own header and passes the rest up. In the next module you step through it as an animation at both sender and receiver.

Stack animation: sender and receiver

The grand finale – now it all comes together. The message "hello" travels down all 7 layers and each wraps its own header (like an envelope inside an envelope). At the bottom it collapses to bits, flies across the medium to the receiver, then climbs back up – each layer reads and peels its header until a clean message is left. That is encapsulation. (Along the way a router peels the frame back to Layer 3, reads the destination IP, and builds a new frame for the next hop – the upper layers stay untouched.) Watch the unit name on the right change too (data → segment → packet → frame → bits).

And that wraps up the ISO/OSI course. You can now read a network layer by layer: you know what L1–L7 do, what hubs, switches and routers are for, how transport works (TCP/UDP), where the firewall fits and how encapsulation holds it all together. In the Switching and VLANs course we return to Layer 2 in practice: you’ll learn to split a network with VLANs and switches – the foundation of every real company network.