Networking for Developers.

The browser finds the server, asks it for the page, and renders what comes back, in a fixed sequence of small steps.

• It parses the URL into scheme, host and path.
• It resolves the hostname into an IP address through DNS.
• It opens a TCP connection to that server on the right port. For HTTPS, a TLS handshake then sets up encryption.
• It sends an HTTP request for the path. The server replies with a status code and usually an HTML body.
• It parses the HTML and fetches the stylesheets, scripts and images it finds, often over the same connection. Then it renders the page.

Each step adds delay, so a slow page usually has one clear culprit, and knowing the sequence tells you where to look first.

Your machine asks a resolver, which answers from its cache or walks the DNS hierarchy down to the server that owns the name. The resolver is usually run by your ISP or a public service. DNS works like a phone book that maps names to addresses.

On a cache miss, the resolver starts at a root server, which points to the top-level domain server for .com. That server points to the authoritative server for the domain. The authoritative server returns the actual IP address, and the resolver hands it back to your program.

The 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, while 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, as in web pages and APIs. File transfers and databases need it too. Reach for UDP when speed beats completeness, as in live video and voice calls. Games and DNS lookups use it for the same reason. Losing one frame of video beats stalling the whole stream.

An HTTP method tells the server what action you want on a resource, and each request names one method up front.

• 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.

The choice matters because caches, proxies and browsers treat methods differently. A GET can be cached and prefetched, but a POST usually cannot. The wrong one causes surprising behavior and confuses anyone reading your API.

The first digit of a status code names its family, which says whether the request worked and who is at fault. You can react to the family before reading the exact code.

• 2xx is success, like 200 OK or 201 Created.
• 3xx is a redirect, used when the resource moved or has not changed.
• 4xx is a client error, like 404 Not Found or 401 Unauthorized.
• 5xx is a server error on a valid request.

The family guides retries and blame. Resending a 4xx rarely helps, but a retry after a 5xx often works, since the fault sits on the server.

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.

The TLS 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, such as coffee-shop WiFi, ISPs and 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 number and proposes its own. The final ACK confirms the server's number, so both sides agree.

It exists because TCP promises ordered, reliable delivery, and 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.