Skip to main content

Network Models · Foundations

OSI and TCP IP Foundations

Page 1 of 4

Encapsulation, addressing, and layer models, explained with exact terms and safe practice.

Optional reading support. Use this only if it helps you read or focus.

Progress

Core path

Your path through this level

Progress saves in this browser and syncs after you sign in

Completed
0 of 8
You will be able to
  • Explain why layered reference models exist and when OSI helps more than the operational Internet view.
  • Use exact protocol data unit names and describe encapsulation without hand-waving.
  • Distinguish hostnames, IP addresses, MAC addresses, and ports using their actual responsibilities.

Pick up where you left off

A layered model separates communication functionsPDU naming prevents confusionMapping is approximateWhat belongs whereNames to addressesSubnet reasoningRequest flowProve the layer
Optional
Full module map
Use this if you want the shape of the level before you start
Show
Module 1.1A layered model separates communication functions
Use the model to identify the first function that failed. Do not treat OSI and TCP/IP as identical, and do not treat layers like folders on disk.
Open
Prerequisites
  • No previous technical background required
  • Read the section explanation before using tools
Outcomes
  1. Explain a layered model separates communication functions in your own words and apply it to a realistic scenario.
  2. Use the model to identify the first function that failed. Do not treat OSI and TCP/IP as identical, and do not treat layers like folders on disk.
  3. Check the assumption "The reference model is not the running stack" and explain what changes if it is false.
  4. Check the assumption "Evidence beats confidence" and explain what changes if it is false.
Practice
  • Complete one guided exercise and explain your decision in plain language
  • Use the recap only after reading the main section
Artefact and failure modes
  • A short module note with one key definition and one practical example
  • Reciting layers without naming the function. Layer talk can hide uncertainty. The goal is a testable statement about name resolution, transport, routing, link delivery, or application behaviour.
  • Forcing a perfect mapping. Do not pretend every protocol fits neatly into a schoolbook stack. Use the model to reason, not to flatten reality.
Module 1.2PDU naming prevents confusion
Segment, packet, and frame are not synonyms. Naming the unit clarifies the layer.
Open
Prerequisites
  • No previous technical background required
  • Read the section explanation before using tools
Outcomes
  1. Explain pdu naming prevents confusion in your own words and apply it to a realistic scenario.
  2. Segment, packet, and frame are not synonyms. Naming the unit clarifies the layer.
  3. Check the assumption "Encapsulation has direction" and explain what changes if it is false.
  4. Check the assumption "You can name the unit" and explain what changes if it is false.
Practice
  • Complete one guided exercise and explain your decision in plain language
  • Use the recap only after reading the main section
Artefact and failure modes
  • A short module note with one key definition and one practical example
  • Packet for everything. Using one word for everything hides the problem. Be precise.
  • Mixing data and headers. People forget which headers belong to which layer. The model fixes that.
Module 1.3Mapping is approximate
OSI and TCP/IP map loosely. Do not force a perfect one to one story.
Open
Prerequisites
  • No previous technical background required
  • Read the section explanation before using tools
Outcomes
  1. Explain mapping is approximate in your own words and apply it to a realistic scenario.
  2. OSI and TCP/IP map loosely. Do not force a perfect one to one story.
  3. Check the assumption "The mapping is a learning aid" and explain what changes if it is false.
  4. Check the assumption "Real stacks blur layers" and explain what changes if it is false.
Practice
  • Complete one guided exercise and explain your decision in plain language
  • Use the recap only after reading the main section
Artefact and failure modes
  • A short module note with one key definition and one practical example
  • One to one myth. Forcing a perfect mapping creates confident wrong answers.
  • Treating layers as ownership. Layers are responsibilities, not team boundaries.
Module 1.4What belongs where
Layer thinking works when you can place a protocol at a layer for a reason.
Open
Prerequisites
  • No previous technical background required
  • Read the section explanation before using tools
Outcomes
  1. Explain what belongs where in your own words and apply it to a realistic scenario.
  2. Layer thinking works when you can place a protocol at a layer for a reason.
  3. Check the assumption "You can justify placement" and explain what changes if it is false.
  4. Check the assumption "Boundaries are conceptual" and explain what changes if it is false.
Practice
  • Complete one guided exercise and explain your decision in plain language
  • Use the recap only after reading the main section
Artefact and failure modes
  • A short module note with one key definition and one practical example
  • Layer confusion. If you cannot say what a layer does, you cannot troubleshoot it.
  • Blaming a layer. Layers are not enemies. They are a way to ask the right next question.
Module 1.5Names to addresses
Names are for humans. Addresses are for routing. DNS is the bridge.
Open
Prerequisites
  • No previous technical background required
  • Read the section explanation before using tools
Outcomes
  1. Explain names to addresses in your own words and apply it to a realistic scenario.
  2. Names are for humans. Addresses are for routing. DNS is the bridge.
  3. Check the assumption "Caching exists" and explain what changes if it is false.
  4. Check the assumption "You can inspect" and explain what changes if it is false.
Practice
  • Complete one guided exercise and explain your decision in plain language
  • Use the recap only after reading the main section
Artefact and failure modes
  • A short module note with one key definition and one practical example
  • DNS blamed without proof. DNS is often the cause, but not always. Test it.
  • Stale cache surprises. Old answers can persist. Know where caching occurs.
Module 1.6Subnet reasoning
Subnetting is about what is local, what is routed, and what must be sent to a gateway.
Open
Prerequisites
  • No previous technical background required
  • Read the section explanation before using tools
Outcomes
  1. Explain subnet reasoning in your own words and apply it to a realistic scenario.
  2. Subnetting is about what is local, what is routed, and what must be sent to a gateway.
  3. Check the assumption "CIDR is a model" and explain what changes if it is false.
  4. Check the assumption "Gateways exist" and explain what changes if it is false.
Practice
  • Complete one guided exercise and explain your decision in plain language
  • Use the recap only after reading the main section
Artefact and failure modes
  • A short module note with one key definition and one practical example
  • Off by one ranges. Small mistakes create big confusion. Work carefully and verify.
  • Mixing address and network. A host address and a network address are different things. Keep them separate.
Module 1.7Request flow
A web request is a chain. Diagnose the chain step by step.
Open
Prerequisites
  • No previous technical background required
  • Read the section explanation before using tools
Outcomes
  1. Explain request flow in your own words and apply it to a realistic scenario.
  2. A web request is a chain. Diagnose the chain step by step.
  3. Check the assumption "Order matters" and explain what changes if it is false.
  4. Check the assumption "Each step is testable" and explain what changes if it is false.
Practice
  • Complete one guided exercise and explain your decision in plain language
  • Use the recap only after reading the main section
Artefact and failure modes
  • A short module note with one key definition and one practical example
  • Misdiagnosed slowness. People blame the server when DNS is slow, or blame the network when the server is slow. Measure.
  • Skipping evidence. Troubleshooting without evidence becomes superstition.
Module 1.8Prove the layer
A good troubleshooting note states the layer, the evidence, and the next test.
Open
Prerequisites
  • No previous technical background required
  • Read the section explanation before using tools
Outcomes
  1. Explain prove the layer in your own words and apply it to a realistic scenario.
  2. A good troubleshooting note states the layer, the evidence, and the next test.
  3. Check the assumption "You state assumptions" and explain what changes if it is false.
  4. Check the assumption "You change one variable" and explain what changes if it is false.
Practice
  • Complete one guided exercise and explain your decision in plain language
  • Use the recap only after reading the main section
Artefact and failure modes
  • A short module note with one key definition and one practical example
  • Guessing. Guessing is how problems become long and expensive. Tests are cheaper.
  • Tool worship. Tools help, but the model is what makes tool output meaningful.
Optional
Planning and evidence
Objectives, timing, and CPD tracking
Show

If you want to start learning now, leave this closed. Come back when you want to plan your practice or keep evidence for CPD. This is guidance and it is not endorsed by awarding bodies. Standards mapping lives on the course overview page.

Learning objectives

What you will be able to do

  1. 1. Explain why layered reference models exist and when OSI helps more than the operational Internet view.
    Layers exist to make problems explainable, so I start with the why.
  2. 2. Use exact protocol data unit names and describe encapsulation without hand-waving.
    Encapsulation is the core mechanic behind everything you will troubleshoot.
  3. 3. Distinguish hostnames, IP addresses, MAC addresses, and ports using their actual responsibilities.
    Addressing terms are often confused, so we fix that early.
  4. 4. Trace a web request from URL to first byte and identify where each failure would first appear.
    Layered troubleshooting stops guessing and speeds fixes.
What comes next
Next we handle TCP, UDP, NAT, and routing because those are the faults you meet in the wild.
Continue to Applied

What changes at this level

Level expectations

Each level is independent but clearly deeper than the last. This panel makes the jump explicit.

Assessment intent
Foundations

Correct vocabulary and correct layering. Encapsulation and flows explained cleanly.

Style
mixed
25 questions
40 min timed
Pass standard
80%
Not externally certified
▸Evidence you can save (CPD friendly)
  • An encapsulation storyboard for one real flow: DNS → TCP → TLS → HTTP, with correct PDU names at each step.
  • A small glossary you wrote yourself: MAC vs IP vs port vs name, plus one example for each.
  • A troubleshooting log for one issue you have seen: symptom, evidence, layer, fix, and what you ruled out.

CPD timing

Foundations time breakdown

Defensible timing based on page content: reading, labs, checkpoints, and reflection.

Reading
30m
4,416 words × 1.3
Practice
60m
4 × 15m
Checkpoints
40m
8 × 5m
Reflection
64m
8 × 8m
Estimated total
3h 14m
Based on page content
Claimed hours
3h
Includes reattempts + capstone

CPD tracking

Fixed hours for this level are 3. Timed assessment time is included once on pass.

View in My CPD
Sign in to sync progress and unlock assessments
Progress minutes
0.0 hours

Learning objectives

What you will be able to do

  1. 1. Explain why layered reference models exist and when OSI helps more than the operational Internet view.
    Layers exist to make problems explainable, so I start with the why.
  2. 2. Use exact protocol data unit names and describe encapsulation without hand-waving.
    Encapsulation is the core mechanic behind everything you will troubleshoot.
  3. 3. Distinguish hostnames, IP addresses, MAC addresses, and ports using their actual responsibilities.
    Addressing terms are often confused, so we fix that early.
  4. 4. Trace a web request from URL to first byte and identify where each failure would first appear.
    Layered troubleshooting stops guessing and speeds fixes.
What comes next
Next we handle TCP, UDP, NAT, and routing because those are the faults you meet in the wild.
Continue to Applied

What changes at this level

Level expectations

Each level is independent but clearly deeper than the last. This panel makes the jump explicit.

Assessment intent
Foundations

Correct vocabulary and correct layering. Encapsulation and flows explained cleanly.

Style
mixed
25 questions
40 min timed
Pass standard
80%
Not externally certified
▸Evidence you can save (CPD friendly)
  • An encapsulation storyboard for one real flow: DNS → TCP → TLS → HTTP, with correct PDU names at each step.
  • A small glossary you wrote yourself: MAC vs IP vs port vs name, plus one example for each.
  • A troubleshooting log for one issue you have seen: symptom, evidence, layer, fix, and what you ruled out.

Learning contract

Foundations outcomes

About 3 hours

Read the explanation first, then use the tools to test the idea. Skip any tool that is not useful for your goal.

  1. Explain why layered reference models exist and when OSI helps more than the operational Internet view.
  2. Use exact protocol data unit names and describe encapsulation without hand-waving.
  3. Distinguish hostnames, IP addresses, MAC addresses, and ports using their actual responsibilities.
  4. Trace a web request from URL to first byte and identify where each failure would first appear.
Loading content...

Next step

Practise this level, then take the timed assessment

I recommend you start with the practice assessment for Foundations. It is not timed and it helps you write a clear CPD reflection before the full assessment.

25

Questions

40

Minutes

80%

Pass mark

Practice assessment

Start the practice assessment for Foundations

It is designed for confidence and evidence, and you can retry as often as you need.

Start practice assessment

Full assessment

Network models Foundations assessment

This assessment is timed. It is free to take and you can retry as often as you need.

  • Detailed feedback on every question
  • Pass evidence recorded in your account on pass
  • Personalised recommendations on weak areas
Sign in to start the full assessment

Sign in to save progress and keep your pass record

You can complete the course while signed out, and your progress saves in this browser. Sign in before assessments so your pass record is attached to your account.

Sign in for trackingContinue to Applied

Courses and assessments are free. There is no paywall for the learning path, practice questions, or formal assessments.

During timed assessments, copy and the context menu are restricted to reduce casual cheating. Passed assessments are recorded in your account as evidence.