Ewolucja komunikacji internetowej

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.

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.