Skip to main content

Documentation Index

Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Module 2: Network Models

To understand how networks function, we use reference models that break down communication into layers. The two most important models are OSI and TCP/IP. Why layers? Consider the postal system analogy. When you mail a letter, you do not think about how the mail truck’s engine works. You write your message (application layer), put it in an envelope with an address (network layer), and hand it to the post office (physical layer). Each layer handles its own job without worrying about the others. Networking layers work the same way — a web developer writing an HTTP request does not need to understand voltage levels on copper wire.
OSI Model vs TCP/IP Model

​
2.1 The OSI Model

The Open Systems Interconnection (OSI) model has 7 layers. Think of it as a factory assembly line where each station adds something specific before passing the product to the next station.
  1. Physical Layer (Layer 1): Bits, cables, signals. This is the actual wire, fiber, or radio wave. It only understands 0s and 1s — raw electrical or optical pulses. Analogy: the road itself.
  2. Data Link Layer (Layer 2): Frames, MAC addresses, switching. Responsible for getting data to the next directly-connected device. MAC addresses are used here — they are like apartment numbers within a building. Analogy: the local mail carrier who delivers within your neighborhood.
  3. Network Layer (Layer 3): Packets, IP addresses, routing. Handles end-to-end delivery across multiple networks. IP addresses live here. Analogy: the ZIP code that tells the postal system which city to route your letter to.
  4. Transport Layer (Layer 4): Segments, TCP/UDP, reliability. Ensures data arrives completely and in order (TCP) or fires it quickly without guarantees (UDP). Analogy: TCP is certified mail with tracking; UDP is dropping a postcard in the mailbox and hoping for the best.
  5. Session Layer (Layer 5): Session management. Establishes, maintains, and terminates connections between applications. In practice, this layer is mostly absorbed into Layer 4 and Layer 7.
  6. Presentation Layer (Layer 6): Data formatting, encryption, compression. Ensures the data is in a format the application can understand (e.g., SSL/TLS encryption, character encoding). Think of it as translating between languages before the message reaches the recipient.
  7. Application Layer (Layer 7): User applications (HTTP, SMTP, DNS). This is the layer you interact with directly. When your browser makes a request, it speaks HTTP at this layer.
Memory trick: “Please Do Not Throw Sausage Pizza Away” (Physical, Data Link, Network, Transport, Session, Presentation, Application). Or from top to bottom: “All People Seem To Need Data Processing.”
Practical reality: Layers 5 and 6 are mostly theoretical in modern networking. The TCP/IP model (below) merges them into the Application layer. When someone says “Layer 7 load balancer,” they mean it inspects HTTP content. When they say “Layer 4 load balancer,” it only looks at TCP/UDP ports and IP addresses. You will hear “Layer 3” and “Layer 7” constantly in real-world discussions — Layers 5 and 6 almost never come up.

​
2.2 The TCP/IP Model

The TCP/IP model is the practical implementation used in the Internet today. While OSI is the “textbook” model, TCP/IP is what actually runs the internet. It condenses the OSI layers into 4 (or 5) layers.
  1. Network Interface (Physical + Data Link) — handles the physical transmission and local delivery
  2. Internet (Network) — IP addressing and routing across networks
  3. Transport (Transport) — end-to-end reliability (TCP) or speed (UDP)
  4. Application (Session + Presentation + Application) — everything the user-facing software does, including HTTP, DNS, SMTP, and TLS encryption

​
Why two models?

The OSI model was designed by committee (ISO) as an ideal reference before the internet took off. The TCP/IP model was designed by engineers who were actually building the internet. OSI is great for learning and discussing networking concepts. TCP/IP is what you will see in actual protocol headers, packet captures, and documentation. In interviews and real-world discussions, people freely mix terminology from both models — “Layer 7” is OSI terminology, but everyone uses it when talking about TCP/IP networks.

​
2.3 Encapsulation

Data is wrapped with headers (and trailers) as it moves down the layers. Think of it like putting a letter in an envelope, then putting that envelope in a shipping box, then putting that box on a delivery truck. Each layer adds its own “wrapping” with the information it needs.
  • Application: Data — the raw message, like the text of your letter.
  • Transport: Segment (Data + TCP Header) — adds port numbers and sequence numbers, like writing “page 3 of 10” on the letter.
  • Internet: Packet (Segment + IP Header) — adds source and destination IP addresses, like writing the sender and recipient addresses on the envelope.
  • Link: Frame (Packet + Frame Header + Trailer) — adds MAC addresses and error-checking, like the shipping label and “fragile” sticker on the box.
When data arrives at the destination, the process reverses — each layer strips its header (de-encapsulation), passing the inner content up to the next layer. The receiving application only ever sees the original data. 
Sending:                          Receiving:
App Data                          App Data  (headers stripped)
  ↓ add TCP header                  ↑ remove TCP header
[TCP][App Data]                   [TCP][App Data]
  ↓ add IP header                   ↑ remove IP header
[IP][TCP][App Data]               [IP][TCP][App Data]
  ↓ add Frame header + trailer      ↑ remove Frame header + trailer
[Frame][IP][TCP][App Data][FCS]   [Frame][IP][TCP][App Data][FCS]
  ↓ transmit as bits                ↑ receive bits
0110100101...                     0110100101...
Each layer only looks at its own header. A router (Layer 3) examines the IP header to make routing decisions but does not inspect the TCP header or the application data. This is why a Layer 4 load balancer is faster than a Layer 7 one — it reads less of the packet.
Packet Encapsulation

​
Next Module

Module 3: Physical & Data Link

Explore the bottom layers of the stack.

​
Interview Deep-Dive

Strong Answer:
  • The OSI model was designed by the ISO committee as a theoretical reference framework before the internet took off. It has 7 layers and provides a clean separation of concerns for teaching and discussing networking concepts. The TCP/IP model was built by the engineers actually constructing the internet — it is pragmatic, has 4 layers, and maps directly to real protocol implementations.
  • In production, the TCP/IP model is what matters. Protocol headers, packet captures in Wireshark, and documentation all reference TCP/IP. However, OSI terminology dominates real-world conversations — everyone says “Layer 7 load balancer” or “Layer 4 firewall,” and those are OSI layer numbers. Nobody says “Application layer load balancer in the TCP/IP model.”
  • Layers 5 (Session) and 6 (Presentation) from the OSI model are almost never discussed in practice. They have been absorbed into the Application layer in TCP/IP. When I hear someone reference Layer 5 or 6 in an interview, it often signals textbook knowledge without operational experience.
  • The practical value of the layered model is troubleshooting. When something breaks, you work bottom-up: is the cable connected (Layer 1)? Can I ping the gateway (Layer 3)? Is the port open (Layer 4)? Is the application responding (Layer 7)? This systematic approach is the real gift of the model, regardless of which model you reference.
Follow-up: When someone says ‘Layer 4 load balancer versus Layer 7 load balancer,’ what is the concrete difference in how they handle traffic?A Layer 4 load balancer looks at the TCP/UDP header — specifically the source and destination IP addresses and port numbers — and makes a routing decision based on that alone. It does not terminate the TCP connection or inspect the payload. It is fast because it reads very little of the packet. A Layer 7 load balancer terminates the client’s TCP connection, reads the full HTTP request (URL path, headers, cookies, body), makes a routing decision based on that content, and then opens a new connection to the backend server. This means L7 can route /api/* to one backend pool and /static/* to another, perform SSL termination, inject headers like X-Forwarded-For, and do A/B testing. The trade-off is higher latency and more CPU usage because it parses the entire HTTP request. In practice, you default to L7 for web applications and use L4 for non-HTTP protocols like database connections or game servers.
Strong Answer:
  • Encapsulation is the process where each layer of the networking stack wraps the data from the layer above with its own header (and sometimes a trailer). It is like putting a letter in an envelope, then putting that envelope in a shipping box, then loading the box onto a truck.
  • In a Wireshark capture of an HTTPS response leaving a web server, I would see from outside to inside: the Ethernet frame header (source and destination MAC addresses, EtherType 0x0800 for IPv4), the IP header (source and destination IP addresses, TTL, protocol field set to 6 for TCP), the TCP header (source port 443, destination port matching the client’s ephemeral port, sequence and acknowledgment numbers, flags), and then the TLS record containing the encrypted application data. Wireshark cannot decrypt the TLS payload unless you provide the session keys.
  • At the end of the frame, there is an FCS (Frame Check Sequence) trailer — a CRC checksum for detecting corruption during transmission. If the FCS does not match, the frame is silently dropped at Layer 2 without any notification to the sender. Retransmission, if any, happens at Layer 4 (TCP).
  • The critical insight is that each layer only reads its own header. A router examines the IP header for routing decisions but ignores TCP and application data. This is why Layer 4 load balancers are faster than Layer 7 ones — they stop reading earlier.
Follow-up: You said the frame is ‘silently dropped’ if the FCS fails. How does the sender eventually find out the data was lost?The sender finds out through TCP’s reliability mechanisms at Layer 4. When the sender transmits data, it starts a retransmission timer. The receiver is expected to send an ACK acknowledging receipt. If the frame was dropped at Layer 2 due to FCS failure, the data never reaches Layer 4 on the receiver, so no ACK is sent. The sender’s timer expires, and TCP retransmits the segment. If multiple consecutive ACKs are missing, TCP also uses fast retransmit: if the sender receives three duplicate ACKs for the same sequence number (meaning the receiver got subsequent segments but is missing one), it retransmits the missing segment immediately without waiting for the timeout. This is a clean separation of responsibilities — Layer 2 handles error detection, Layer 4 handles error recovery.
Strong Answer:
  • Layered architecture exists for the same reason we have separation of concerns in software engineering: it allows each layer to evolve independently without breaking the others. HTTP does not care whether the underlying transport is TCP, QUIC, or something invented next year. Ethernet does not care whether the packets it carries contain IP, ARP, or IPv6. This independence is what allowed the internet to grow from a research project to a global infrastructure without requiring coordinated rewrites at every level.
  • In practice, this means I can switch my application from HTTP/1.1 to HTTP/2 without changing anything about my network infrastructure. I can upgrade from copper to fiber without touching a single application configuration. I can deploy a VPN (which adds an encapsulation layer) without modifying the applications running through it.
  • Layering also makes troubleshooting tractable. If I had one monolithic protocol, a failure could be anywhere. With layers, I can systematically isolate: “Layer 1 is fine (link light is on), Layer 3 is fine (I can ping the gateway), Layer 4 is fine (port is open), so the problem must be at Layer 7 (application misconfiguration).” That process saves hours compared to blind guessing.
  • The trade-off is overhead. Each layer adds its own headers, which means a 1-byte application message might become a 66-byte frame by the time all headers are added. And sometimes the layer boundaries create artificial constraints — for example, TCP’s head-of-line blocking problem, which HTTP/3 solves by moving to UDP (QUIC) and reimplementing reliability at the application layer.
Follow-up: You mentioned HTTP/3 uses QUIC over UDP instead of TCP. Does that break the layered model, since the application is now doing what the transport layer used to do?It does bend the model, and this is a great example of where theory meets pragmatism. QUIC essentially reimplements TCP’s reliability, flow control, and congestion control at the application layer, running on top of UDP. This lets it solve TCP’s head-of-line blocking problem (where one lost packet stalls all streams on the connection) by handling multiple independent streams. It also integrates TLS 1.3 directly, reducing handshake round trips. Purists might say this violates layer separation, but the engineering reality is that the layer model is a guide, not a law. When a lower layer’s design constraints become a bottleneck — as TCP’s head-of-line blocking did for HTTP/2 — practical engineers move functionality to a layer where they have more control. The layer model is still useful for reasoning about networks, even if real implementations do not always respect the boundaries perfectly.