OSI and TCP/IP organize networking for different reasons
The OSI model is a seven-layer reference model designed to separate networking functions conceptually. The TCP/IP model is closer to the actual Internet protocol suite and is commonly shown with four or five layers. Both are useful, but they are not identical diagrams with different labels. The real value comes from understanding how responsibilities, protocols, and troubleshooting evidence map across the two.
Use AP Networking OSI and Encapsulation Practice Test to apply the models without forcing a one-to-one implementation map. Its three levels follow encapsulation, per-hop framing, transport demultiplexing and the evidence needed to separate a lower prerequisite from application success.
TCP/IP compresses several OSI layers into broader practical groups
| OSI layer/function | TCP/IP grouping | Examples |
|---|---|---|
| 7 Application | Application | HTTP, DNS, SMTP, application protocols |
| 6 Presentation | Data representation, encryption-related functions | |
| 5 Session | Session/dialog management concepts | |
| 4 Transport | Transport | TCP, UDP, ports |
| 3 Network | Internet | IP, ICMP, routing |
| 2 Data Link | Link / Network Access | Ethernet, Wi-Fi framing, MAC, VLANs |
| 1 Physical | Copper, fiber, radio, signaling |
Swipe horizontally to see the full mapping table.
Some courses split Link into Data Link and Physical for easier comparison
The TCP/IP model is sometimes shown as four layers and sometimes as five. In the five-layer version, Physical and Data Link are separated instead of being grouped together. That difference is mostly presentational. What matters is whether you can identify the actual networking function being discussed.
Physical concerns whether bits can move across the medium
Layer 1 covers signal transmission, cabling, fiber, radio, connectors, transceivers, and electrical/optical behavior. A link can fail here because of a damaged cable, dead optic, interference, or loss of signal.
A healthy physical link is only the first checkpoint. It does not prove VLANs, IP addressing, routing, or applications.
Data Link handles local framing, switching, MAC addressing, and VLAN behavior
Ethernet switching, MAC tables, local broadcasts, VLAN membership, and frame delivery belong here conceptually. A device can have a working physical link yet still be in the wrong VLAN or unable to resolve its gateway locally.
Network/Internet handles logical addressing and routed path selection
IPv4/IPv6 addressing, routing tables, next hops, subnet boundaries, and ICMP behavior belong here. A successful ping to a remote numeric IP is useful Layer 3 evidence, but it does not prove DNS or a TCP application.
Transport introduces ports, end-to-end delivery behavior, and service-specific reachability
TCP and UDP sit at the transport layer. Once Layer 3 reachability is established, Layer 4 answers a more specific question: can the client reach the required transport endpoint, such as TCP 443 for HTTPS or UDP/TCP 53 for DNS?
The upper OSI layers separate session, representation, and application concepts
OSI distinguishes session management, presentation/representation, and application behavior. TCP/IP typically groups those functions into one Application layer. This is one reason the models should not be treated as a perfect one-to-one conversion chart.
OSI gives troubleshooting language more granularity
You can say “the physical link is good, but the VLAN is wrong,” or “IP routing works, but the TCP port is blocked.” That vocabulary helps teams avoid vague statements such as “the network is down.”
Physical
Can the medium carry a signal?
Data Link
Can frames move correctly on the local segment?
Network
Can IP packets be routed to the destination?
Transport
Can the required port/session be reached?
Upper layers
Can the actual application transaction succeed?
TCP/IP mirrors the real protocols used by modern IP networks
When following a real request, TCP/IP is intuitive: an application such as HTTPS uses TCP, TCP uses IP, and IP rides over a local link such as Ethernet or Wi-Fi. The model maps naturally to packet captures and command-line troubleshooting.
Each layer adds information needed by the layer below it
Application data is passed downward through the stack. Transport adds information such as ports and sequencing for TCP. IP adds source/destination logical addressing. The local link adds frame information for the current hop. At the receiver, those layers are processed in reverse.
The Layer 2 frame changes at each routed hop while the Layer 3 packet continues toward the destination
When a router forwards an IP packet from one link to another, it removes the incoming link-layer frame and creates a new frame appropriate for the outgoing link. The destination IP remains focused on the final host, while local MAC addressing changes hop by hop.
Some real technologies cross conceptual boundaries
TLS provides encryption, authentication, and secure-session behavior often associated conceptually with OSI presentation/session responsibilities. In real Internet stacks, TLS usually operates above TCP and below an application such as HTTPS.
This is a perfect example of why the models are explanatory tools rather than rigid laws.
DNS is an application-layer protocol even though it supports almost every other application
DNS maps names to addresses and other records. In TCP/IP it sits at the Application layer. It uses UDP and TCP at Transport and IP beneath that. A DNS failure can therefore exist even while Layer 3 reachability is healthy.
Both models teach the same dependency discipline
You do not need to restart at Layer 1 after a later checkpoint succeeds. Preserve proven dependencies and test the first unresolved layer/function.
Link light is on, but the client cannot reach its gateway
Evidence: physical carrier exists. The client is placed in the wrong VLAN and ARP for the intended gateway fails.
Interpretation: Layer 1 is healthy enough for link, while Layer 2 placement is the first demonstrated failure.
Gateway and remote IP work, but hostname fails
Evidence: local and routed IP reachability are proven. DNS queries time out.
Interpretation: lower layers are working; Application-layer DNS resolution is the first unresolved dependency.
Ping succeeds but HTTPS fails
Evidence: ICMP/IP path works. TCP 443 times out.
Interpretation: Layer 3 success does not prove Layer 4 transport or HTTPS application health. Inspect TCP/443 policy, route, listener, TLS, and app behavior.
TCP 443 connects, but the browser reports a certificate error
Evidence: network and transport connectivity are working well enough to establish TCP.
Interpretation: the first visible failure is now in secure upper-layer/session/application behavior rather than basic IP reachability.
HTTP returns 200 but the application transaction is still wrong
Evidence: application-layer HTTP response succeeded, but the returned content is incorrect because the backend database has stale data.
Interpretation: lower network layers are healthy; the failure is above basic network transport.
Each artifact proves only its own layer/function
| Artifact | Supports | Still unproven |
|---|---|---|
| Link light | Physical carrier | VLAN/IP/app |
| MAC table | Layer 2 learning | Routing/application |
| Ping remote IP | ICMP/IP path | DNS/TCP/app |
| TCP handshake | Transport to a port | Application correctness |
| HTTP 200 | Application transaction response | Backend data correctness |
Swipe horizontally to see the evidence matrix.
Do not treat layer labels as a substitute for evidence
- Layer 1 success does not prove Layer 2 configuration.
- Layer 2 success does not prove routing.
- Layer 3 reachability does not prove TCP/UDP service access.
- Transport success does not prove the application works correctly.
- DNS is an application-layer service even though almost every user workflow depends on it.
- TLS does not fit perfectly into a single rigid OSI box.
- The TCP/IP layer count can vary by presentation; the functions matter more.
Learn function → protocol → evidence before memorizing numbers
Instead of only memorizing “Layer 3 = Network,” practice saying: “Layer 3 handles IP addressing and routing; a route table, IP configuration, or ICMP reachability test is relevant evidence.” This creates usable knowledge that transfers to unfamiliar scenarios.
ARP is a perfect example of why layer mapping must follow the function, not just the acronym
On IPv4 Ethernet networks, ARP helps a host discover the MAC address associated with a local IPv4 next hop. That makes it closely tied to local link delivery even though the question starts with an IP address. If a client cannot resolve its default gateway's MAC address, the immediate failure is local delivery—not remote routing or DNS.
This is why a good model explanation should name both the function and the evidence instead of forcing every protocol into a simplistic memorization box.
Wrong VLAN and wrong route can create similar user symptoms at different layers
A client in the wrong VLAN may receive the wrong subnet, fail to reach the intended gateway, or reach a completely different policy zone. A client in the correct VLAN with a bad route may communicate locally but fail when traffic must leave the subnet.
| Observation | Stronger layer/function | Useful artifact |
|---|---|---|
| Wrong subnet/DHCP lease | Layer 2 placement / local design | Switchport, SSID-to-VLAN mapping, DHCP scope |
| Gateway reachable, remote subnet fails | Layer 3 routing | Route table, traceroute, next-hop state |
| Remote IP works, hostname fails | Application service dependency | DNS query |
| IP path works, TCP 443 fails | Transport/policy | Socket test, firewall log |
Swipe horizontally to see the troubleshooting comparison.
Ports belong to Transport, but the service meaning comes from the Application layer
TCP port 443 is a transport-layer endpoint. HTTPS is the application-layer protocol that commonly uses it. That distinction matters because “TCP 443 is reachable” proves something different from “the HTTPS application is healthy.”
This layered interpretation is much more useful than simply labeling all three observations “Layer 7.”
A packet capture lets you see several layers at once
One captured web packet can contain an Ethernet frame, an IP packet, a TCP segment, and application data. The capture therefore becomes a practical way to connect the abstract models to real protocol headers.
When a router forwards the packet, the Ethernet header changes for the next link, while the IP destination continues toward the final host. That visible behavior makes encapsulation and routed-hop boundaries concrete.
Layer labels can become misleading when they replace actual troubleshooting evidence
Saying “it is a Layer 3 issue” is only useful if you can explain the failed Layer 3 dependency: wrong IP address, missing route, unreachable next hop, or another network-layer problem. Likewise, “Layer 7 issue” is too broad unless you can identify DNS, TLS, HTTP, application logic, or another upper-layer dependency.
“Website does not load” can originate almost anywhere in the stack
| Failure | Layer/function | User symptom |
|---|---|---|
| Wi-Fi link lost | Physical/Link | Site does not load |
| Wrong VLAN | Data Link | Site does not load |
| Missing default route | Network/Internet | Site does not load |
| TCP 443 blocked | Transport/policy | Site does not load |
| DNS failure | Application dependency | Site does not load by name |
| HTTP 500 | Application | Site fails despite network path |
Swipe horizontally to see how one symptom maps to different failure layers.
Each successful test lets you move one dependency higher without re-proving everything below it
If the first six checkpoints succeed and the application returns an error, replacing the cable is not a high-information next step. The model helps preserve proven layers while moving the investigation upward.
VPN connects, but one internal application still fails
Evidence: the VPN tunnel is established, internal DNS resolves the application name, and the route table contains the correct private prefix. TCP 443 to the application times out.
Interpretation: link, IP, VPN path, and DNS are already demonstrated. The unresolved boundary is transport/policy or the destination listener. The model prevents you from restarting with basic connectivity tests.
TCP connects, TLS succeeds, but the web application returns an authorization error
Evidence: network path, transport, and secure session are healthy enough to complete. The user receives an application-generated authorization response.
Interpretation: lower layers are functioning; the failure is in application identity, authorization, or business logic.
Use OSI for precision and TCP/IP for following real protocol stacks
OSI is especially useful when you want to distinguish physical media, local-link delivery, routing, transport, and upper-layer behavior. TCP/IP is especially useful when you want to trace a real Internet transaction from HTTP/DNS through TCP or UDP, then IP, then the link.
In practice, experienced troubleshooters move between both vocabularies. They care less about defending one diagram and more about identifying the dependency that failed.
24 OSI vs. TCP/IP digital flashcards
Practice layer mapping, protocols, encapsulation, troubleshooting order, TLS/DNS placement, and evidence boundaries.