Module 1 · Layers, Addresses and DNS · Lesson 1 of 28
Why layers exist
1.1 Why layers exist
Networking is organised as a stack of layers, each solving one problem and trusting the layer below. As an application developer you live at the top, but every performance mystery you'll ever debug — timeouts, socket exhaustion, stale DNS, slow first requests — is caused by behaviour two or three layers down. The practical model (a simplified TCP/IP stack):
| Layer | Examples | Purpose | Notes |
|---|---|---|---|
| APPLICATION | HTTP, gRPC, DNS protocol | “what to say” | ← HttpClient lives here |
| SECURITY | TLS | “say it secretly” | ← certificates live here |
| TRANSPORT | TCP, UDP | “say it reliably” | ← sockets live here |
| NETWORK | IP | “find the house” | ← addresses, routing |
| LINK | Ethernet, Wi‑Fi | “physical hop” |
Each layer wraps the one above like envelopes inside envelopes: your JSON body goes inside an HTTP message, which is encrypted by TLS, chopped into TCP segments, which ride inside IP packets, which ride inside Ethernet frames. The receiving machine unwraps in reverse order.
KEY POINT
IP is unreliable by design — packets can be lost, duplicated, or arrive out of order. Everything you rely on (ordering, delivery guarantees, “streams” of data) is manufactured by TCP on top of an unreliable postal system. Understanding that TCP is doing constant, invisible work is the root of most performance intuition.
1.2 IP addresses and ports
An IP address identifies a machine (or more precisely, a network interface) — 20.51.88.12. But one machine runs many programs that all want to use the network. A port is a 16-bit number (0–65535) that identifies which program on that machine a message is for. The OS keeps a table: “port 443 → the Kestrel process”, “port 1433 → SQL Server”.
- Well-known ports (0–1023): 80 = HTTP, 443 = HTTPS, 53 = DNS. Servers listen on these.
- Ephemeral ports (
~32768–65535on Linux,~49152–65535on Windows): when your Core API makes an outgoing call, the OS picks a random free port from this range as the source. This is the finite resource behind socket exhaustion — roughly 16k–28k usable outgoing ports per destination.
A connection is uniquely identified by the 4-tuple: (source IP, source port, dest IP, dest port).
Two connections from Core API to Media API differ only by source port — which is exactly why running out of source ports means no new connections.