How Web Browsing Works Today
Browser ----HTTP/HTTPS----> Web Server
(Unicast)
Every browser opens its own dedicated TCP connection to the server. If a million people load the same page, the server handles a million separate connections and sends a million separate responses.
What Would Need to Change
1. Replace TCP with UDP
HTTP/1.1 and HTTP/2 both run over TCP, which requires:
- A per-client connection
- Acknowledgments (ACKs)
- Retransmissions
- Congestion control
- Ordered delivery
None of this works for multicast. A sender cannot maintain separate TCP state for thousands of receivers at once — TCP is fundamentally point-to-point. A multicast-capable browser would need a UDP-based transport instead.
Browser joins multicast group
239.1.1.1:5000
2. Join a Multicast Group
Today, a browser requests a resource directly:
GET /index.html
A multicast-capable browser would instead join a group:
JOIN 239.1.1.1
The operating system sends an IGMP Join message into the network:
Browser
|
IGMP Join
|
Router
The router now knows this client wants traffic addressed to 239.1.1.1.
3. Application Protocol Must Become Publish/Subscribe
HTTP is fundamentally request/response:
Request → Response
Multicast is fundamentally publish/subscribe:
Publisher
|
|
239.1.1.1
/ | \
User1 User2 User3
Instead of requesting a page, a client subscribes to a channel:
JOIN sports/live
4. Content Must Be Identical for Everyone
Multicast only makes sense when every subscriber wants the exact same bytes.
Works well with multicast:
- Live sports broadcasts
- Stock price feeds
- Weather alerts
- IPTV
- Emergency broadcasts
Does not work with multicast:
- Gmail
- Amazon shopping cart
- Banking
- Personalized social media feeds
Why Ordinary Websites Don't Use Multicast
Suppose one million users visit https://amazon.com at the same moment. Each of them gets:
- A different cart
- Different recommendations
- A different account
- Different cookies and session state
User A → HTML A
User B → HTML B
User C → HTML C
Since every response is unique, there is nothing to multicast. The efficiency gain of multicast comes entirely from sending one packet stream to many recipients — and that only works when the payload is the same for all of them.
Where Multicast Would Actually Help
Consider a live World Cup match streamed to a million viewers.
Unicast (today):
Server
├── Stream → User1
├── Stream → User2
├── Stream → User3
Total bandwidth at the server:
10 Mbps × 1,000,000 users
Multicast (hypothetical):
Server
|
239.1.1.1
|
Network duplicates packets
The server sends the stream once:
10 Mbps
The network itself — not the server — duplicates packets at each branch point, so every subscribed client receives the same stream without multiplying the server's outbound load.
Why Browsers Don't Support It Today Regardless
Even if every browser implemented multicast tomorrow, the public Internet largely couldn't carry it:
- Most ISPs do not enable multicast routing.
- Home routers frequently don't forward Internet multicast traffic.
- NAT and firewalls complicate multicast delivery.
- CDNs are architected around scalable unicast, not multicast.
This is why services like YouTube, Netflix, and Twitch rely on many parallel unicast streams distributed through CDNs. It costs more total bandwidth than multicast would, but it works reliably on the Internet as it exists today.
Summary
For a browser to act as a multicast client, it would need to:
- Join multicast groups via IGMP.
- Use a multicast-capable transport — typically UDP.
- Speak a publish/subscribe application protocol instead of request/response.
- Receive content that is identical for every subscriber.
This is precisely why multicast is well suited to live broadcasts, but fundamentally incompatible with interactive or personalized web applications.
Top comments (0)