P2P Technology (2) Complete Guide to STUN, TURN, ICE Protocols - In-depth Analysis of NAT Traversal Solutions

Introduction

In the previous article, we explored centralized, decentralized, and distributed network architectures, as well as IPv4, NAT, and their traversal difficulties.

Although we understood the basic principles of NAT traversal, there are still several key problems to solve in practical applications:

Discovery Problem: How do both parties A and B know each other’s internal/external IP addresses? (STUN)
Traversal Failure: What to do when encountering Symmetric NAT? (TURN)
Unified Management: Is there a framework that can integrate the entire NAT traversal process? (ICE)

This article will dive deep into these three core technologies that solve P2P traversal problems. By understanding the operating mechanisms of STUN, TURN, and ICE, you will master the complete technology stack of modern P2P communication.

What is STUN?

STUN (Session Traversal Utilities for NAT) is a lightweight network protocol specifically designed to solve device discovery problems in NAT environments. It allows devices behind NAT to query their own Public IP, Port, and NAT type.

Simply put, STUN is like a mirror that lets you know “what you look like to the outside world”.

When your device is behind NAT, it only knows its internal IP (like 192.168.1.100) but doesn’t know what public IP it displays externally. The STUN Server acts as this “magic mirror”, telling your device: “Your public IP is 203.0.113.5, and the port is 12345”.

📘 RFC Definition: RFC 5389
📖 STUN Wiki

STUN Workflow:

Query Phase: Device A sends a query request to STUN Server
Response Phase: STUN Server returns A’s public IP and port information
Exchange Phase: A and B exchange their respective public addresses through Signaling Server
Traversal Phase: Both parties use the obtained information for NAT hole punching to establish direct P2P connection

This process allows two internal network devices that originally “couldn’t see each other” to find each other and establish direct communication channels.

TIP

STUN is an indispensable first step in implementing P2P communication, but it becomes powerless when encountering Symmetric NAT.

What is TURN?

TURN (Traversal Using Relay NAT) is a “relay protocol” and an enhanced version of STUN. When STUN hole punching fails (such as encountering Symmetric NAT), TURN comes to the rescue.

The core concept of TURN is “relay forwarding”. When two devices cannot establish direct P2P connection, they communicate through a TURN Server as an intermediary.

TURN Operating Logic:

Request Phase: Client requests the TURN Server to allocate a relay port
Establishment Phase: TURN Server establishes dedicated forwarding channels for each client
Communication Phase: All data is first sent to TURN Server, then forwarded to the target

This is like when you and friends A and B cannot talk directly, so you ask another friend C to relay messages. Although it’s not the most efficient way, it at least ensures communication success.

📖 TURN Wiki

WARNING

TURN solves connection problems, but all data goes through the TURN server, which increases bandwidth costs and latency. Commercial services usually need to deploy their own TURN servers.

What is ICE?

ICE (Interactive Connectivity Establishment) is a comprehensive NAT traversal framework, which can be called the “smart butler” of P2P communication. It integrates multiple protocols like STUN, TURN, RSIP, making the entire connection establishment process more automated and intelligent.

ICE’s design philosophy is “multi-path attempt, smart selection”. It doesn’t rely on a single technology but simultaneously tries multiple connection methods and ultimately selects the best path.

ICE Operating Logic:

Collection Phase: Simultaneously collect all possible connection paths (Candidates)
Priority Phase: Prioritize using STUN to establish P2P direct connection
Backup Phase: If STUN fails, automatically switch to TURN relay communication
Optimization Phase: Analyze all successful paths and select the optimal connection method
Establishment Phase: Establish stable bidirectional communication channel

This design ensures finding viable communication solutions in various network environments.

📖 ICE Wiki

ICE Automatic Path Selection Architecture

TIP

ICE is the mainstream approach for modern P2P communication. Services like WebRTC, Zoom, and Google Meet all have built-in ICE mechanisms to handle NAT traversal.

Technology Integration: STUN + TURN + ICE

The three technologies have clear role divisions, forming a complete P2P communication solution:

Protocol	Function Description	Applicable Scenarios
STUN	Help you know “what I look like in external network”	Device discovery in most NAT environments
TURN	Help relay data when hole punching fails	Symmetric NAT or strictly restricted network environments
ICE	Help choose the best communication method with automatic fallback	Unified management of entire connection establishment process

Technology Development Timeline:

STUN (First Generation): Solves device discovery problems but has limitations with complex NAT
TURN (Second Generation): Provides reliable backup but increases bandwidth costs
ICE (Third Generation): Integrates advantages of the previous two, achieving intelligent connection management

TIP

It’s recommended that all real-time video/device connection services adopt ICE framework to maximize connection success rates and maintain STUN/TURN backup mechanisms.

Next Article Preview: Practical Applications

After understanding the theoretical foundations of STUN, TURN, and ICE, the next article will take you into the practical stage:

Signaling Server Design: How to implement the central system for information exchange
WebRTC Deep Application: Modern browser-native P2P communication framework
AWS KVS Practice: Cloud-hosted WebRTC solution deployment techniques

Through specific code and architectural design, you will learn how to transform these theories into practical P2P application systems.

TIP

If you have other insights into STUN, TURN, ICE implementation processes, or are trying technologies like WebRTC and AWS KVS, feel free to comment or email for discussion. Let’s discuss various applications and challenges of P2P together!