Why Peer-to-Peer Communication Is So Hard

The Dream of Peer-to-Peer Communication

Imagine two users:

Alice
Bob

Both have Internet connections.

Both have browsers.

Both want to start a video call.

The ideal scenario is:

Alice <---> Bob

No realy.

No media server.

No middleman.

Just direct communication.

This is called:

Peer-to-Peer (P2P)

Communication.

Why P2P Is Attractive

Let's understand why engineers love P2P.

Lower Latency

Consider:

Alice <--> Server <--> Bob

Every packet takes an extra trip.

Now compare:

Alice <--> Bob

Fewer hops.

Lower latency.

Better conversations.

Lower Infrastructure Cost

Suppose 1000 users.

Each video stream:

2 Mbps

Through a server:

1000 x 2 Mbps incoming
1000 x 2 Mbps outgoing

Massive bandwidth bills

With P2P:

Alice <--> Bob

Media bypasses servers.

Much cheaper.

Better Scalability

Every user no longer consumes larger amounts of server bandwidth.

The system scales better.

This is why P2P became highly desirable.

Why Direct Communication Fails

Let's create the simplest scenarios possible.

Example Network:

Alice:
	Public IP: 45.10.20.30

Bob:
	Public IP: 88.90.100.110

No NAT.

No firewall.

No restrictions.

Connection:

Alice <--> Bob

Works.

Easy.

Unfortunately, this is not how the real world works.

The Real Internet

Most users look like this:

Laptop
|
Router
|
Internet

The laptop does not have a public IP.

It has private IP.

Example:

192.168.1.10

This changes everything.

The Hidden Device Problem

Alice:

Private IP: 192.168.1.10

Bob:

Private IP: 192.168.0.25

Now Alice tells Bob:

Connect to: 192.168.1.10

Bob tries.

Nothing happens.

Why?

Because:

192.168.1.10

exists only inside Alice's local network.

It has no meaning on the public Internet.

Understanding NAT

NAT stands for:

Network Address Translation

Its job:

Private IP
      ↓
Public IP

When Alice sends traffic:

192.168.1.10

becomes:

49.36.10.25

on the Internet.

The router performs this translation.

The Critical NAT Rule

Here is the rule that breaks P2P

NAT devices allow outgoing connections easily.

But they generally block unexpected incoming connections.

This behavior protects users.

Example:

Alice opens:

google.com

Traffic:

Alice
   ↓
Router
   ↓
Google

Works perfectly.

Because the connection started from inside.

Now suppose a random computer on the Internet says:

I want to connect to Alice

Router response:

Who are you?

Connection rejected.

Why Routers Behave This Way

Imagine if routers accepted all incoming traffic.

Anyone on the Internet could directly connect to:

Your Laptop
Your Phone
Your Smart TV

This would be a security nightmare.

Therefore routers become gatekeepers.

The Core Problem

Peer-to-peer requires:

Alice -> Bob
Bob -> Alice

But both routers block incoming traffic.

So we get:

Alice ❌ Bob

Nobody can reach anybody.

NAT Translation Tables

Routers keep temporary records.

Example:

Internal: 192.168.1.10:5000

Mapped To: 49.36.10.25:620000

This mapping exists only because Alice initiated communication.

The router remembers:

If responses arrive,
send them back to Alice.

The Important Observation

The router creates a hole.

Example:

Alice -> Internet

Router temporarily opens:

49.36.10.25:62000

Responses can come back through this opening.

This observation led to one of the most important techniques in networking.

Hole Punching

Instead of waiting for incoming traffic, both peers send outgoing traffic first. Since outgoing traffic is allowed:

Alice -> Bob
Bob -> Alice

Each router creates temporary mappings.

These mappings creates holes.

Hence the name: NAT Hole Punching.

Example:

Alice's Router:

192.168.1.10:5000
        ↓
49.36.10.25:62000

Bob's Router:

192.168.0.25:7000
        ↓
88.20.15.90:54000

Now each peer learns the other's public mapping.

Alice learns:

88.20.15.90:5000

Bob learns:

49.36.10.25:62000

Both send packets simultaneously.

Routers see expected traffic.

Connection succeeds.

The Missing Piece

Wait. How does Alice learn:

88.20.15.90:54000

And how does Bob learn:

49.36.10.25:62000

The cannot magically know.

This creates another problem.

The Discovery Problem

Every peer must learn:

Its Public Address

and

The Other Peer's Public Address

This requirement gave birth to:

STUN (Session Traversal Utilities for NAT)

Think of STUN as:

"What is my public address?"

service.

Unfortunately, Hole Puching doesn't always work.

This is where networking becomes interesting.

Not all NAT devices behave the same way.

Different routers implement different rules.

Some are friendly.

Some are hostile.

NAT Types

Historically, NAT devices were categorized into several behaviors.

Full Cone NAT

Most permissive.

Once a mapping exists:

49.36.10.25:62000

Almost anyone can send traffic to it.

Easy for P2P.

Restricted Cone NAT

More restrictive.

Only known endpoints can respond.

Still manageable.

Port Restricted NAT

Even stricter.

IP and pot must match expectations.

Symmetric NAT

The nightmare.

Every destination receive a unique mapping.

Why Symmetric NAT Is a Problem

Hole punching elies on predictability.

Symmetric NAT destroys predictability.

As a result:

Direct P2P

often fails.

The Industry Needed a Backup Plan

Engineers realized:

Direct connections will not always work.

A fallback mechanism was required.

The solution:

TURN: Traversal Using Relays around NAT

Concept:

Instead of:

Alice <---> Bob

Use:

Alice
 |
TURN
 |
Bob

The TURN server relays traffic.

Everyone can reach the TURN server.

Therefore communication succeeds.

Tradeoffs

STUN

Pros:

Direct connection
Low latency
Cheap

Cons:

Doesn't always work

TURN

Pros:

Almost always works

Cons:

Higher latency
Higher cost
Consumes bandwidth

The Fundamental Strategy

Modern WebRTC follows this philosophy:

Try Direct Connection First

If successful:

Use Direct Connection

If unsuccessful:

Fallback to TURN

This strategy minimized cost while maximizing reliability.

The Birth of ICE

At this point we have multiple possibilities:

Direct Public IP
Private Network
STUN Address
TURN Relay

Whic path should be used?

Which one is fastest?

Which one actually works?

The industry needed a system to:

1. Discover possibilties
2. Test possibilities
3. Choose the best possibility.

That system became:

ICE: Interactive Connectivity Establishment

The brain of WebRTC networking.