The Layer Model — What Each Layer Decides
In a nutshell
Layering is a design that divides things so that each layer uses only the services of the layer below and exposes only an interface to the layer above, and when diagnosing an outage it becomes a tool for asking "up to which layer did it succeed".
Why this was needed
A network is not built by one person. The companies that lay fiber-optic cable, the companies that make routers, and the companies that make browsers are all different. For them to work together without knowing one another's implementations, boundaries and contracts are needed.
Layering is that contract. The lower layer provides a service to the upper layer, and the upper layer does not need to know how the lower layer implemented that service. TCP does not care whether its segments travel over fiber or Wi-Fi.
How it works
The textbook OSI seven layers and the TCP/IP model of the actual Internet correspond as follows.
| OSI | TCP/IP | What this layer decides | Data unit |
|---|---|---|---|
| Application, presentation, session | Application | What to exchange (HTTP, DNS) | Message |
| Transport | Transport | To which process, and reliably, to send | Segment / datagram |
| Network | Internet | To which host, and by what path, to send | Packet |
| Data link | Link | How to send to the next device within the same network | Frame |
| Physical | Link | What signal to turn bits into | Bit |
Encapsulation is the process of attaching the lower layer's header to the upper layer's data. A TCP header is attached to an HTTP request to make a segment, an IP header is attached to make a packet, and an Ethernet header is attached to make a frame. The receiving side strips them in reverse order.
Here we must point out a frequently misunderstood point. The OSI seven layers are an educational model, not the implementation of the Internet. There is no Internet protocol that corresponds exactly to the presentation and session layers. That is why there is no clear-cut answer to a question like "which layer is TLS". TLS runs on top of TCP and encrypts application data, so it is awkward wherever you place it. A model is a tool to aid understanding, not reality.
What it looks like in the field
The practical value of the layer model lies in the diagnostic order. When a connection fails, asking in the following order narrows the scope quickly.
- Does the name resolve —
getent hosts api.example.com(name resolution, beneath the application layer) - Does a TCP connection to that address succeed —
curl -v --connect-timeout 3 http://주소:포트/(address and port go where the Korean words are) - Does the connection succeed but no response come — the transport layer is passed and it is an application layer problem
If you keep this order, you can turn the report "the network doesn't work" into "it stops at step 3". For reference, even in places where you cannot use ping or tcpdump, such as the lab environment, all three steps above can be checked with ss, curl, dig, getent, and /proc/net/* alone.
A table for finding the layer from the symptom
The practical value of the layer model is deciding which layer to look at by looking at the symptom.
| Symptom | Layer to suspect | Command to check |
|---|---|---|
| The link does not come up | L1 physical | ip link, cable/SFP |
| Same subnet but no connectivity | L2 | ip neigh, ARP reply |
| A different range is unreachable | L3 | ip route get, traceroute |
| Only the port is not open | L4 | nc -zv, firewall |
| The name does not resolve | Application (DNS) | getent hosts, dig |
| TLS error | Presentation (TLS) | openssl s_client -connect |
| 404, 500 | Application | Application logs |
Going from the bottom up is the default, but in practice it is faster to start from the middle (L3/L4). Physical problems are rare, and application problems are told to you by the logs.
The overhead that encapsulation creates
Each layer attaches a header, so the actual data shrinks by that much.
이더넷 프레임 1518 바이트 (MTU 1500)
− IP 헤더 20
− TCP 헤더 20
= 1460 바이트가 실제 데이터 (MSS)
If you use a VPN or an overlay network, more headers are added on top of this. VXLAN adds 50 bytes, so the actual MSS becomes 1410. If you do not match the MTU, large packets are fragmented or dropped.
This is the cause of the symptom in Kubernetes that "small requests work but large responses stall". Path MTU discovery (PMTUD) uses ICMP, and if that ICMP is blocked by a firewall, the sender keeps sending large packets and never gets any response (a PMTU black hole).
# 조각내지 않고 보낼 수 있는 최대 크기 찾기
ping -M do -s 1472 <대상> # 1472 + 28(ICMP+IP) = 1500
Why split TCP and UDP
| TCP | UDP | |
|---|---|---|
| Connection | 3-way handshake | None |
| Order and retransmission | Guaranteed | None (the app does it) |
| Flow control | Yes | None |
| Until the first byte | At least 1 RTT extra | Immediate |
The reason DNS uses UDP is that three handshake messages per query is a waste. If the response exceeds 512 bytes, it asks again over TCP.
QUIC rebuilds reliability and encryption on top of UDP. It is a design that aims to get reliability while avoiding TCP's problems (head-of-line blocking, an implementation embedded in the kernel).
What to check in the quiz that follows
Check what each layer decides, what the encapsulation order is, and how far to trust the OSI model.