Networking & Hosting — How a Website Works, End to End
In short: URL parsed → browser/OS caches checked → DNS resolves the host to an IP (resolver → root → TLD → authoritative) → TCP three-way handshake to port 443 (or QUIC for HTTP/3) → TLS handshake validates the certificate and sets up encryption → HTTP request sent with headers/cookies → CDN/load balancer/reverse proxy route it → web server and application handle it (auth, routing, controller, database) → HTTP response with status, headers, body → browser parses HTML into the DOM, loads CSS/JS/images, builds the render tree, lays out and paints the page;
- further requests reuse the connection.
In short: DNS translates domain names to IP addresses through a hierarchy of servers with caching (TTL).
- An A record maps a name to an IPv4 address (AAAA for IPv6);
- a CNAME makes a name an alias of another name (e.g.
www→shop.azurewebsites.net); - an MX record lists the mail servers for the domain.
- TXT records are used for verification and email security (SPF, DKIM, DMARC).
In short: HTTPS is HTTP over TLS: the connection is encrypted (confidentiality), protected from tampering (integrity), and the server proves its identity with a certificate signed by a trusted certificate authority (authentication).
- Default ports 80 vs 443.
- HTTPS is required for modern browser features, SEO and any login or personal data.
In short: TCP is connection-oriented and reliable: handshake, acknowledgements, retransmission, ordering, flow and congestion control — used for the web, databases, email.
- UDP is connectionless with no delivery guarantees but lower latency and overhead — used for DNS, voice/video, games and QUIC (HTTP/3), where the application handles reliability.
In short: GET (read), POST (create/action), PUT (replace, idempotent), PATCH (partial update), DELETE (remove, idempotent), OPTIONS/HEAD.
- Status: 200 OK, 201 Created, 204 No Content, 301/302 redirects, 304 Not Modified, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 429 Too Many Requests, 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout.
In short: An IP address identifies a machine on a network;
- a port identifies a program/service on that machine (443 HTTPS, 1433 SQL Server);
- a socket is the endpoint IP + port + protocol, and a connection is the pair of endpoints.
- Private IPs (10.x, 172.16–31.x, 192.168.x) are used inside networks and translated by NAT; public IPs are reachable on the internet.
In short: A component that distributes incoming traffic across several servers for scalability and availability, using health probes to skip unhealthy instances.
- Algorithms: round robin, weighted round robin, least connections, IP hash/sticky sessions, least response time.
- Layer 4 balancers route by IP/port (fast); layer 7 balancers understand HTTP and can route by path, host or header and terminate TLS.
In short: A Content Delivery Network caches content at edge servers around the world, so users download from a nearby location: lower latency, less load on the origin, protection against traffic spikes and DDoS, often a WAF and free TLS.
- Best for static assets with long cache headers and fingerprinted file names; dynamic content can also be accelerated.
In short: A forward proxy acts for clients (they connect out through it — corporate filtering, anonymity).
- A reverse proxy acts for servers (clients connect to it and it forwards to backend servers — TLS termination, load balancing, caching, compression, hiding internal servers).
- Nginx, IIS ARR, YARP and Azure Application Gateway are reverse proxies.
In short: Install the .NET Hosting Bundle (runtime + ASP.NET Core Module).
- IIS receives requests via HTTP.sys and the app pool's
w3wp.exe; - the ASP.NET Core Module runs the app in-process (inside w3wp, fastest) or out-of-process (proxying to Kestrel).
- The app pool uses "No Managed Code";
web.config(generated on publish) configures the module; bindings and certificates are set in IIS.
In short: HTTP/1.1: text protocol, one outstanding request per connection (browsers open ~6 connections per host), keep-alive.
- HTTP/2: binary framing, multiplexes many requests over one TCP connection, header compression; still suffers TCP head-of-line blocking on packet loss.
- HTTP/3: runs over QUIC (UDP), independent streams without head-of-line blocking, faster connection setup, connection migration across networks.
In short: Cookies are small values sent automatically with every request to the domain (can be HttpOnly/Secure/SameSite) — used for session ids and auth.
- A session is server-side data keyed by a session id cookie. localStorage/sessionStorage are browser-only key-value stores readable by JavaScript and never sent automatically — fine for preferences, not for tokens (XSS risk).
In short: IaaS: you get VMs/networks and manage the OS and everything above (Azure VM).
- PaaS: the platform runs your app; you manage code and configuration (Azure App Service, Azure SQL).
- SaaS: complete software you just use (Microsoft 365, Salesforce).
- Serverless: run functions or containers on demand with automatic scaling and pay-per-use (Azure Functions, Container Apps), no server management at all.
In short: The client and server negotiate a cipher suite, exchange keys with (elliptic-curve) Diffie-Hellman, and derive symmetric session keys;
- the server presents a certificate binding its public key to the domain, signed by a certificate authority the client trusts.
- The client checks the chain, validity dates, hostname (SAN) and revocation.
- The certificate proves the server controls the domain (DV) and, for OV/EV, who the organisation is.
In short: Check from outside (another network, downforeveryoneorjustme, mobile data).
- DNS:
nslookupfrom different resolvers — wrong/expired record or propagation. - Connectivity:
Test-NetConnection host -Port 443, firewall/NSG, load balancer health probes. - TLS: expired certificate or missing intermediate (SSL Labs).
- Server: app pool/process running, logs (Event Viewer, stdout, Application Insights), 5xx errors, resource limits.
- Recent changes: deployment, certificate renewal, DNS edits.
- Your machine may use a cached DNS entry or hosts-file entry.
In short: DNS caching: resolvers and clients cache the old A record until its TTL expires (and some ignore TTLs).
- Next time lower the TTL (e.g. to 300 s) a day before the move, then change the record, keep the old server running (or redirecting) until traffic drains, and raise the TTL afterwards.
In short: The app crashed during startup.
- Enable
stdoutLogEnabled="true"in web.config (create the logs folder with write permission) or check Event Viewer → Application; - run the app from the command line on the server (
dotnet Shop.Web.dll) to see the exception. - Common causes: wrong/missing .NET runtime or Hosting Bundle, missing config/connection string for the environment, file permissions for the app pool identity, database unreachable at startup, wrong
ASPNETCORE_ENVIRONMENT.
In short: The app keeps session or authentication state per server (in-memory session, per-machine Data Protection keys), and the load balancer sends requests to different instances.
- Fix: store session in a distributed cache (Redis/SQL), share the ASP.NET Core Data Protection key ring (Blob Storage/Redis + Key Vault), or use stateless tokens;
- sticky sessions only as a stop-gap.