How Web Browsing Works Today 

Browser ----HTTP/HTTPS----> Web Server
        (Unicast)

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

2. Join a Multicast Group

Today, a browser requests a resource directly:

GET /index.html

Enter fullscreen mode Exit fullscreen mode

A multicast-capable browser would instead join a group:

JOIN 239.1.1.1

Enter fullscreen mode Exit fullscreen mode

The operating system sends an IGMP Join message into the network:

Browser
    |
IGMP Join
    |
Router

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

Multicast is fundamentally publish/subscribe:

Publisher
      |
      |
239.1.1.1
   /   |   \
User1 User2 User3

Enter fullscreen mode Exit fullscreen mode

Instead of requesting a page, a client subscribes to a channel:

JOIN sports/live

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

Total bandwidth at the server:

10 Mbps × 1,000,000 users

Enter fullscreen mode Exit fullscreen mode

Multicast (hypothetical):

Server
     |
239.1.1.1
     |
Network duplicates packets

Enter fullscreen mode Exit fullscreen mode

The server sends the stream once:

10 Mbps

Enter fullscreen mode Exit fullscreen mode

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:

  1. Join multicast groups via IGMP.
  2. Use a multicast-capable transport — typically UDP.
  3. Speak a publish/subscribe application protocol instead of request/response.
  4. 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.