The OSI model

The OSI model describes how two computers talk as seven layers, from bits on a wire at layer 1, through frames, packets and segments, up to the application’s own messages at layer 7. Each layer does one job and wraps the data from the layer above in its own header. The internet actually runs the simpler four-layer TCP/IP stack, but the OSI numbers survive as shared vocabulary: “L4 load balancer”, “L7 DDoS”, “terminate TLS at the edge”.

Picture it first: a box of sweets from Jaipur to Kochi

You courier a box of Diwali sweets to your cousin in Kochi. Notice how many people handle it, and what each one reads.

• You write a card saying which sweet is which. That’s the application: the message you care about.
• You write it in Malayalam, which your cousin reads best, and seal the box with tamper tape. Agreeing on a language and protecting the contents is the presentation job.
• You phone ahead: “three boxes are coming; if the second goes missing, I’ll resend from there.” Managing the conversation is the session job.
• The courier counter gives each box a docket number, collects a signature at delivery and resends a lost box. The label names one person in the house, Anu. That’s transport, and Anu is the port.
• The address and PIN code are read at every sorting hub to pick the next hub, and never change between Jaipur and Kochi. That’s the network layer and its IP address.
• Each leg of the trip (your lane to the Jaipur hub, Jaipur to Nagpur, Nagpur to Kochi) has its own trip sheet naming only the next stop, rewritten at every hub. That’s the data link layer: frames and MAC addresses.
• Roads, rails and wheels are the physical layer.

Two lessons carry straight over. The hub clerk reads the PIN code and never opens the box, just as a router reads the IP header and never the HTTP request. And anyone who wants to inspect the sweets must break the seal, just as a WAF or L7 proxy must hold the TLS key to read a request.

The seven layers, bottom to top

ITU-T X.200, published with identical text as ISO/IEC 7498-1, defines the model. Each layer offers a service to the layer above, talks to the same layer on the other machine through a protocol, and needn’t know how the layers below do their jobs.

Layer 1, physical. Moves raw bits as light, voltage or radio between directly connected devices: connectors, signal levels, timing. No addresses. A cut fibre or weak Wi-Fi signal is a layer 1 problem.

Layer 2, data link. Delivers a frame to a neighbour on the same link, and a checksum in its trailer catches corrupted bits. Ethernet and Wi-Fi live here, addressed by 48-bit MAC addresses (RFC 894). A switch forwards frames by destination MAC. ARP finds the MAC for a next hop’s IP address (IPv6 uses Neighbor Discovery).

Layer 3, network. Delivers a packet from source host to destination host across many links, choosing the path hop by hop. This is IP, with 32-bit IPv4 or 128-bit IPv6 addresses (see IP addresses), and routers live here. IP is best effort: packets can be lost, duplicated or reordered. ICMP, which carries error reports and ping, rides inside IP packets but is formally part of IP.

Layer 4, transport. Delivers data to a process, named by a 16-bit port, with whatever guarantees the protocol offers. TCP’s unit is a segment of a reliable byte stream; UDP’s is a datagram with no promises (TCP vs UDP compares them). A connection is named by its 5-tuple: protocol, source IP and port, destination IP and port.

Layer 5, session. Opens, manages and closes a dialogue, with checkpoints to resume from after a failure. X.200 gives it tokens, synchronisation points and resynchronisation; on the internet those jobs live inside applications and libraries, such as TLS session resumption or a resumable upload.

Layer 6, presentation. Makes both sides interpret bytes the same way: encodings, formats, compression, encryption. Today that means JSON or Protobuf (serialization), gzip, and the encryption half of TLS.

Layer 7, application. The protocols applications speak: HTTP, gRPC, DNS, SMTP. Its addresses are names: hostnames, URLs, API paths. The browser isn’t layer 7; HTTP is.

A reference model, not the internet’s blueprint

X.200 says plainly that it is not meant as an implementation specification; it is a conceptual framework so committees could standardise each layer independently. OSI had its own protocols too, but the internet ran on TCP/IP, which RFC 1122 (1989) describes in four layers:

• Link: whatever the host uses on its directly attached network. OSI 1 and 2.
• Internet: IP, with ICMP and IGMP. OSI 3.
• Transport: TCP and UDP. OSI 4.
• Application: everything else. RFC 1122 says it “essentially combines” OSI’s presentation and application layers; session work lands there too.

So layers 5 and 6 are the honest gap. No internet protocol is “layer 5” the way TCP is layer 4, and a quiz answer that confidently files TLS into exactly one of them is guessing.

Where the lines blur

• TLS runs on TCP and carries HTTP. It encrypts (layer 6’s job) and manages resumable sessions (layer 5’s); the TCP/IP model just calls it application.
• QUIC goes further: reliability, congestion control, streams and TLS 1.3 in one protocol, carried in UDP datagrams. A transport living above another transport.
• DNS is an application protocol (RFC 1122 lists it as a “support protocol”), even though its answer, an IP address, is consumed by layer 3.
• ARP fills in layer 2 headers from layer 3 addresses, so it sits on the 2/3 boundary.

RFC 3439 has a section titled “Layering Considered Harmful”. Its point: strict layering hides information that other layers need, such as the lower layer’s packet size. You’ll meet exactly that problem with MTUs below. Treat the layers as a map, not a law.

Encapsulation: one request, wrapped four times

Follow a UPI-style app on a phone asking GET /v1/payments/8841/status over HTTPS, and say the HTTP request is 200 bytes. Going down the stack, each layer adds its header without reading what’s inside:

1. TLS 1.3 record. The request plus a 1-byte inner content type is encrypted; AES-128-GCM appends a 16-byte tag (RFC 5116) and a 5-byte record header goes in front (RFC 8446). 200 + 1 + 16 + 5 = 222 bytes.
2. TCP segment. A header of at least 20 bytes with ports, sequence and acknowledgment numbers: 222 + 20 = 242 bytes.
3. IPv4 packet. At least 20 bytes more (RFC 791 counts the header in 32-bit words, minimum 5): 242 + 20 = 262 bytes.
4. Ethernet frame. A 14-byte header (destination MAC, source MAC, 2-byte EtherType) and a 4-byte frame check sequence, as drawn in RFC 7348: 262 + 18 = 280 bytes.

On the phone’s first hop the frame is actually a Wi-Fi frame with a longer link header; the access point swaps it for an Ethernet header on the wired side. That swap is the point of layer 2: link headers are local and replaced at every hop.

The receiver unwraps in reverse. The network card checks the FCS and strips the Ethernet header; IP checks the destination address and uses its protocol field to hand the payload to TCP; TCP finds the socket by destination port; TLS decrypts and verifies the tag; the server finally sees 200 bytes of HTTP.

The arithmetic interviewers like

Ethernet carries at most 1,500 bytes of IP packet per frame (RFC 894). That is the MTU, a layer 3 size. Subtract the minimum IP and TCP headers to get the most TCP payload per packet, the MSS: 1,500 − 20 − 20 = 1,460 bytes over IPv4. IPv6’s fixed header is 40 bytes, so its MSS is 1,500 − 40 − 20 = 1,440 (RFC 8200, section 8.3). If the peer sends no MSS option, TCP must assume 536 (576 − 40) for IPv4 or 1,220 (1,280 − 60) for IPv6 (RFC 9293).

Headers are a fixed cost per packet, so they hurt small messages and fade on bulk transfers. Take a 1,000,000-byte product image during a Flipkart-style sale. TLS splits it into 62 records of at most 16,384 bytes, adding 62 × 22 = 1,364 bytes. The 1,001,364-byte stream needs ⌈1,001,364 ÷ 1,460⌉ = 686 segments, each paying 20 + 20 + 18 = 58 bytes: 39,788 more.

The ACK row: a 40-byte packet is padded because Ethernet’s data field has a 46-byte minimum. Jumbo frames matter less for 3 points of efficiency than for sending 6.1× fewer packets (686 ÷ 112), because NICs, kernels and routers pay per packet. (The physical layer’s preamble and inter-frame gap add a little more that software never sees.)

Hop by hop: who reads which header

Every box on the path unwraps only as far as its job needs, decides, and wraps the packet up again. The highest layer it reads is the most useful fact about it.

• Switch (L2). Looks up the destination MAC in a table learned from source MACs and forwards the frame. Never touches IP.
• Router (L3). Reads the destination IP, picks the next hop, decrements TTL (Hop Limit in IPv6), recomputes the IPv4 header checksum because TTL changed, and builds a new frame: its own MAC as source, the next hop’s as destination. When TTL reaches zero, the packet is dropped and the sender gets ICMP Time Exceeded. That kills routing loops and powers traceroute.
• NAT (L3 and L4). Your home router rewrites the private source IP and source port, and keeps a table to reverse it for replies: a “layer 3 box” editing layer 4 fields.
• Stateful firewall or security group (L3 and L4). Matches IPs, protocol and ports, and remembers connections so replies get back in.
• L4 load balancer. Picks a backend per connection from the 5-tuple; never decrypts. See load balancing L4 vs L7.
• L7 load balancer, reverse proxy, API gateway, CDN edge. Terminate TCP and TLS, parse HTTP, and route, cache, authenticate or rate-limit by host, path, headers and cookies (proxy vs reverse proxy, API gateway, CDN).
• Service-mesh sidecar (L7). A local proxy beside each service doing mTLS, retries and per-request balancing (sidecar and service mesh).

The rule to remember: MAC addresses change at every router; IP addresses survive end to end unless NAT rewrites them; TLS survives only to the first box that holds the key. Anything that reads above layer 4 must decrypt, which makes it a security boundary. HTTP and HTTPS covers where to terminate TLS.

Why interviewers say “L4” and “L7”

A layer number is shorthand for one question: how much of the request must this component understand? The more it reads, the smarter its decisions and the more each request costs.

Load balancing

An L4 balancer forwards connections by address and port: microseconds per packet, any protocol, no keys, but no idea which request is which. An L7 balancer reads every request, so it can route /api/search and /api/orders to different pools and spread one gRPC connection’s calls, paying for TLS, parsing and a new security boundary. Big systems put L4 in front of L7; load balancing L4 vs L7 has the details.

DDoS: volumetric floods versus application floods

Layer 3/4 attacks try to fill your pipes or connection tables: UDP reflection, SYN floods, junk to random ports. They are huge but dumb, so you drop them on packet properties alone, ideally at an anycast edge with more capacity than the attack (anycast is covered in DNS). As Cloudflare notes, that only works if the network can absorb the volume.

Layer 7 attacks send valid HTTPS requests, say a botnet hammering search and login during an IRCTC tatkal rush. Each request completes TCP and TLS from a real address and looks like a user, yet costs the server database work. Packet filters can’t tell them apart, so you need L7 tools: WAF rules, per-client rate limiting, bot challenges and caching. You gain precision; you pay for terminating TLS and inspecting every request at the edge.

Firewalls, security groups and WAFs

The state and rule columns follow AWS’s own comparison. Stack them: ACLs and security groups shrink what can reach a host, and the WAF judges what a request means. Neither replaces the other.

Going deeper: MTU, fragmentation and black holes

Fragmentation and Path MTU Discovery

When an IPv4 router must forward a packet bigger than the next link’s MTU, it can split it into fragments for the destination to reassemble. Fragments are fragile: losing one loses the packet, and only the first carries the TCP or UDP ports that firewalls and balancers look for. So TCP sets the Don’t Fragment (DF) bit and runs Path MTU Discovery (RFC 1191): a router that can’t forward a DF packet drops it and returns ICMP “fragmentation needed” (type 3, code 4) with the next hop’s MTU, and the sender shrinks its packets. IPv6 routers never fragment; they send ICMPv6 Packet Too Big, and every IPv6 link must carry at least 1,280 bytes.

Tunnels shrink the MTU

A tunnel puts your packet inside another, leaving less room inside:

• VXLAN, used by many Kubernetes and cloud overlay networks, wraps the whole inner Ethernet frame in UDP. On a 1,500-byte underlay the inner MTU is 1,500 − 20 (outer IP) − 8 (UDP) − 8 (VXLAN) − 14 (inner Ethernet) = 1,450 bytes. RFC 7348 recommends raising the underlay MTU instead.
• An IPsec VPN adds an outer IP header, ESP framing, padding and an integrity tag. AWS Site-to-Site VPN supports an MTU of 1,446 and an MSS of 1,406, 54 bytes below plain Ethernet, and does not support Path MTU Discovery (AWS VPN quotas).

The black hole

PMTUD only works if the ICMP gets back to the sender. Block all ICMP “for security” and large packets vanish silently. RFC 2923 describes the symptom exactly: pings and small interactive exchanges work, while bulk transfers stall on the first full-size packet and eventually time out. In practice, the office VPN is up, ssh works, the login API works, but a file upload or a download hangs.

Fixes, best first:

• Let “fragmentation needed” and ICMPv6 “Packet Too Big” through. AWS warns that a network ACL can block ICMP even when the security group allows it.
• Clamp the TCP MSS at the tunnel. The gateway rewrites the MSS option in passing SYNs to 1,406, so TCP never builds packets that won’t fit. Essential when, as on AWS VPN, PMTUD isn’t supported at all.
• Set the interface MTU to the tunnel’s inner MTU.
• Probe instead of trusting ICMP. Packetization-layer PMTUD (RFC 4821, and RFC 8899 for datagrams) has the transport try bigger sizes and back off on loss.

Jumbo frames

Inside an AWS VPC, current-generation instances support 9,001-byte jumbo frames, and AWS recommends them within cluster placement groups. But traffic through an internet gateway, over a VPN, or between Regions (unless through a transit gateway) is capped at 1,500, and inter-Region VPC peering at 8,500. You gain up to 6× fewer packets for bulk data; you pay with one more way to meet a smaller hop with blocked ICMP. Set the MTU per route or per interface.

Boxes that peek above their layer

• ECMP routers and L4 balancers hash ports, layer 4 fields, to keep each flow on one path.
• SNI routing: some L4 proxies read the hostname from the unencrypted TLS ClientHello and route on it without decrypting.
• NAT edits ports, which breaks protocols that write addresses into their payload.
• QUIC encrypts most of its transport header precisely so middleboxes can’t peek, and so can’t freeze the protocol’s design.

Each shortcut buys speed or simplicity, and each makes the layers less independent than the diagram suggests.

Troubleshooting layer by layer

When “the API is down”, walk up the stack from the bottom, or down from the top if you already have an HTTP status. Each layer has a tool that answers one yes-or-no question (Linux syntax; macOS differs slightly):

# L1–L2: is the link up, and do we know the gateway's MAC?
ip link show eth0                  # state UP? error and drop counters?
ip neigh show                      # gateway REACHABLE, not FAILED?

# L3: can packets get there, and by which path?
ping -c 4 203.0.113.10
traceroute 203.0.113.10            # or mtr for a live view

# L3 + MTU: does a full-size packet with DF set get through?
ping -M do -s 1472 203.0.113.10    # 1472 + 8 (ICMP) + 20 (IP) = 1500

# DNS: an application protocol everything else depends on
dig +short api.example.com

# L4: is anything listening on the port?
nc -vz api.example.com 443

# TLS: does the handshake finish, with the right certificate?
openssl s_client -connect api.example.com:443 -servername api.example.com </dev/null

# L7: what does the server actually say?
curl -v https://api.example.com/health

Read the failures by layer. ping works but nc times out: a firewall or security group is dropping the port. nc gets “connection refused” instantly: something answered with a reset, usually because nothing listens on that port. nc connects but openssl fails: wrong or expired certificate, or a TLS version mismatch. curl gets 502 or 504: a proxy is up but can’t reach its backend. Many hosts drop ICMP echo, so a failed ping alone proves little; prefer a TCP check.

traceroute is the TTL rule turned into a tool: it sends probes with TTL 1, 2, 3 and so on, and each router where a probe dies reports itself with Time Exceeded.

Cheat sheet

Mnemonic, bottom up: “Pune–Delhi–Nagpur Trains Serve Piping-hot Adrak chai” = Physical, Data link, Network, Transport, Session, Presentation, Application.

How to say it in the interview

“The OSI model is a seven-layer vocabulary: physical, data link with MAC addresses, network with IP, transport with ports, then session, presentation and application. The internet really runs TCP/IP’s four layers, and TLS straddles the top. Each component works up to some layer: a router reads IPs, an L4 balancer the 5-tuple, an L7 proxy or WAF the decrypted request. So here I’d put DDoS protection and an L4 tier at the edge, terminate TLS at the L7 gateway where the WAF and rate limits run, and watch the MTU on the VPN to the bank’s network.”

At which layer does TLS sit? Between transport and application. It runs on TCP and carries HTTP, doing layer 6’s encryption and some of layer 5’s session work; the TCP/IP model counts it as application. In practice, the box that terminates TLS is the first one that can act at L7.

What does an L4 load balancer see that an L7 one doesn’t, and vice versa? L7 sees a superset: the client connection’s addresses and ports plus the decrypted method, host, path, headers and cookies. L4’s advantages are reach and cost: any TCP or UDP protocol, no keys, and packets forwarded untouched, so the backend can see the client’s real IP. Behind L7, the backend sees the balancer’s address and needs X-Forwarded-For.

Why do packets get dropped after you add a VPN or tunnel? Encapsulation eats MTU: 1,446 on an AWS VPN, 1,450 inside VXLAN. Full-size DF packets no longer fit, and if ICMP “packet too big” is filtered, the sender never learns: small requests work, big ones hang. Clamp the MSS, lower the MTU, or let the ICMP through.

Is DNS layer 3 or layer 7? Layer 7. It’s an application protocol over UDP or TCP port 53, and RFC 1122 lists it as an application support protocol. Its output is an IP address for layer 3 to use, which is where the confusion comes from.

Where would you put a WAF? At the first place TLS is terminated and HTTP is readable: the CDN edge, or the L7 load balancer or API gateway, before requests reach services. Not at an L4 pass-through balancer, which sees only ciphertext. Keep L3/4 controls (DDoS edge, security groups) underneath it.

Where to go next

• TCP vs UDP: the transport layer in depth, including QUIC.
• IP addresses: layer 3 addressing, subnets and NAT.
• HTTP and HTTPS: layer 7, TLS and where to terminate it.
• Load balancing L4 vs L7: where layer numbers show up most.
• Proxy vs reverse proxy: the L7 boxes in front of and behind you.
• Domain Name System: the application protocol every request depends on.
• Checksums: the error detection in Ethernet, IP, TCP and UDP.
• Content delivery network: the L7 edge that ends TLS near users and absorbs floods.

References and further reading

1. ITU-T Recommendation X.200 (07/94): OSI Basic Reference Model, identical to ISO/IEC 7498-1itu.intThe seven layers and the purpose of each, the principles used to choose them, and the statement that the model is a framework, not an implementation specification.
2. RFC 1122 — Requirements for Internet Hosts: Communication Layersrfc-editor.orgThe internet’s four layers (link, internet, transport, application), with the application layer absorbing OSI’s presentation layer, DNS as a support protocol and ICMP as part of IP.
3. RFC 3439 — Some Internet Architectural Guidelines and Philosophyrfc-editor.orgSection 3, “Layering Considered Harmful”: strict layering hides information, such as lower-layer packet sizes, that other layers need.
4. RFC 791 — Internet Protocolrfc-editor.orgThe IPv4 header (20 bytes minimum, 60 maximum), TTL decremented at every hop, the per-hop header checksum and the Don’t Fragment bit.
5. RFC 8200 — Internet Protocol, Version 6 (IPv6) Specificationrfc-editor.orgThe fixed 40-byte header, Hop Limit, fragmentation only at the source, the 1,280-byte minimum link MTU, and MSS = MTU − 40 for IPv4 or − 60 for IPv6.
6. RFC 7348 — Virtual eXtensible Local Area Network (VXLAN)rfc-editor.orgFrame diagrams showing the Ethernet header (two 48-bit MACs and an EtherType) and FCS, the outer IP, UDP and VXLAN headers, and the advice to raise underlay MTUs.
7. RFC 2923 — TCP Problems with Path MTU Discoveryrfc-editor.orgThe PMTUD black hole: with ICMP suppressed, large packets vanish while pings and small exchanges still work.
8. Network maximum transmission unit (MTU) for your EC2 instance (AWS)docs.aws.amazon.com1,500-byte versus 9,001-byte jumbo frames, the 1,500 limit over internet gateways, VPNs and between Regions, 8,500 over inter-Region peering, and why PMTUD needs ICMP.
9. AWS Site-to-Site VPN quotasdocs.aws.amazon.comWhat a tunnel costs in bytes: an MTU of 1,446 and an MSS of 1,406, no jumbo frames, and no Path MTU Discovery.
10. What is an application layer DDoS attack? (Cloudflare Learning Center)cloudflare.comWhy layer 7 floods cost the server more than the attacker and look like real users, while layer 3/4 floods can be dropped if the network can absorb them.