👥 대칭 NAT에서의 WebRTC 연결 수립 과정

1. 초기 상황

• A는 대칭 NAT 환경, B는 일반 NAT 환경(Full Cone NAT, Restricted Cone NAT, Port Restricted Cone NAT 등)에 있음
• STUN 서버를 통해 A와 B는 각각 자신의 공인 IP/Port를 확인
• A와 B는 해당 후보를 서로 교환

2. B의 연결 시도

• B는 A로부터 받은 공인 IP/Port로 패킷을 보냄
• 대칭 NAT의 동작 원리로 인해, A의 NAT 라우터는 B의 요청에 대해 새로운 매핑(공인 IP/Port)을 생성

3. A가 새로운 매핑 정보 인지

• A의 NAT는 새로운 공인 IP/Port를 생성하고, 이를 통해 B의 요청 패킷을 A로 전달
• A는 이 새로운 공인 IP/Port를 감지하고, 피어 반사 ICE 후보로 등록

4. 새로운 후보 교환 및 연결 수립

• A는 새로운 피어 반사 ICE 후보 정보를 B에게 전달
• B는 해당 후보를 통해 다시 A로 접근
• 최적 경로를 선택하여 연결 수립

제약

• A와 B 중 한쪽만 대칭 NAT일 때 이 방식이 작동 가능
• 양쪽 모두 대칭 NAT인 경우, 새로운 매핑을 생성해도 상대방 NAT 라우터에서 막힐 가능성이 높아 TURN 서버 필요

sequenceDiagram
    participant A as 피어 A
    participant NAT_A as A's NAT 라우터 (대칭)
    participant STUN as STUN 서버
    participant NAT_B as B's NAT 라우터
    participant B as 피어 B

    A->>STUN: STUN 요청 (A의 공인 IP/Port 요청)
    STUN-->>A: A의 공인 IP/Port 전달
    B->>STUN: STUN 요청 (B의 공인 IP/Port 요청)
    STUN-->>B: B의 공인 IP/Port 전달

    A->>B: A의 후보 정보 전송 (서버 반사 ICE 후보)
    B->>A: B의 후보 정보 전송 (서버 반사 ICE 후보)
    
    B->>NAT_A: A의 공인 IP/Port로 접근 시도
    NAT_A->>A: 새로운 매핑 생성 후 패킷 전달

    A->>A: 새로운 매핑 인지
    A->>B: 새로운 피어 반사 ICE 후보 전달

    B->>NAT_A: 새로운 후보로 접근
    NAT_A->>A: 패킷 전달
    A->>B: 연결 수립 성공

Loading

ICE 후보 테스트 순서

• ICE는 후보 테스트의 **우선순위(Host → srflx → Relay)**를 기준으로 진행
• Peer-Reflexive 후보는 테스트 중 동적으로 발견되며, relay 후보보다 우선적으로 테스트
• TURN 서버가 있는 경우에도 비용 효율성을 고려하여 가능한 후보를 먼저 시도하며, relay 후보는 최후의 수단으로 사용

graph TD
    Start([ICE 후보 테스트 시작]) --> Host[Host 후보 테스트]
    Host -->|성공| Connected[연결 수립]
    Host -->|실패| Srflx[Server-Reflexive 후보 테스트]
    Srflx -->|성공| Connected
    Srflx -->|실패: Peer-Reflexive 후보 발견| PeerReflex[Peer-Reflexive 후보 테스트]
    PeerReflex -->|성공| Connected
    Srflx -->|실패| Relay[Relay 후보 테스트]
    Relay -->|성공| Connected
    Relay -->|실패| Failed[연결 실패]

Loading