Part 1 let the server reach the browser; Part 2 gave the browser an equal voice back. But in both, every byte still travels through a server. This final part is about the one browser technology that removes the server from the middle: WebRTC, which lets one browser talk straight to another — video, audio, and data, peer to peer.
In Part 1 the server learned to talk without being asked — but the browser could still only listen. A chat, a multiplayer game, a collaborative editor: these need both sides speaking freely over one connection. This is Part 2 of the series, and it's about the browser's true two-way channels — WebSockets, the workhorse, and WebTransport, its modern successor.
Plain HyperText Transfer Protocol (HTTP) has one stubborn rule: the browser asks, the server answers, and then the line goes dead. So how does a chat notification, a live score, or a stream of tokens from a language model reach a page that never asked again? This is Part 1 of a three-part tour of the browser's networking beyond request–response — and it starts with the three ways a server can reach you.
Every framework, HTTP client, and browser hides the protocol behind a few convenient calls — so most developers never see the request that actually goes over the wire. This post pulls back that curtain: the communication model, the methods, the status codes, and the headers you've been using all along without knowing it.
Type a URL, hit Enter, and a page appears. Between that keystroke and the first pixel sits a surprising amount of machinery — DNS, TCP, TLS, HTTP, load balancers, and the services behind them. This post walks the whole path, end to end.
If you've ever nodded along when someone said "that's a layer 4 problem" while secretly having no idea what they meant, this post is for you. We'll walk through the OSI (Open Systems Interconnection) model with a simple, everyday postal analogy, and then use that new knowledge to understand why HTTP/3 — the newest version of the HyperText Transfer Protocol (HTTP) — is such a big deal.
Most developers use curl as a quick way to "hit an endpoint". But curl is much more than that — a tiny HTTP client, a debugging tool, a poor man's Postman, a network probe, a CI health checker, a download manager, and often the fastest way to understand what's really happening between your machine and a server. Here are 25 curl recipes I actually reach for.
When you need to inspect, modify, or replay HTTP(S) traffic, few tools are as powerful and flexible as mitmproxy.
It's open-source, scriptable in Python, and works seamlessly as a man-in-the-middle proxy.