You type a name and a page appears. The previous lesson followed that journey from the browser's point of view. This one goes one level down, to the part nearly every later topic quietly assumes you know.
A load balancer "distributes traffic across ports". A proxy "terminates the connection". A database "listens on 5432". A firewall "allows inbound 443 from the load balancer only". None of those sentences mean anything without the vocabulary below, and none of the later lessons stop to define it.
Machines find each other by number, not by name
Every machine reachable on a network has an IP address — a number that identifies where it is, in the way a street address identifies a building.
IPv4 addresses are written as four numbers, each 0–255, like 93.184.216.34. That gives about 4.3 billion possible addresses, which sounded limitless in the 1980s and ran out decades ago.
IPv6 addresses are much longer, written in hexadecimal like 2606:2800:220:1:248:1893:25c8:1946. There are enough of them that running out is not a practical concern.
Names exist only for humans. DNS turns a name into an address, and after that the name is irrelevant — every router along the path makes its decision from the number alone.
A port says which program, not which machine
An address gets a packet to the right machine. But a machine runs many programs at once: a web server, a database, a metrics agent. A port number says which of them the packet is for.
If the IP address is the building, the port is the flat number.
Ports are 16-bit numbers, so 1 to 65535. Some are conventional:
- 80 — HTTP
- 443 — HTTPS
- 22 — SSH
- 5432 — PostgreSQL
- 6379 — Redis
Nothing enforces these; they are agreements. A web server can listen on 8080 and frequently does. The convention matters because it lets a browser assume 443 when you type a name without one.
A connection is identified by four things together: source address, source port, destination address, destination port. Your laptop opening two tabs to the same site produces two connections that differ only in the source port — which is how the machine knows which response belongs to which tab.
The layers, and why anyone cares
Networking is built in layers, each using the one below without knowing how it works. The useful mental model has four:
Diagram, as text
- Application: HTTP, DNS leads to Transport: TCP, UDP
- Transport: TCP, UDP leads to Network: IP, routing
- Network: IP, routing leads to Link: Ethernet, wifi
- Link moves bits between two directly connected devices.
- Network (IP) gets a packet across many hops to the right machine anywhere in the world. It makes no promise it will arrive.
- Transport (TCP, UDP) adds ports, and optionally reliability and ordering.
- Application (HTTP, DNS) is your actual request.
The layering matters for one practical reason: each layer can fail on its own, and the symptoms look different. A name that will not resolve is DNS. A connection that hangs before any response is transport or routing. A connection that opens and returns 500 is your application. Knowing which layer you are in tells you which tool to reach for.
Private addresses and NAT
Most machines do not have their own public address. Home networks, office networks and cloud virtual networks use private address ranges — reserved blocks that are meaningless on the public internet:
10.0.0.0to10.255.255.255172.16.0.0to172.31.255.255192.168.0.0to192.168.255.255
Your laptop's 192.168.1.14 exists on millions of networks simultaneously. It works because of NAT (network address translation): a router with one public address rewrites outgoing packets to appear to come from itself, remembers which internal machine sent them, and rewrites the replies back.
The consequence is asymmetry. A machine behind NAT can start a connection outwards, but nothing outside can start one inwards — there is no address to aim at. This is why a database in a private subnet is unreachable from the internet by default, and why exposing a service deliberately means putting something with a public address in front of it.
Bandwidth, latency and packet loss are three different things
These get used interchangeably and are not the same.
- Bandwidth is how much data fits through per second. A wide pipe.
- Latency is how long one packet takes to arrive. A long pipe.
- Packet loss is the fraction of packets that never arrive at all.
A satellite link can have enormous bandwidth and terrible latency. A mobile connection in a tunnel can have decent latency and 30% loss. Loss is the one that hurts most surprisingly, because a reliable protocol responds by retransmitting and slowing down, so a few percent of loss can collapse throughput far more than the raw number suggests.
Distance is the part people underestimate, because it is the one thing no amount of bandwidth fixes:
Round trip time by distance
The data as a table
| Round trip time | Round trip |
|---|---|
| Same rack | 0.5 ms |
| Same city | 5 ms |
| Across a country | 40 ms |
| Across an ocean | 150 ms |
A protocol that needs three round trips before it sends anything useful costs half a second across an ocean and almost nothing in the same rack. That single fact explains most of why TLS handshake reuse, connection pooling and edge locations exist.
Check your understanding
Common mistakes
Confusing an address with a name. DNS changes are cached and land slowly and unevenly; the address is what actually routes. Debug with the address before assuming the name is right.
Assuming a private address is a security boundary. Being unroutable from the internet is not the same as being protected. Anything else inside the same network can usually reach it.
Treating bandwidth as the fix. Most user-facing slowness is latency or loss. Adding bandwidth to a high-latency path changes nothing a user notices.
Forgetting that ports are per machine, not per service. Two containers on one host cannot both hold port 8080 on the same address, which is the source of a large share of first-deployment failures.
Reading a timeout as "the other side is down". A timeout means no answer came back. The other side may be healthy and simply unreachable from where you are standing.
Practice
A service in a private subnet needs to call a payment provider on the public internet, and must also receive webhooks back from that provider. Explain why one direction works by default and the other does not, and describe what each direction requires.
Write your own answer first, on paper or in a note. Then compare.
Show a hint
NAT remembers connections it started. It has nothing to remember for a connection it did not.
Show a strong answer
Outbound works by default. The service opens a connection to the provider. NAT rewrites the source to the router's public address and records the mapping, so when the reply comes back it knows which internal machine to forward it to. Nothing had to be configured, because the mapping was created by the outgoing packet.
Inbound does not work, because the provider's webhook is a new connection that NAT has no record of. There is no internal address to translate to, and no public address that names the service. The packet arrives at the router and is discarded.
What each direction needs:
- Outbound: an egress path — a NAT gateway or equivalent — plus a rule permitting the destination port (443). Note that the provider will see the gateway's address, not the service's, which matters if they operate an allow-list.
- Inbound: something with a public address that the provider can aim at — a load balancer or API gateway — which terminates the connection and forwards it inwards. The service itself stays private; only the entry point is exposed, and only on the one port and path the webhook uses.
This asymmetry is a feature, not an obstacle. It means the default posture is "nothing is reachable" and every exposure is a deliberate act.
A user reports the app is unusable. You need to find which layer is at fault. Describe a sequence of checks that isolates the layer, and what each result tells you.
Write your own answer first, on paper or in a note. Then compare.
Show a hint
Work upwards. Each check should only be meaningful if the one below it passed.
Show a strong answer
Work from the bottom of the stack up, because a failure low down makes every check above it meaningless.
- Does the name resolve? Ask for the address. If resolution fails or returns an unexpected address, the problem is DNS and nothing above matters. A stale cached answer pointing at a decommissioned address is a classic and looks exactly like the service being down.
- Does a connection open to the port? If resolution worked but the connection hangs, the problem is routing or a filtering rule — packets are leaving and nothing is coming back. If it is actively refused rather than hanging, something answered: the machine is reachable and nothing is listening on that port. Hang and refuse are different diagnoses and separating them saves hours.
- Does the handshake complete? A connection that opens but fails during encryption negotiation points at certificates — expired, wrong name, or an untrusted issuer.
- Does a request return? Now you are in the application. A 500 is your code, a 502 or 504 is something in front of you failing to reach what is behind it, and a 200 with wrong content is a correctness problem rather than an availability one.
The discipline is not the specific tools; it is refusing to guess about layer four while layer three is unverified.
Key takeaways
- Addresses identify machines, ports identify programs. A connection is the four-tuple of both ends, which is how one machine keeps thousands of conversations apart.
- The layers fail independently and produce different symptoms. Resolution failures, timeouts, refusals and 500s each point at a different level.
- Private addresses plus NAT make outbound easy and inbound impossible by default. Anything reachable from outside was deliberately exposed.
- Bandwidth, latency and loss are three separate properties. Most user-visible slowness is latency, and loss punishes throughput far more than its percentage suggests.
- A timeout means no answer came back, which is not the same as the other side being down.
Further reading
- RFC 791, Internet Protocol, and RFC 8200, Internet Protocol, Version 6 (IPv6) Specification — the addressing layer itself.
- RFC 1918, Address Allocation for Private Internets — where the private ranges come from and what they guarantee.
- RFC 3022, Traditional IP Network Address Translator — how NAT maintains its mappings.
- W. Richard Stevens, TCP/IP Illustrated, Volume 1, second edition (Addison-Wesley, 2011) — the standard reference for the whole stack.
- Ilya Grigorik, High Performance Browser Networking (O'Reilly, 2013), chapters 1–2 — latency, bandwidth and loss, with the arithmetic worked through.