The browser walks a fixed sequence of small steps before anything shows. First it parses the URL into scheme, host, and path. It resolves the hostname into an IP address. Then it opens a connection to that server on the right port.

Over that connection the browser sends an HTTP request for the path. The server replies with a status code and usually an HTML body. The browser parses the HTML and finds more resources: stylesheets, scripts, images. It fetches each one, often over the same connection.

Each step adds delay, so a slow page usually has one clear culprit. It might be DNS, connection setup, server time, or heavy assets. Knowing the sequence tells you where to look first.

DNS acts like a phone book that maps names to addresses. Your machine asks a resolver, usually run by your ISP or a public service. The resolver checks its cache first. On a miss it walks the name hierarchy from the top.

It asks a root server, which points to the top-level domain server for .com. That points to the authoritative server for the domain. The authoritative server returns the actual IP address. The resolver hands that back to your program.

This lookup happens before any real request, so it sits on the critical path. A cold lookup can add tens of milliseconds. Caching along the way keeps most lookups fast.

TCP gives you a reliable, ordered stream; UDP gives you fast, best-effort messages. TCP sets up a connection, tracks every byte, and resends lost data. It delivers bytes in order, so what you send arrives whole.

UDP just fires packets with no handshake and no retries. Packets can arrive late, out of order, or not at all. In exchange it has almost no overhead and lower latency.

Reach for TCP when correctness matters: web pages, APIs, file transfers, databases. Reach for UDP when speed beats completeness: live video, voice calls, games, DNS lookups. Losing one frame of video beats stalling the whole stream.

HTTP methods tell the server what action you want on a resource. Each request names one method up front. The common ones map to reading, creating, updating, and removing.

• GET fetches a resource without changing it.
• POST submits data, often to create something new.
• PUT replaces a resource with the body you send.
• PATCH updates part of a resource.
• DELETE removes the named resource.
• HEAD fetches only the headers, no body.

Picking the right method matters because caches, proxies, and browsers treat them differently. A GET can be cached and prefetched; a POST usually cannot. Using the wrong one causes surprising behavior. It also confuses other developers reading your API.

Status codes come in families keyed by their first digit. The digit tells you who is happy and who has a problem. You can react to the family even before reading the exact code.

• 2xx means success: the request worked, like 200 OK or 201 Created.
• 3xx means redirect: look elsewhere, the resource moved or is unchanged.
• 4xx means client error: your request was bad, like 404 Not Found or 401 Unauthorized.
• 5xx means server error: the server broke while handling a valid request.

This split guides retries and blame. A 4xx usually will not improve if you retry the same request. A 5xx often will, since the fault sits on the server side.

HTTPS is plain HTTP wrapped inside an encrypted TLS connection. HTTP sends everything as readable text over the wire. HTTPS scrambles it so anyone in between sees only noise.

That layer does three jobs. It hides the content from eavesdroppers. It proves you reached the real server, not an impostor. It detects any tampering with the bytes in transit.

This matters because networks are full of untrusted hops: coffee-shop WiFi, ISPs, proxies. Without HTTPS, passwords and cookies travel in the clear. Browsers now mark plain HTTP pages as not secure, so HTTPS is the default. That is why login pages and payment forms always use it.

The three-way handshake is how two machines agree to start a TCP connection. It takes three messages before any real data flows. Both sides pick a starting sequence number and confirm they can hear each other.

client -> SYN     (let's talk, my seq = x)
server -> SYN-ACK (ok, my seq = y, got your x)
client -> ACK     (got your y, let's go)

SYN means synchronize and ACK means acknowledge. The client's SYN proposes its own starting number. The server's SYN-ACK accepts that and proposes its number too. The final ACK confirms the server's number, so both agree.

It exists because TCP promises ordered, reliable delivery. That promise needs both sides to sync sequence numbers first. The handshake also confirms the path works in both directions. The cost is one round trip of delay before you send data.