Infra, Illustrated.
FOUNDATIONS · PACKET JOURNEY

Networking, Illustrated

Follow one HTTPS request from a hostname on a laptop to a server, and see which layer makes each decision.

CLIENT · client.lab.exampleFLOW EXPLORER · FOUNDATIONALPublished Sep 16, 2026 · Reviewed Sep 16, 2026
LIVE SCENARIOHTTPS · app.example.test · 10.20.10.25:51514 → 203.0.113.80:443READY
NAMEapp.example.test
DSTunknown
NEXT HOPunresolved
SRC10.20.10.25:51514
01 / REQUEST

One request crosses several decision points

What happens after an application asks for app.example.test?

PACKET PATHCHECKPOINT 01 / 06
SIDE LOOKUP · DNSapp.example.test10.20.10.53answer 203.0.113.80
Client10.20.10.25
Local linkgateway MAC
Gateway10.20.10.1
Edge NATsource tuple may change
Server203.0.113.80:443
FIRST HOP ENVELOPE
ETHERNET gateway MACIP 203.0.113.80TCP 51514 → 443
Ethernet names this link’s next hop; IP names the remote destination.

Resolve: DNS returns 203.0.113.80

OBSERVABLE EVIDENCE
Illustrative DNS answer: app.example.test A 203.0.113.80
A network request is one application intent carried through several layer-specific decisions.

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.

02 / REQUEST

OSI, reimagined around one request

How do seven OSI layers relate to the TCP/IP stack your request actually uses?

PACKET PATHCHECKPOINT 01 / 04
SEVEN RESPONSIBILITIESOne request. Two ways to read it.

OSI names the jobs. TCP/IP groups the protocols used to do them.

OSI / TCP/IP · approximate correspondence
OSI modelTCP/IP model
L7ApplicationMeaning of the exchangeApplicationApplication protocols and libraries
L6PresentationRepresentation of data
L5SessionCoordination of the dialog
L4TransportCommunication between endpointsTransportTCP · UDP
L3NetworkAddressing and routing across networksInternetIP
L2Data linkFrames on the local linkLinkLocal network access
L1PhysicalSignals through the medium

THIS HTTPS REQUEST

Sender: application bytes down to the link

  1. ApplicationHTTP over TLSGET / → protected bytesThe HTTP exchange uses TLS above TCP in this example.
  2. TransportTCP segment51514 → 443An ordered byte stream between transport endpoints.
  3. InternetIPv4 packet10.20.10.25 → 203.0.113.80IP addresses guide delivery across routed networks.
  4. LinkEthernet + signalsClient 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.

OBSERVABLE EVIDENCE
For this HTTP-over-TLS-over-TCP example:
DNS resolved ≠ TCP connected
TCP connected ≠ TLS accepted
TLS accepted ≠ HTTP request succeeded
Use layers to identify the responsibility and the evidence you need; a working lower layer does not prove the layers above it work.

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.

03 / REQUEST

Each layer adds the address it owns

Which address matters to the next device, and which one identifies the final peer?

PACKET PATHCHECKPOINT 01 / 04
ETHERNET FRAME 02:11:22:33:44:25 → gateway 02:aa:bb:cc:dd:01
IPV4 PACKET 10.20.10.25 → 203.0.113.80
TCP SEGMENT 51514 → 443
HTTPS request bytes
frame trailer · current link only
At the router, the incoming frame is removed and a new frame is built for the next link. The IP destination normally remains the remote peer.

Application: HTTPS request bytes

OBSERVABLE EVIDENCE
$ ip route get 203.0.113.80
… via 10.20.10.1 dev eth0 src 10.20.10.25
MAC addresses reach the next hop; IP addresses guide the packet across hops; ports select an endpoint.

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.

04 / LOCAL LINK

The prefix decides what is local

Does 203.0.113.80 live on the client’s link?

PACKET PATHCHECKPOINT 01 / 04
CLIENT ADDRESS10.20.10.25/24
PREFIX / HOST BITS
10 . 20 . 10. 25
24 network bits8 host bits
ON THIS SUBNET10.20.10.80may use local neighbor resolution
OUTSIDE THIS SUBNET203.0.113.80needs a selected route / next hop

Client IP: 10.20.10.25/24

OBSERVABLE EVIDENCE
Illustrative: 10.20.10.25/24 → connected route 10.20.10.0/24
Prefix length divides the address space; the route table decides what to do with a destination.

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.

05 / LOCAL LINK

The first frame targets the gateway, not the server

What MAC address goes into the Ethernet destination field?

PACKET PATHCHECKPOINT 01 / 04
CLIENT10.20.10.25route via 10.20.10.1
ARP request → Who has 10.20.10.1?
← ARP reply 02:aa:bb:cc:dd:01
GATEWAY10.20.10.102:aa:bb:cc:dd:01
OUTGOING ETHERNET FRAME
Dst MAC · gatewayDst IP · 203.0.113.80
The remote server’s MAC is not present on this first link.

Route: selected next hop 10.20.10.1

OBSERVABLE EVIDENCE
Illustrative neighbor record: 10.20.10.1 → 02:aa:bb:cc:dd:01
ARP resolves a local next hop. It does not discover the remote server’s Ethernet address across routers.

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.

06 / ROUTING

Forwarding chooses the most specific route

Why does this destination use a specific gateway?

PACKET PATHCHECKPOINT 01 / 04
DESTINATION203.0.113.80Which prefix matches most specifically?
CLIENT ROUTING TABLE
10.20.10.0/24local · eth0
203.0.113.64/26via 10.20.10.1
203.0.113.0/24via 10.20.10.253
0.0.0.0/0via 10.20.10.254
SELECTED IN THIS SCENARIO/26 → 10.20.10.1resolve that next hop’s MACbuild outgoing frameNAT only if configured at a later edge

This 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

OBSERVABLE EVIDENCE
Illustrative route table: 203.0.113.64/26 via 10.20.10.1
Route selection happens before neighbor resolution; the longest matching prefix wins.

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.

07 / TRANSPORT

TCP establishes a connection before application data

What does TCP add to this HTTPS request?

PACKET PATHCHECKPOINT 01 / 04
CLIENT · 10.20.10.25:51514SERVER · 203.0.113.80:443
SYN→open connection
SYN-ACK←server responds
ACK→handshake complete
DATA⇄ordered byte stream
UDP comparisonUDP has ports and checksums but no transport connection handshake or built-in stream retransmission.

SYN: client asks to open a TCP connection

OBSERVABLE EVIDENCE
Illustrative socket state: SYN-SENT → ESTABLISHED
TCP connection state and retransmission are transport responsibilities; they do not repair missing routes or application failures.

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.

08 / TRANSPORT

A five-tuple distinguishes this connection

How does the server know which application endpoint should receive it?

PACKET PATHCHECKPOINT 01 / 04
PROTOCOLTCP
SOURCE IP10.20.10.25
SOURCE PORT51514
DESTINATION IP203.0.113.80
DESTINATION PORT443
SERVER SOCKETsshd or web server binds an address and portThis HTTPS example requires a TCP listener on :443.

Protocol: TCP

OBSERVABLE EVIDENCE
Illustrative: TCP 10.20.10.25:51514 → 203.0.113.80:443
An IP address identifies a host/interface context; a port and protocol identify transport endpoints.

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.

09 / ROUTING

NAT rewrites a tuple at a configured edge

Which fields change when the private client reaches the outside network?

PACKET PATHCHECKPOINT 01 / 04
INSIDE · BEFORE10.20.10.25:51514→ 203.0.113.80:443
SNAT →
OUTSIDE · AFTER198.51.100.25:62001→ 203.0.113.80:443
EDGE MAPPING STATEprivate source ↔ translated sourceNeeded to identify the matching reply flow
← reply to 198.51.100.25:62001 · reverse map to 10.20.10.25:51514

Inside tuple: 10.20.10.25:51514

OBSERVABLE EVIDENCE
Illustrative mapping: 10.20.10.25:51514 ↔ 198.51.100.25:62001
NAT changes selected address or port fields; routing and filtering remain separate decisions.

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.

10 / DISCOVERY

DNS returns data before transport starts

How did the client learn 203.0.113.80?

PACKET PATHCHECKPOINT 01 / 02
APPLICATIONapp.example.test?
RESOLVER CACHEusable A answer?Hit → return answer · miss → ask authority
DNS HIERARCHYdelegation → authorityCache miss only → return answer
RESOLVER ANSWER203.0.113.80Now the application can attempt transport.
DNS lookup is beside the later packet path, not a hop in it.

Cache hit: The resolver returns its cached 203.0.113.80 answer without querying authority.

OBSERVABLE EVIDENCE
Illustrative DNS record: app.example.test. 300 IN A 203.0.113.80
DNS discovers a destination; it is not a forwarding hop for the application packet.

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.

11 / DISCOVERY

A firewall evaluates packets at its own boundary

Why can a SYN fail while a later reply is allowed?

PACKET PATHCHECKPOINT 01 / 03
NEW FLOWTCP SYN → :443
POLICY GATEallow new connection?
RETURN FLOWstate match → allow
STATEFULcan match allowed connection state
STATELESSeach packet needs an applicable rule
ALTERNATE: DENY NEW SYN · stop at this policy boundary

New SYN: evaluate ingress/egress policy

OBSERVABLE EVIDENCE
Illustrative policy: allow TCP destination 443; allow established replies
A filter decision depends on rule context and connection state, not just the destination IP.

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.

12 / DISCOVERY

Load balancing chooses an endpoint using different evidence

How does the information a balancer inspects change its backend choice?

PACKET PATHCHECKPOINT 01 / 02
L4 EVIDENCEIP · port · protocolTCP connection metadata
L4 CHOICEeligible backendconnection-oriented routing
L7 EVIDENCEHost + /api pathHTTP attributes after inspection
L7 CHOICEhealthy API targetrequest-oriented routing

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.

OBSERVABLE EVIDENCE
Illustrative: app.example.test /api → API pool
The layer of inspection determines the routing criteria and the connection behavior a balancer can implement.

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.

13 / DIAGNOSIS

Troubleshoot the first checkpoint that fails

Where should you look when a request times out?

PACKET PATHCHECKPOINT 01 / 05
01Namegetent hosts app.example.test
02Routeip route get 203.0.113.80
03Socketss -tn state syn-sent
04PolicyInspect firewall and conntrack state
05ServiceConfirm a listener and application response
FIRST FAILED ASSUMPTIONFollow the evidence, not the timeout alone.

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

OBSERVABLE EVIDENCE
$ nc -vz app.example.test 443
Connection to app.example.test 443 port [tcp/https] succeeded!
Find the first failed assumption, then collect evidence at that layer before changing configuration.

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.