Two models describe how a network moves data: the seven-layer OSI model and the TCP/IP model that the Internet actually runs on. Layers are referred to by their OSI number in everyday networking, the protocols on the wire are TCP/IP, and the two models map onto each other cleanly once the layout is clear. This guide sets out all seven OSI layers, maps them to TCP/IP, walks the encapsulation process an HTTP request goes through on the way down the stack, and confirms every layer against a real packet capture.
Captured June 2026 with tshark 4.2, the command-line build of Wireshark.
The model is the vocabulary for everything that follows in networking, from where a switch operates to why a router rewrites a frame. If the CLI is still new, the base device configuration walkthrough covers getting a device to the point where it can pass this traffic.
Why networking uses a layered model
A layered model splits one large problem (move data between two hosts) into independent jobs, each with a defined input and output. A NIC vendor builds Layer 1 and 2, an OS vendor builds Layer 3 and 4, an application developer builds Layer 7, and none of them needs to know how the others work internally. They only agree on what each layer hands to the one below it.
Two models exist for historical reasons. OSI was published by the ISO in 1984 as a reference architecture with seven layers. TCP/IP came out of ARPANET, shipped earlier, and became the de-facto standard. The result: OSI is the numbering system everyone cites (“that is a Layer 3 problem”), and TCP/IP is the protocol stack that actually carries the packet.
The seven OSI layers, bottom to top
Each layer has a number, a name, the name of the data unit at that layer (its PDU), and the protocols that operate there. Layers 2 and 3 come up constantly in commands, error messages, and day-to-day troubleshooting, so the numbers are worth knowing without hesitation.
| Layer | Name | PDU | Job and key protocols |
|---|---|---|---|
| 7 | Application | data | Interface to applications: HTTP, DNS, SMTP, FTP |
| 6 | Presentation | data | Format, compression, encryption (TLS sits here conceptually) |
| 5 | Session | data | Sets up and tears down sessions between hosts |
| 4 | Transport | segment | End-to-end delivery, flow control: TCP, UDP |
| 3 | Network | packet | Logical addressing and routing: IP |
| 2 | Data Link | frame | MAC addressing, delivery on one link: Ethernet, Wi-Fi |
| 1 | Physical | bits | Signals on the medium: cables, NIC electronics |
Layers 5 and 6 are rarely tested on their own; treat them as part of the application story. The Data Link layer carries more detail. It splits into two sublayers: LLC, which handles flow and error control to the layer above, and MAC, which handles media access and the physical (hardware) addresses. Layer 2 is also the only layer that adds a trailer as well as a header. That trailer is the Frame Check Sequence, covered below.
The layer numbers double as a troubleshooting map, which is why they come up constantly when you describe and isolate a fault. A hub repeats signals at Layer 1, a switch forwards frames by MAC address at Layer 2, and a router forwards packets by IP address at Layer 3. When a fault is labelled “Layer 1” it points at cabling or signal, “Layer 2” at switching, MAC, or VLAN, and “Layer 3” at IP addressing or routing. Naming the layer is the first step to naming the fix.
How the TCP/IP model maps to the OSI model
TCP/IP collapses the OSI layers into fewer. The original four-layer model from RFC 1122 merges OSI layers 5, 6, and 7 into one Application layer and merges Physical and Data Link into one layer that RFC 1122 calls the Link layer (many textbooks label it Network Access). Cisco certification material uses a five-layer variant that keeps Physical and Data Link separate, because Ethernet and Wi-Fi operate at two distinct layers and the distinction matters for switching.
| OSI layer | TCP/IP 4-layer (RFC 1122) | TCP/IP 5-layer (Cisco) |
|---|---|---|
| 7 Application, 6 Presentation, 5 Session | Application | Application |
| 4 Transport | Transport | Transport |
| 3 Network | Internet | Network |
| 2 Data Link | Link | Data Link |
| 1 Physical | Link | Physical |
People refer to layers by their OSI number even when the protocol is a TCP/IP one, so the OSI numbers are the ones to know regardless of which TCP/IP count is in front of you. (On the Cisco CCNA 200-301 exam, layer questions use OSI numbering for exactly this reason.) The side-by-side view makes the overlap obvious:
Encapsulation: how data travels down the stack
Encapsulation is the process of each layer wrapping the data from the layer above in its own header before passing it down. A web request makes this concrete. A browser sending an HTTP GET to a web server produces five steps, top to bottom:
- Layer 7 creates the application data: the HTTP GET request.
- Layer 4 adds a TCP header with source and destination ports, a sequence number, and flags. The unit is now a segment.
- Layer 3 adds an IP header with source and destination IP addresses. The unit is now a packet.
- Layer 2 adds an Ethernet header (destination MAC, source MAC, EtherType) and an FCS trailer. The unit is now a frame.
- Layer 1 converts the frame to electrical, optical, or radio signals: bits on the wire.
Each step keeps everything from the steps above it intact and prepends its own header. Only Layer 2 also appends a trailer. The PDU names (segment, packet, frame, bits) are the standard terminology, and they map directly to the layers that create them:
One detail decides a lot of routing questions: the IP packet is end-to-end, the frame is hop-to-hop. At each router the frame is stripped, the IP header is read for the routing decision, and a brand-new frame is built for the next link. The Layer 3 packet survives the whole journey; the Layer 2 frame is rebuilt at every hop. That is why a router reads and rewrites Layer 2 while routing on Layer 3, and it ties directly into how IP routing forwards packets.
De-encapsulation: the receiving side
De-encapsulation is encapsulation in reverse, bottom to top. The receiving host strips one header at each layer and hands the remainder up. The NIC receives the bits and reassembles the frame. Layer 2 checks the FCS for errors and strips the Ethernet header, passing the packet up. Layer 3 reads the IP header, confirms the packet is for this host, and passes the segment up. Layer 4 reads the TCP header, reorders and acknowledges as needed, and hands the data to the application. Each “strip” is one step of de-encapsulation.
Adjacent-layer and same-layer interaction
Two interaction terms are easy to mix up, and they describe different things. Adjacent-layer interaction is one layer providing a service to the layer directly above it on the same host: TCP on a host asks IP on that same host to deliver its segment. Same-layer interaction is the same layer on two different hosts communicating through the headers they exchange: TCP on host A sets a sequence number that TCP on host B reads and acknowledges. The header is the conversation between peer layers; the function call is the conversation between stacked layers.
Seeing the layers in a real capture
The fastest way to make the stack stop being abstract is to capture one packet and expand it. The capture has to be plain HTTP, not HTTPS, or TLS hides the application headers. Start a capture on the active interface in one terminal:
sudo tshark -i eth0 -f "tcp port 80" -w capture.pcapThen generate one plain-HTTP request from a second terminal. The neverssl.com site exists precisely so it never redirects to HTTPS:
curl http://neverssl.com/Stop the capture, then print the full protocol tree of the GET packet. The -V flag expands every layer:
tshark -r capture.pcap -Y http.request -VOne frame contains all the layers stacked in order, exactly as encapsulation built them: the Ethernet II header (Layer 2) with source and destination MAC and a Type of IPv4, the Internet Protocol header (Layer 3) with source and destination addresses, the Transmission Control Protocol header (Layer 4) with the ports and sequence number, and the Hypertext Transfer Protocol payload (Layer 7) with the GET line.
The “Frame” line at the top is Wireshark’s own metadata about the capture (length, interface, arrival time), not an OSI layer. The first real protocol layer is Ethernet II. Note what is missing: the FCS trailer. The four-byte Frame Check Sequence that Layer 2 appends is computed and validated by the NIC hardware, which strips it before the frame reaches the capture, so it rarely shows in Wireshark. It is still on the wire, and it is the only trailer any layer adds.
Filtering the same capture to the TCP port shows the three-way handshake that precedes the GET. This is same-layer interaction on display: the SYN carries Seq=0, the SYN-ACK answers with Ack=1, and the ACK confirms before any data moves. TCP on each host is talking to TCP on the other through these flags and numbers.
Application-layer protocols sit on top of this same stack. A DNS lookup rides Layer 4 (usually UDP) the same way HTTP rides TCP here, and the addressing the IP header carries is the same addressing covered in the subnetting guide.
Practice the OSI and TCP/IP models
Drill the layer numbers, PDU names, and encapsulation order with the flashcards, then test the mapping and interaction concepts on the quiz. The deck is also a downloadable Anki package for spaced repetition.
Now check yourself:
OSI and TCP/IP quick reference
Two tables to commit to memory. The OSI layers with their PDU names:
| Layer | Name | PDU |
|---|---|---|
| 7 | Application | data |
| 6 | Presentation | data |
| 5 | Session | data |
| 4 | Transport | segment |
| 3 | Network | packet |
| 2 | Data Link | frame |
| 1 | Physical | bits |
And the mapping from OSI to the Cisco five-layer TCP/IP model:
| OSI | TCP/IP (Cisco 5-layer) | Example protocols |
|---|---|---|
| 7, 6, 5 | Application | HTTP, DNS, FTP |
| 4 | Transport | TCP, UDP |
| 3 | Network | IP, ICMP |
| 2 | Data Link | Ethernet, Wi-Fi |
| 1 | Physical | Cabling, signals |
Learn the layer numbers and PDU names cold, keep the OSI-to-TCP/IP mapping in mind, and the rest of the CCNA syllabus reads as variations on where a protocol sits and what header it adds. The CCNA 200-301 study roadmap shows where this foundation leads next.
