Applied OSI and TCP IP

In foundations we built language and the basic flow. Here we get more exact about behaviour. We focus on what you can prove using inspection, not what you can recite.

TCP provides a reliable byte stream between two endpoints. Reliable means three specific things.

1. Data is delivered in order.
2. Data is retransmitted if it is lost.
3. Data is protected against corruption using checksums.

TCP also manages flow control so a fast sender does not overwhelm a slow receiver. It also performs congestion control so the network is not overwhelmed.

Worked example. “The server is slow” vs “the network is slow”

A page loads slowly. People immediately blame the server or “the Internet”. The applied way to think is: what is slow, exactly. DNS resolution. TCP connection establishment. TLS handshake. Or the request/response once the connection is established.

My opinion: if you cannot say which step is slow, you do not yet have a problem statement. You have a feeling.

Maths ladder (optional). RTT, throughput, and why distance matters

This section is here for two reasons. First, networks are graphs and queues, whether you like it or not. Second, protocols are state machines, whether the spec admits it politely or not. If you understand those three lenses, a lot of “network mystery” evaporates.

Graph theory lens. Routing as a shortest path problem

Treat routers as nodes and links as edges. Routing is a path selection problem on that graph. In link-state routing (conceptually), each router learns a view of the topology and computes paths. You do not need to run Dijkstra by hand, but you should understand what the algorithm is doing for you.

Queueing lens. Latency is waiting time under load

At a very blunt level, every interface is a queue. Packets wait when the sender is faster than the link. As utilisation approaches 100%, queueing delay grows quickly. This is why “it works fine until peak hours” is a predictable story.

A simple mental model: if arrivals are near the service rate, the system becomes sensitive to bursts. You then see increased latency, drops, and retransmissions. People interpret that as “random slowness”. It is not random. It is saturation plus burstiness.

State machine lens. Protocols are behaviour, not packets

Protocols like TCP are easier to reason about as finite state machines: LISTEN, SYN-SENT, ESTABLISHED, FIN-WAIT, and so on. This is not academic. It is how you explain why a socket is stuck, why TIME-WAIT exists, and why resets happen.

Verification. Three “maths” questions that make you faster

• Graph: what path is being selected, and why.
• Queue: where is waiting happening, and is it load driven or loss driven.
• State: what state is each endpoint in, and what event would move it forward.

Common mistakes (TCP edition)

• Treating “reliable” as “fast”. TCP can be reliable and still slow under loss and high RTT.
• Thinking TCP “sends packets”. TCP provides a byte stream; IP carries packets; link carries frames.
• Forgetting that congestion control is a feature, not an error. It is TCP trying not to melt the network.

Verification. What you should be able to explain from a capture

• Identify the SYN, SYN-ACK, ACK handshake.
• Explain what sequence and acknowledgement numbers represent (ordering and confirmation).
• Explain what a retransmission indicates (loss or missing acknowledgement).

When DNS fails, people often blame the Internet. I try to be more exact. I ask which step failed.

Common mistakes (DNS edition)

• Treating “DNS is down” as one thing. It could be local resolver, upstream resolver, cache, or network reachability.
• Forgetting caching exists, then being confused when “it worked for me” but not for others.
• Mixing “name” problems and “connection” problems. If you have an IP, you have moved past DNS.

Verification. The DNS steps you should be able to narrate

• Client asks resolver.
• Resolver answers from cache or queries upstream.
• Response contains records (A/AAAA/CNAME) and TTLs that drive caching behaviour.

UDP is a connectionless transport. It sends datagrams. It does not provide ordering or retransmission.

This is not always a weakness. Some applications implement reliability themselves. Some applications prefer timeliness over perfect delivery.

Examples you will see often:

1. DNS commonly uses UDP for queries.
2. Real time audio and video often uses UDP based transports.
3. Modern web transports can run over UDP based protocols such as QUIC.

Verification. When UDP is the right choice

• When timeliness matters more than perfect delivery (some real-time media).
• When the application provides its own recovery or ordering.
• When you want to avoid some TCP behaviours (for example head-of-line blocking) and the protocol is designed for it.

Routing is how a device decides which next hop to use for a destination. Forwarding is the act of moving a packet from one interface to another based on that decision.

Switching is different. A switch forwards frames inside a local network using MAC addresses. A router forwards packets across networks using IP addresses.

This is why you can have a perfect Wi Fi link and still fail to reach a remote site.

Common mistakes (routing edition)

• Assuming “no traceroute hop” means “no route”. Some devices do not reply, or replies are filtered.
• Confusing switching and routing when diagnosing failures.
• Forgetting that the default route exists. Many failures are “no route for this destination”.

Verification. The TTL story

• TTL decreases at each router hop.
• When TTL hits zero, a router may send back “time exceeded”.
• Traceroute uses this behaviour to infer a path, imperfectly.

Network Address Translation changes addresses as packets pass through a device. The most common pattern is translating many private addresses to one public address.

NAT is not the same thing as a firewall. Many devices combine NAT with stateful filtering, which is why people confuse them.

Common failure patterns:

1. The mapping expires and breaks a long lived flow.
2. A port is reused and traffic is delivered to the wrong internal endpoint.
3. An inbound flow is blocked because there is no mapping and no explicit rule.

Common mistakes (NAT edition)

• Thinking NAT provides security by itself. It does not. It is translation.
• Forgetting timeouts exist, then being confused when long-lived connections die.
• Using protocols that embed IP/port information without considering NAT traversal behaviour.

Verification. What the NAT table must contain

• Inside IP:port and outside IP:port mapping.
• Timeout behaviour (when entries expire).
• Direction rules (what is allowed inbound vs outbound).

TLS is the protocol most people mean when they say HTTPS. TLS provides confidentiality and integrity for application data.

OSI explanations often place TLS in the presentation layer because it is about encoding and protection of data. In TCP IP practice, TLS is usually treated as part of the application layer stack because it is above the transport layer.

This is the key point. Layer models describe responsibilities. They do not force a protocol to live in one place forever.

Verification. What TLS gives you (and what it does not)

• Confidentiality and integrity for application data in transit.
• Server identity verification via certificates (when correctly validated).
• It does not fix bad authentication, insecure endpoints, or poor authorisation logic.

My method is simple.

1. State the user visible symptom in one sentence.
2. State what success would look like.
3. Pick the smallest test that isolates one layer boundary.
4. Record the result and update your hypothesis.

When you do this, you stop jumping straight to rare causes.

Common mistakes (troubleshooting edition)

• Starting with rare causes because they are interesting.
• Changing three things at once, then not knowing what fixed it.
• Not writing down observations, then losing evidence under pressure.

Pick one real page you trust. Use a browser. Write down the DNS step, the TCP step, and the TLS step. For each step, write one observation you could use as evidence.

CPD evidence (keep it practical)

• What I studied: TCP reliability, DNS resolution, UDP trade-offs, routing vs switching, NAT behaviour, TLS placement.
• What I practised: one walkthrough using a tool and one written troubleshooting narrative for a real page.
• What I learned: one place I used to guess (for example DNS vs TCP) and the test I will now run first.
• Evidence artefact: a short step-by-step write-up with observations and assumptions.