Networking, Illustrated
Follow one HTTPS request from a hostname on a laptop to a server, and see which layer makes each decision.
One request crosses several decision points
What happens after an application asks for app.example.test?
Resolve: DNS returns 203.0.113.80
Illustrative DNS answer: app.example.test A 203.0.113.80
DNS supplies an address before TCP begins. The client then selects a route and a next-hop link address; routers repeat forwarding decisions at each hop.
Boundary: The diagram keeps TLS and internet-provider routing outside the frame. 203.0.113.80 and 198.51.100.0/24 are documentation-only addresses.
Failure state: The resolver has no usable answer. No TCP SYN is sent because the application does not yet have a destination address.
OSI, reimagined around one request
How do seven OSI layers relate to the TCP/IP stack your request actually uses?
OSI names the jobs. TCP/IP groups the protocols used to do them.
| OSI model | TCP/IP model |
|---|---|
| L7ApplicationMeaning of the exchange | ApplicationApplication protocols and libraries |
| L6PresentationRepresentation of data | |
| L5SessionCoordination of the dialog | |
| L4TransportCommunication between endpoints | TransportTCP · UDP |
| L3NetworkAddressing and routing across networks | InternetIP |
| L2Data linkFrames on the local link | LinkLocal network access |
| L1PhysicalSignals through the medium |
THIS HTTPS REQUEST
Sender: application bytes down to the link
- ApplicationHTTP over TLS
GET / → protected bytesThe HTTP exchange uses TLS above TCP in this example. - TransportTCP segment
51514 → 443An ordered byte stream between transport endpoints. - InternetIPv4 packet
10.20.10.25 → 203.0.113.80IP addresses guide delivery across routed networks. - LinkEthernet + signals
Client MAC → gateway MACA frame reaches the local next hop through the medium.
The receiving endpoint processes the data up its stack.
Functions overlap. TCP/IP has no separate presentation or session layer. Applications, libraries, and transport protocols divide those jobs; these bands are a teaching correspondence.
Where does TLS fit? Here it protects HTTP above TCP. Assigning it a universal OSI layer hides how the protocols actually compose.
Four or five layers? This uses the four-layer Internet model. A common five-layer teaching version separates physical signaling from the link layer.
Model references: ITU-T X.200 §6–7 · RFC 1122 §1.1.3 · TLS 1.3 §1
Application: HTTP gives the request meaning; TLS protects its bytes above TCP here. Representation and dialog functions live in applications and libraries rather than separate mandatory OSI modules.
For this HTTP-over-TLS-over-TCP example: DNS resolved ≠ TCP connected TCP connected ≠ TLS accepted TLS accepted ≠ HTTP request succeeded
Open Systems Interconnection (OSI) separates seven communication responsibilities. The TCP/IP model groups Internet protocols into application, transport, internet, and link layers. Select a band to connect the vocabulary to this HTTPS request.
- Application: HTTP gives the request meaning; TLS protects its bytes above TCP here. Representation and dialog functions live in applications and libraries rather than separate mandatory OSI modules.
- Transport: TCP carries an ordered byte stream between ports 51514 and 443. A successful TCP connection does not prove TLS trust or a successful HTTP response.
- Internet: IPv4 addresses identify the source and destination for routed delivery. Each router chooses its next hop; a destination IP does not identify the Ethernet next hop.
- Link: Ethernet frames target the next hop on this local link, and physical signaling carries the encoded data. At a router, the outgoing link gets a new frame.
Boundary: This is an approximate functional correspondence, not a one-to-one protocol assignment. Session functions can span applications and transport. TLS runs above TCP in this example; HTTP/3 uses a different stack with QUIC over UDP.
Failure state: The client loses physical link connectivity. Its configured IP address can still exist, but this interface cannot send frames to the gateway. Higher-layer configuration cannot restore the missing link.
Each layer adds the address it owns
Which address matters to the next device, and which one identifies the final peer?
Application: HTTPS request bytes
$ ip route get 203.0.113.80 … via 10.20.10.1 dev eth0 src 10.20.10.25
The Ethernet frame is only for the current local link. The IP packet carries the end-to-end destination, while TCP identifies the receiving transport endpoint.
Boundary: The exact link layer changes across a path. A router removes the incoming frame and builds a new frame for its outgoing link.
Failure state: The route is valid, but the host cannot resolve the gateway’s link-layer address. Local delivery waits or fails before the frame can leave.
The prefix decides what is local
Does 203.0.113.80 live on the client’s link?
Client IP: 10.20.10.25/24
Illustrative: 10.20.10.25/24 → connected route 10.20.10.0/24
The client has 10.20.10.25/24, so its directly connected subnet is 10.20.10.0/24. A destination outside it needs a route through a next hop. A prefix describes a network range, not a physical wire.
Boundary: IPv6 uses prefixes too, but its address and neighbor behavior differs. Broadcast is an IPv4 local-link concept.
Failure state: A misconfigured prefix can make the host treat a remote peer as on-link and attempt neighbor resolution instead of using the intended gateway.
The first frame targets the gateway, not the server
What MAC address goes into the Ethernet destination field?
Route: selected next hop 10.20.10.1
Illustrative neighbor record: 10.20.10.1 → 02:aa:bb:cc:dd:01
After route selection, the host resolves the selected IPv4 next hop with ARP on the local link. The outgoing frame uses the gateway’s MAC; the IP packet still names 203.0.113.80.
Boundary: This is IPv4 over Ethernet. IPv6 uses Neighbor Discovery instead of ARP.
Failure state: The route exists but the gateway cannot be resolved on this link, so the first frame cannot be sent to that next hop.
Forwarding chooses the most specific route
Why does this destination use a specific gateway?
10.20.10.0/24local · eth0203.0.113.64/26via 10.20.10.1203.0.113.0/24via 10.20.10.2530.0.0.0/0via 10.20.10.254This table deliberately includes overlapping routes: 203.0.113.80 matches the /26, /24, and default, so the /26 wins.
Lookup: 203.0.113.80 matches /26, /24, and default
Illustrative route table: 203.0.113.64/26 via 10.20.10.1
The deliberately overlapping route table selects 203.0.113.64/26 for 203.0.113.80. That beats 203.0.113.0/24 and the default route. Only then does the host resolve the selected next hop’s link address.
Boundary: NAT is a separate transformation at a configured edge. It is not performed by every router, and the translation state depends on that device.
Failure state: If all matching routes, including the default, are removed, the host stops before neighbor resolution.
TCP establishes a connection before application data
What does TCP add to this HTTPS request?
SYN: client asks to open a TCP connection
Illustrative socket state: SYN-SENT → ESTABLISHED
The client sends SYN, receives SYN-ACK, and returns ACK before exchanging stream data. TCP numbers bytes and acknowledges delivery; UDP carries independent datagrams without a transport handshake.
Boundary: This is a simplified three-way handshake. TLS begins after transport setup, and modern clients may choose QUIC over UDP for some HTTPS traffic.
Failure state: The client retransmits according to TCP behavior; a route or policy problem can leave it waiting before application data is exchanged.
A five-tuple distinguishes this connection
How does the server know which application endpoint should receive it?
Protocol: TCP
Illustrative: TCP 10.20.10.25:51514 → 203.0.113.80:443
For this TCP flow, protocol, source IP and port, and destination IP and port distinguish the transport conversation. The server needs a listener on the destination address/port; a successful DNS lookup says nothing about that listener.
Boundary: A socket can bind a specific address or a wildcard; operating-system connection tracking and proxying can add additional state.
Failure state: A reachable host can reject a connection when no process is listening on the selected destination port.
NAT rewrites a tuple at a configured edge
Which fields change when the private client reaches the outside network?
Inside tuple: 10.20.10.25:51514
Illustrative mapping: 10.20.10.25:51514 ↔ 198.51.100.25:62001
In this source-NAT example, the edge maps 10.20.10.25:51514 to 198.51.100.25:62001. Return traffic uses that mapping to find the private client. The remote destination and its port stay the same in this example.
Boundary: This is an illustrative NAPT mapping, not a universal requirement for IP communication. Both public addresses shown are documentation blocks.
Failure state: Without matching translation state, a later reply cannot be mapped back to this private flow.
DNS returns data before transport starts
How did the client learn 203.0.113.80?
Cache hit: The resolver returns its cached 203.0.113.80 answer without querying authority.
Illustrative DNS record: app.example.test. 300 IN A 203.0.113.80
The application asks a resolver, which may answer from cache or query the DNS hierarchy. An A record supplies an IPv4 address; TTL bounds how long a cached answer may be reused. The later TCP packet does not pass through DNS.
- Cache hit: The resolver returns its cached 203.0.113.80 answer without querying authority.
- Cache miss: With no usable cached answer, the resolver follows delegation and returns the authoritative answer.
Boundary: Resolver behavior, search paths, multiple answers, IPv6 AAAA records, and connection reuse can change observed requests.
Alternate state: Authority now returns 203.0.113.81, but this resolver still returns 203.0.113.80 with 120 seconds left on its cached TTL. The DNS lookup succeeds; the client can attempt a connection to the older address.
A firewall evaluates packets at its own boundary
Why can a SYN fail while a later reply is allowed?
New SYN: evaluate ingress/egress policy
Illustrative policy: allow TCP destination 443; allow established replies
A stateful firewall can remember an allowed flow and classify return packets using connection state. A stateless rule set evaluates each packet independently. Policy order, direction, and location determine where a packet first fails.
Boundary: Different firewalls implement state and timeout behavior differently. A silent drop and an active rejection produce different client evidence.
Failure state: A silent drop leaves the client waiting in SYN-SENT; the server may see no request at all.
Load balancing chooses an endpoint using different evidence
How does the information a balancer inspects change its backend choice?
The balancer’s layer determines the information it can inspect. A healthy target set remains necessary at either layer.
L4 connection: Use transport metadata to choose an eligible backend for this connection.
Illustrative: app.example.test /api → API pool
An L4 balancer can use addresses, ports, protocol and connection state. An L7 HTTP balancer can inspect application attributes such as host and path once it terminates or parses that protocol. Both need healthy eligible targets.
- L4 connection: Use transport metadata to choose an eligible backend for this connection.
- L7 request: Inspect HTTP host and path to choose the API pool for this request.
Boundary: Products vary in TLS handling, source-IP preservation, connection reuse, and health-check implementation.
Failure state: The balancer can receive the request but has no eligible backend to send it to.
Troubleshoot the first checkpoint that fails
Where should you look when a request times out?
Successful DNS does not prove TCP delivery. A successful direct IP connection does not prove the name or proxy path.
Name: getent hosts app.example.test
$ nc -vz app.example.test 443 Connection to app.example.test 443 port [tcp/https] succeeded!
Test a claim at each layer: name resolution, route, neighbor reachability, TCP handshake, policy, then application response. A later test cannot repair an earlier missing prerequisite.
Boundary: ICMP behavior and firewall policy vary, so a failed ping does not by itself prove TCP is blocked.
Failure state: The packet reaches the policy boundary, which silently drops the SYN. The client remains in SYN-SENT until its timeout.