Web通信の進化

How does your browser actually talk to a website? We start with the web's foundation, HTTP, then see why it struggles with realtime interactions.

HTTP (HyperText Transfer Protocol) is the rule set browsers and servers use to understand each other — it fires every time you load a URL or click a link.

HTTP runs on a request-response model: the client asks, the server answers. It's a one-way street, always kicked off by the client.

HTTP is stateless: each request-response pair is independent. The server doesn't remember your last request without extra work like cookies or sessions.

For static content — articles, images, files — HTTP is efficient and reliable. You request a page, get it, and the connection closes until you ask again.

Then came dynamic content: live chat, stock tickers, multiplayer games, collaborative editors. This is where plain HTTP starts to strain.

HTTP's realtime problem: it's client-initiated, so the server can't push updates on its own. Imagine a chat app where you must hit refresh for new messages.

True realtime needs the server to push data the moment it's ready, unprompted. HTTP wasn't built for server-push, so simulating it is wasteful.

HTTP's realtime limits: it's unidirectional and stateless, every request carries header overhead, and constant polling adds latency to fresh data.

Based on what we've learned, what is the primary limitation of standard HTTP for building truly realtime applications?

Recap: HTTP powers the web with a stateless request-response cycle, great for static content but weak at instant, server-initiated updates. Realtime needs more.