Real-Time Streaming Systems (WebRTC + Live Data) · 강의

STUN 서버 기능 이해

STUN(Session Traversal Utilities for NAT) 서버가 피어가 공용 IP 주소와 포트 매핑을 확인하도록 돕는 방식을 배웁니다.

STUN 서버 기능 이해은(는) CoddyKit의 무료 Real-Time Streaming Systems (WebRTC + Live Data) 강의입니다. 이것은 4개 중 2번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Real-Time Streaming Systems (WebRTC + Live Data) 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Real-Time Streaming Systems (WebRTC + Live Data) 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

What is a STUN Server?

Welcome! Today we'll unravel the mystery of STUN servers. STUN stands for Session Traversal Utilities for NAT. It's a key technology that helps WebRTC connections work.

Its main job is to help devices behind a NAT (Network Address Translator) discover their public IP address and port number. This is crucial for establishing direct peer-to-peer connections.

NAT: A Quick Reminder

Remember NAT from our previous lesson? NAT helps multiple devices in a private network share a single public IP address. While great for conserving IPs, it hides your device's true network address from the outside world.

For WebRTC, this is a problem! Peers need to know each other's actual, routable addresses to connect directly. STUN is here to solve this.

STUN's Core Function: Discovery

Think of a STUN server as a friendly helper on the public internet. When your device wants to know its public identity, it asks the STUN server, "Hey, what's my public IP and port from your perspective?"

The STUN server replies with the public address it observed your request coming from. This is your device's public 'face' to the internet.

The STUN Request Flow

Here's how a STUN request typically works:

Your WebRTC client sends a 'binding request' to a known STUN server.
This request travels through your local network and then through your NAT.
The NAT modifies the packet, assigning a public IP and port before sending it out.
The STUN server receives this request.

Understanding the STUN Response

When the STUN server gets your request, it records the source IP and port of the incoming packet. This is what it sees as your public address.

It then sends a 'binding response' back to your client, containing this observed public IP and port. Your client now knows how it appears to the outside world!

Binding Requests in Detail

The 'binding request' isn't just a simple 'hello'. It's a specific message format defined by the STUN protocol.

It contains a transaction ID to match requests with responses.
It asks the server to reflect the client's observed network address.
The response carries attributes like XOR-MAPPED-ADDRESS, which is the public IP and port.

STUN & WebRTC's ICE

STUN servers are a fundamental part of WebRTC's ICE (Interactive Connectivity Establishment) framework.

ICE uses STUN (and sometimes TURN) to gather all possible network addresses (called 'candidates') for a peer. These candidates include local IPs, public IPs (from STUN), and relayed IPs (from TURN).

Configuring STUN in WebRTC

In WebRTC, you configure STUN servers as part of your RTCPeerConnection setup. The browser then handles the communication with the STUN server automatically to gather ICE candidates.

Here's how you define a STUN server for your peer connection:

const configuration = {
  iceServers: [
    {
      urls: 'stun:stun.l.google.com:19302'
    }
  ]
};

const peerConnection = new RTCPeerConnection(configuration);

// The browser will now use the STUN server
// to discover public IP/port for ICE candidates.

STUN vs. NAT Types

STUN works very well with certain types of NATs, like Full Cone NAT and Restricted Cone NAT, where the mapping of internal to external ports is consistent.

However, STUN can struggle with more complex NATs, such as Symmetric NATs. For these, a TURN server (which we'll cover next!) is often required to relay traffic.

Test Your STUN Knowledge

Which of the following best describes the primary role of a STUN server in WebRTC?

STUN: Your NAT Helper

Great job! You've learned that STUN (Session Traversal Utilities for NAT) servers are vital for WebRTC.

They help devices behind NATs find their public IP and port.
This discovery is crucial for ICE to gather connectivity candidates.
STUN works well for many NAT types, but not all.

Next, we'll explore TURN servers, which tackle the toughest NAT challenges!

자주 묻는 질문

“STUN 서버 기능 이해” 강의는 무료인가요?

네 — “STUN 서버 기능 이해” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Real-Time Streaming Systems (WebRTC + Live Data) 강의 전체를 잠금 해제할 수 있습니다. Real-Time Streaming Systems (WebRTC + Live Data) 강의에는 총 4개의 강의가 포함되어 있습니다.

“STUN 서버 기능 이해”에서 뭘 배우나요?

STUN(Session Traversal Utilities for NAT) 서버가 피어가 공용 IP 주소와 포트 매핑을 확인하도록 돕는 방식을 배웁니다. 브라우저에서 직접 실행하는 실습 코드로 Real-Time Streaming Systems (WebRTC + Live Data)을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Real-Time Streaming Systems (WebRTC + Live Data)을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Real-Time Streaming Systems (WebRTC + Live Data)은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 2번째 강의입니다.

“STUN 서버 기능 이해” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Real-Time Streaming Systems (WebRTC + Live Data) 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Real-Time Streaming Systems (WebRTC + Live Data) 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Real-Time Streaming Systems (WebRTC + Live Data)(으)로 돌아가기