How the web works

Clients, servers, DNS, IP addresses, ports and TCP — everything that happens before your code runs.

Clients and servers

Almost every app you use is split in two:

The client — a browser, a mobile app, a smart TV, or another server — shows things and collects input.
The server (the backend) holds the data and the rules: it validates input, checks permissions, stores and retrieves data, sends emails, talks to payment providers and other services.

The client asks; the server answers. This client–server model is the foundation of the web, and the subject of this whole track — independent of any language. Track 11 then shows how ASP.NET Core implements it.

Never trust the client

Anything running on the user's device can be modified by the user. Prices, permissions and validation must always be enforced on the server — client-side checks are only a convenience.

Addresses: IP and DNS

Machines on the internet are identified by IP addresses: 203.0.113.10 (IPv4) or 2001:db8::1 (IPv6). Humans prefer names like shop.example, so the Domain Name System (DNS) translates names into addresses:

Browser: "What's the address of shop.example?"
  → asks a DNS resolver (your ISP's, or 1.1.1.1 / 8.8.8.8)
  → which asks the root servers → the .example servers → shop.example's name servers
  ← "203.0.113.10, valid for 300 seconds"

Answers are cached at every level for their TTL (time to live), so most lookups are instant. Common DNS record types:

Record	Maps
`A` / `AAAA`	Name → IPv4 / IPv6 address
`CNAME`	Name → another name (an alias)
`MX`	Domain → mail servers
`TXT`	Arbitrary text (used for domain verification, email security)

Ports: which program?

An IP address finds a machine; a port finds the program on it. Servers listen on well-known ports:

Port	Used by
80	HTTP
443	HTTPS
22	SSH
5432 / 1433 / 3306	PostgreSQL / SQL Server / MySQL
6379	Redis

When you run an ASP.NET Core app locally, you'll see something like Now listening on: http://localhost:5000 — port 5000 on your own machine.

TCP: a reliable connection

Data travels across the internet in small packets that can be lost, duplicated or arrive out of order. TCP turns that chaos into a reliable, ordered stream of bytes: it numbers packets, acknowledges them, and retransmits lost ones.

Before sending data, TCP performs a three-way handshake (SYN → SYN-ACK → ACK) — one network round trip. HTTPS then adds a TLS handshake to agree on encryption. That's why reusing connections (HTTP keep-alive, connection pooling) matters so much for performance.

Layers, from top to bottom:
  HTTP        — what you're asking for (GET /products/42)
  TLS         — encryption and server identity (the "S" in HTTPS)
  TCP         — reliable, ordered delivery between two ports
  IP          — routing packets between machines
  Ethernet/Wi-Fi/fiber — the physical link

Putting it all together

Step through a complete request — from typing a URL to the rendered page:

Interactive

The journey of a request

From pressing Enter to a rendered page

1/13

Browser

Your computer

DNS

Name → IP address

Load balancer

203.0.113.10

Web server

ASP.NET Core

Cache

Redis

Database

SQL Server

Browserhttps://shop.example/products/42+0 ms · total ≈ 0 ms

You type a URL and press Enter. The browser splits it into scheme (https), host (shop.example) and path (/products/42). It first checks whether it already has a fresh copy in its own cache — it doesn't.

Every component here — load balancers, caches, databases — gets its own lesson later in this track.

Key takeaways

Clients present; the backend owns data and rules — never trust the client.
DNS maps names to IP addresses, with caching controlled by TTLs.
Ports identify programs on a machine; HTTPS uses 443.
TCP provides reliable ordered delivery after a handshake; TLS adds encryption on top.