Run a mock round

The OSI model is a seven-layer reference model: Physical, Data Link, Network, Transport, Session, Presentation and Application. The TCP/IP model as taught is four layers: Link, Internet, Transport and Application.

OSI                     TCP/IP
7 Application  }        Application (HTTP, DNS, TLS)
6 Presentation }   ->
5 Session      }        Transport (TCP, UDP)
4 Transport             Internet (IP, ICMP)
3 Network               Link (Ethernet, Wi-Fi, ARP)
2 Data Link
1 Physical

OSI is a conceptual framework that names what each layer should do and helps when reasoning about problems and protocols. TCP/IP is the model actually implemented by the Internet, and it merges the upper layers and leaves some OSI concerns, such as encryption, to the application or to TLS. In troubleshooting people still speak in OSI layers: a layer 2 problem means a switching or MAC issue, while layer 7 means the application payload.

An IP address is split into a network part and a host part by the subnet mask, which can be written as a CIDR prefix. /24 means the first 24 bits are the network, leaving 8 host bits.

192.168.1.0/24
mask  255.255.255.0
network 192.168.1.0   broadcast 192.168.1.255
usable hosts 192.168.1.1 - 192.168.1.254  (254 hosts)

The number of addresses is 2^(32-prefix), and usable hosts are that minus the network and broadcast addresses for IPv4. Borrowing bits creates subnets; splitting a /24 into four /26 gives 62 usable hosts each.

Longest-prefix match means a router forwarding a packet picks the most specific route. CIDR replaced classful addressing and allows route aggregation, so many contiguous networks are advertised as a single summary route. Private ranges such as 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 are not routed on the public Internet.

TCP and UDP are transport-layer protocols with opposite trade-offs.

TCP is connection-oriented. It sets up a connection with a three-way handshake, numbers every segment, acknowledges delivery, retransmits lost data, orders bytes and applies flow and congestion control. It is used when correctness matters: HTTP, SMTP, SSH and database connections.

UDP is connectionless. It sends independent datagrams with no handshake, acknowledgements or ordering, so delivery is best-effort. It is used when low latency matters more than reliability: DNS, DHCP, VoIP, video streaming and online games. QUIC adds reliability and encryption on top of UDP in user space.

TCP: SYN, SYN-ACK, ACK -> ordered, reliable byte stream
UDP: datagram -> fire and forget

TCP's guarantees cost latency and header overhead; UDP is cheaper but application code must handle loss, duplication and reordering when required.

The browser parses the URL, then finds the server's IP: it checks its cache, the OS cache, /etc/hosts, then asks a resolver, which recurses from the root servers through the top-level domain to the authoritative name server. Meanwhile a TCP connection is opened to port 443 with the three-way handshake.

For HTTPS, a TLS handshake follows: the client sends supported ciphers and a random value, the server returns its certificate, they verify it against trusted CAs, agree on keys via ECDHE and switch to encrypted records. Modern TLS 1.3 does this in one round trip.

The browser then sends an HTTP request with method, path, headers and cookies. The server may hit a load balancer, a cache and application code, and returns a status and body. The browser parses HTML, builds the DOM, fetches subresources, builds the CSSOM, runs layout and paint, and executes JavaScript. All of these stages are visible in browser developer tools.

A content delivery network caches content on edge servers close to users, reducing latency and offloading the origin.

How it works: DNS or anycast routes the user to a nearby edge. On a cache miss the edge fetches from the origin or from a parent tier, stores the object according to its cache headers, and serves subsequent requests locally. TTLs, Cache-Control, ETag revalidation and surrogate keys control freshness and purging.

user -> nearest edge -> (miss) -> parent/origin

Benefits are lower round-trip time, less origin bandwidth, resilience to spikes, and absorption of some DDoS traffic. Design considerations include choosing cacheable content, correct cache keys that account for query strings and cookies, an invalidation strategy, and consistency trade-offs. Static assets are easy; dynamic content needs careful rules, edge compute or short TTLs. Always measure cache hit ratio, origin offload and time to first byte.

TCP congestion control keeps the sender from overwhelming the network. The sender maintains a congestion window, cwnd, and sends at most the minimum of cwnd and the receiver's advertised window.

Classic four phases:

• Slow start: cwnd starts small and doubles each round trip until the slow-start threshold.
• Congestion avoidance: cwnd grows by roughly one segment per round trip, additive increase.
• Fast retransmit: three duplicate ACKs imply one lost segment, so resend it without waiting for a timeout.
• Fast recovery: halve cwnd and continue.

cwnd ^        /|  AIMD sawtooth
     |      /  |
     |   /     |\__
     +-----------------> time

On timeout cwnd drops to one and slow start restarts. This additive-increase, multiplicative-decrease behaviour is why TCP is fair and stable. Modern algorithms differ: CUBIC uses a cubic growth function, and BBR models bandwidth and round-trip time instead of treating loss as the only signal.

TCP opens a connection with a three-way handshake so both sides agree on initial sequence numbers and confirm they can send and receive.

1. Client sends SYN with its initial sequence number and options such as MSS and window scaling.
2. Server replies SYN-ACK: it acknowledges the client's sequence number and sends its own SYN.
3. Client sends ACK acknowledging the server's sequence number; the connection is established.

Client          Server
  SYN seq=x  ->
             <- SYN-ACK seq=y ack=x+1
  ACK ack=y+1 ->

Two steps would not be enough: each side needs to know the other received its SYN, and the exchange prevents stale duplicates from an old connection being mistaken for a new one. Sequence numbers are randomised to make blind spoofing hard.

Teardown takes four steps, FIN, ACK, FIN, ACK, because each direction closes independently, and the side that closes last waits in TIME_WAIT to absorb delayed segments.

DNS maps names to records, most importantly A and AAAA addresses, plus CNAME, MX, TXT and NS. A lookup can walk several servers, but caching means most lookups stop early.

Resolution steps:

1. Check the local hosts file and OS resolver cache.
2. Query the configured recursive resolver, often via the ISP or a public service.
3. If not cached, the resolver asks a root server, which points to the top-level domain servers.
4. The TLD server points to the domain's authoritative name servers.
5. The authoritative server returns the record; the resolver caches it for its TTL and answers the client.

Queries use UDP port 53, falling back to TCP for large responses, and DoT or DoH when encryption is wanted.

client -> recursive resolver -> root -> .com -> ns.example.com

Caching and TTLs reduce load and latency. Debug with dig +trace or nslookup, and remember that propagation delays are really cache expiry.

Network troubleshooting is easier when you reason up the layers and use the right tool at each step.

• ping checks reachability and round-trip time using ICMP and reveals packet loss.
• traceroute shows the path and where latency or loss begins.
• dig or nslookup verifies DNS records and which server answered.
• ss or netstat lists listening sockets and established connections.
• curl -v inspects HTTP status, headers and TLS negotiation.
• tcpdump or Wireshark captures packets to confirm what is on the wire.
• ip addr and ip route verify local addressing and routing.

dig example.com +short
curl -v https://example.com
ss -tulpn

A sensible order is name resolution, then local interface and route, then reachability, then port and application. Check firewalls and security groups early too, since a silent timeout often means a dropped packet rather than a dead host.