릴레이 연결을 위한 TURN 서버

When direct connections between peers fail, TURN (Traversal Using Relays around NAT) servers step in. They act as a relay, forwarding all data between the peers.

Think of it as a middleman. Instead of talking directly, peers send their data to the TURN server, which then forwards it to the other peer.

In the previous lessons, we learned about STUN. STUN helps peers discover their public IP and port, which works for most NAT types.

However, some strict network environments, like symmetric NATs or corporate firewalls, can block direct connections even after STUN. This is when TURN becomes essential.

Unlike STUN, which only helps discover addresses, TURN actively participates in the data exchange. Both peers connect to the TURN server, and all media (audio, video) and data channel messages flow through it.

This ensures connectivity even in the most challenging network setups, albeit with some overhead.

When a peer cannot establish a direct connection, it sends a request to the TURN server. This request asks for an "allocation" – a specific IP address and port on the TURN server.

This allocated address acts as the public point of contact for that peer, allowing the other peer to send data to it via the TURN server.

Here's how data flows through a TURN server:

• 1. Peer A sends data: Peer A transmits its media (e.g., video frames) to the allocated address on the TURN server.
• 2. TURN forwards data: The TURN server receives the data and then forwards it to Peer B's allocated address (or directly to Peer B if it has a direct path to the TURN server).
• 3. Peer B receives data: Peer B receives the relayed media from the TURN server.

The process is mirrored for data flowing from Peer B to Peer A.

Relaying data consumes significant bandwidth and computational resources on the TURN server. To prevent abuse and manage costs, TURN servers almost always require authentication.

Peers provide a username and password (or a temporary credential) to the TURN server before an allocation is granted. This ensures only authorized users can utilize the relay services.

In WebRTC, you provide TURN server details within the RTCPeerConnection configuration, specifically in the iceServers array.

An entry for a TURN server includes its URL (using the turn: protocol), a username, and a credential (password). WebRTC automatically tries to use these servers if direct connections fail.

const configuration = {
iceServers: [
{ urls: 'stun:stun.l.google.com:19302' },
{
urls: 'turn:your.turn.server.com:3478',
username: 'user',
credential: 'password'
}
]
};

This snippet is for illustration; a full runnable example would require a complete WebRTC client setup.

Because TURN servers relay all data, they consume a lot of network bandwidth. This can be a significant operational cost, especially for applications with many users or high-bandwidth media streams.

Therefore, TURN is typically seen as a fallback mechanism, used only when direct peer-to-peer connections (facilitated by STUN) are not possible. This minimizes bandwidth usage and costs.

To summarize the difference:

• STUN: Helps peers discover their public IP and port to establish a direct connection. It's lightweight and inexpensive.
• TURN: Acts as a relay for all traffic when a direct connection cannot be made. It ensures connectivity but is resource-intensive and more costly.

WebRTC implementations usually try STUN first, then fall back to TURN if necessary.

We've explored the crucial role of TURN servers in WebRTC. While STUN helps establish direct connections, TURN provides a reliable fallback by relaying all traffic when direct paths are blocked.

Understanding TURN, its authentication requirements, and cost implications is key to building robust and resilient real-time communication applications that work across diverse network environments.