Skip to main content

Network Models · Applied

Applied OSI and TCP IP

Page 2 of 4

TCP, UDP, routing, NAT, and TLS, with realistic troubleshooting.

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 TCP, UDP, QUIC, DNS, routing, NAT, TLS, and HTTP variants with standards-led precision.
  • Turn vague symptoms into timing, state, and path evidence.
  • Diagnose slow or failing requests using a repeatable, source-aligned method.

Pick up where you left off

TCP reliabilityDNS resolution pathUDP vs TCP choiceHop by hop forwardingNAT is stateTLS boundaryTest orderA defensible write-up
Optional
Full module map
Use this if you want the shape of the level before you start
Show
Module 2.1TCP reliability
TCP reliability is ordering, retransmission, and flow control. It is measurable.
Open
Prerequisites
  • Foundations-level vocabulary and concepts
  • Confidence with basic diagrams and section terminology
Outcomes
  1. Explain tcp reliability in your own words and apply it to a realistic scenario.
  2. TCP reliability is ordering, retransmission, and flow control. It is measurable.
  3. Check the assumption "Reliability has meaning" and explain what changes if it is false.
  4. Check the assumption "Congestion exists" and explain what changes if it is false.
Practice
  • Work through one scenario and justify the decision with evidence
  • Compare two options and name the trade-off clearly
Artefact and failure modes
  • A one-page decision note with assumption, evidence, and chosen action
  • Latency blamed on bandwidth. A slow page can be latency, not throughput. Measure the step that is slow.
  • Packet loss hidden. Loss can look like slowness. Evidence helps you see it.
Module 2.2DNS resolution path
DNS is a multi-hop lookup with caching. Failures often hide in caches.
Open
Prerequisites
  • Foundations-level vocabulary and concepts
  • Confidence with basic diagrams and section terminology
Outcomes
  1. Explain dns resolution path in your own words and apply it to a realistic scenario.
  2. DNS is a multi-hop lookup with caching. Failures often hide in caches.
  3. Check the assumption "Caching layers exist" and explain what changes if it is false.
  4. Check the assumption "TTL matters" and explain what changes if it is false.
Practice
  • Work through one scenario and justify the decision with evidence
  • Compare two options and name the trade-off clearly
Artefact and failure modes
  • A one-page decision note with assumption, evidence, and chosen action
  • Stale caches. If you update DNS but caches hold old values, behaviour looks random.
  • Resolver differences. Different resolvers can behave differently. Know which one you are using.
Module 2.3UDP vs TCP choice
UDP trades reliability for simplicity and latency. That can be correct, not careless.
Open
Prerequisites
  • Foundations-level vocabulary and concepts
  • Confidence with basic diagrams and section terminology
Outcomes
  1. Explain udp vs tcp choice in your own words and apply it to a realistic scenario.
  2. UDP trades reliability for simplicity and latency. That can be correct, not careless.
  3. Check the assumption "Loss is acceptable" and explain what changes if it is false.
  4. Check the assumption "Timing matters" and explain what changes if it is false.
Practice
  • Work through one scenario and justify the decision with evidence
  • Compare two options and name the trade-off clearly
Artefact and failure modes
  • A one-page decision note with assumption, evidence, and chosen action
  • Assuming reliability. UDP does not guarantee delivery. If you need guarantees, design them.
  • Ignoring congestion. UDP can overwhelm networks if used carelessly. Responsible design matters.
Module 2.4Hop by hop forwarding
Routing decides a path. Forwarding moves packets to the next hop.
Open
Prerequisites
  • Foundations-level vocabulary and concepts
  • Confidence with basic diagrams and section terminology
Outcomes
  1. Explain hop by hop forwarding in your own words and apply it to a realistic scenario.
  2. Routing decides a path. Forwarding moves packets to the next hop.
  3. Check the assumption "Routes converge" and explain what changes if it is false.
  4. Check the assumption "Asymmetry can exist" and explain what changes if it is false.
Practice
  • Work through one scenario and justify the decision with evidence
  • Compare two options and name the trade-off clearly
Artefact and failure modes
  • A one-page decision note with assumption, evidence, and chosen action
  • Asymmetric paths. Asymmetry can break stateful systems and confuse captures.
  • Black holes. A missing route can drop traffic quietly. Evidence reveals where.
Module 2.5NAT is state
NAT works by keeping state. Timeouts and collisions create real failure modes.
Open
Prerequisites
  • Foundations-level vocabulary and concepts
  • Confidence with basic diagrams and section terminology
Outcomes
  1. Explain nat is state in your own words and apply it to a realistic scenario.
  2. NAT works by keeping state. Timeouts and collisions create real failure modes.
  3. Check the assumption "State has timeouts" and explain what changes if it is false.
  4. Check the assumption "Port space is limited" and explain what changes if it is false.
Practice
  • Work through one scenario and justify the decision with evidence
  • Compare two options and name the trade-off clearly
Artefact and failure modes
  • A one-page decision note with assumption, evidence, and chosen action
  • Timeout confusion. A broken connection can look like an application bug when NAT state expired.
  • Port exhaustion. Under heavy load, new connections fail even though routing is fine.
Module 2.6TLS boundary
TLS protects data in transit. It does not validate the application’s decisions.
Open
Prerequisites
  • Foundations-level vocabulary and concepts
  • Confidence with basic diagrams and section terminology
Outcomes
  1. Explain tls boundary in your own words and apply it to a realistic scenario.
  2. TLS protects data in transit. It does not validate the application’s decisions.
  3. Check the assumption "Certificates are validated" and explain what changes if it is false.
  4. Check the assumption "Trust is explicit" and explain what changes if it is false.
Practice
  • Work through one scenario and justify the decision with evidence
  • Compare two options and name the trade-off clearly
Artefact and failure modes
  • A one-page decision note with assumption, evidence, and chosen action
  • TLS as a magic shield. TLS does not prevent unsafe queries, broken auth, or bad business logic.
  • Name mismatch. The certificate can be valid and still not be for the service you meant to reach.
Module 2.7Test order
A good method tests in order and changes one variable at a time.
Open
Prerequisites
  • Foundations-level vocabulary and concepts
  • Confidence with basic diagrams and section terminology
Outcomes
  1. Explain test order in your own words and apply it to a realistic scenario.
  2. A good method tests in order and changes one variable at a time.
  3. Check the assumption "One step at a time" and explain what changes if it is false.
  4. Check the assumption "Write down evidence" and explain what changes if it is false.
Practice
  • Work through one scenario and justify the decision with evidence
  • Compare two options and name the trade-off clearly
Artefact and failure modes
  • A one-page decision note with assumption, evidence, and chosen action
  • Random fixes. Random fixes sometimes work and teach you nothing. Method teaches you.
  • Tool spam. More tools does not mean more clarity. Choose the right test for the layer.
Module 2.8A defensible write-up
A good write-up names the layer, the evidence, and the next step.
Open
Prerequisites
  • Foundations-level vocabulary and concepts
  • Confidence with basic diagrams and section terminology
Outcomes
  1. Explain a defensible write-up in your own words and apply it to a realistic scenario.
  2. A good write-up names the layer, the evidence, and the next step.
  3. Check the assumption "Assumptions are explicit" and explain what changes if it is false.
  4. Check the assumption "Next steps are testable" and explain what changes if it is false.
Practice
  • Work through one scenario and justify the decision with evidence
  • Compare two options and name the trade-off clearly
Artefact and failure modes
  • A one-page decision note with assumption, evidence, and chosen action
  • Hand-wavy claims. If you cannot back a claim with evidence, it is not yet useful.
  • No follow-up. If you do not follow up, the same incident returns.
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 TCP, UDP, QUIC, DNS, routing, NAT, TLS, and HTTP variants with standards-led precision.
    TCP and UDP behaviour drives real performance and reliability.
  2. 2. Turn vague symptoms into timing, state, and path evidence.
    Routing and forwarding are invisible until they fail, so you need clear mental models.
  3. 3. Diagnose slow or failing requests using a repeatable, source-aligned method.
    NAT behaviour creates tricky failures that people misdiagnose.
What comes next
Next we focus on monitoring and security because that is how you keep networks healthy.
Continue to Practice & Strategy

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
Applied

Prove behaviour with evidence. TCP, UDP, NAT, routing, TLS, and common failure modes.

Style
scenario
25 questions
40 min timed
Pass standard
80%
Not externally certified
▸Evidence you can save (CPD friendly)
  • A timing breakdown note: DNS, TCP connect, TLS handshake, TTFB, download. Include what each step implies.
  • A NAT and state explanation with one failure mode (timeouts, UDP fragility, or hairpinning) and how you would prove it.
  • A layer-based troubleshooting checklist you can run under pressure, including what tool output counts as evidence.

CPD timing

Applied time breakdown

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

Reading
26m
3,917 words × 1.3
Practice
60m
4 × 15m
Checkpoints
40m
8 × 5m
Reflection
64m
8 × 8m
Estimated total
3h 10m
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 TCP, UDP, QUIC, DNS, routing, NAT, TLS, and HTTP variants with standards-led precision.
    TCP and UDP behaviour drives real performance and reliability.
  2. 2. Turn vague symptoms into timing, state, and path evidence.
    Routing and forwarding are invisible until they fail, so you need clear mental models.
  3. 3. Diagnose slow or failing requests using a repeatable, source-aligned method.
    NAT behaviour creates tricky failures that people misdiagnose.
What comes next
Next we focus on monitoring and security because that is how you keep networks healthy.
Continue to Practice & Strategy

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
Applied

Prove behaviour with evidence. TCP, UDP, NAT, routing, TLS, and common failure modes.

Style
scenario
25 questions
40 min timed
Pass standard
80%
Not externally certified
▸Evidence you can save (CPD friendly)
  • A timing breakdown note: DNS, TCP connect, TLS handshake, TTFB, download. Include what each step implies.
  • A NAT and state explanation with one failure mode (timeouts, UDP fragility, or hairpinning) and how you would prove it.
  • A layer-based troubleshooting checklist you can run under pressure, including what tool output counts as evidence.

Learning contract

Applied 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 TCP, UDP, QUIC, DNS, routing, NAT, TLS, and HTTP variants with standards-led precision.
  2. Turn vague symptoms into timing, state, and path evidence.
  3. Diagnose slow or failing requests using a repeatable, source-aligned method.
Loading content...

Next step

Practise this level, then take the timed assessment

I recommend you start with the practice assessment for Applied. 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 Applied

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

Start practice assessment

Full assessment

Network models Applied 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 Practice and strategy

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.