Interactive Connectivity Establishment(ICE)는 NAT 장비, 방화벽, 여러 네트워크 인터페이스 또는 변화하는 네트워크 조건 때문에 직접 연결이 어려운 상황에서 두 엔드포인트 사이의 미디어 및 데이터 연결을 수립하기 위해 사용되는 네트워크 통과 프레임워크입니다. 실제 환경에서 ICE는 WebRTC, SIP 기반 실시간 미디어, 그리고 가능한 한 자동으로 피어 간 동작 가능한 경로를 찾아야 하는 다양한 인터랙티브 통신 시스템과 가장 자주 연관됩니다.

ICE가 중요한 이유는 간단합니다. 현대 네트워크에서 엔드포인트가 외부에서 바로 접근 가능한 공인 IP 주소에 위치하는 경우는 드뭅니다. 대부분은 가정용 라우터, 기업 방화벽, 통신사 NAT 또는 클라우드 엣지 계층 뒤에 있습니다. 두 장치가 시그널링 메시지를 교환할 수 있다고 해서 오디오, 비디오 또는 데이터 스트림이 직접 흐를 수 있다는 뜻은 아닙니다. ICE는 가능한 네트워크 경로를 수집하고, 이를 원격 측과 교환하며, 어떤 조합이 실제로 동작하는지 테스트하고, 세션에 사용할 수 있는 최적의 경로를 선택함으로써 이 문제를 해결합니다.

ICE는 STUN이나 TURN을 대체하지 않습니다. 오히려 이러한 기술을 함께 사용하는 조정 프레임워크입니다. STUN은 엔드포인트가 NAT 외부에서 어떻게 보이는지 확인하도록 돕고, TURN은 직접 피어 투 피어 연결이 불가능할 때 릴레이 경로를 제공합니다. ICE는 이러한 가능성을 구조화된 의사결정 과정으로 정리하여 실시간 애플리케이션이 더 안정적으로, 그리고 더 적은 수동 네트워크 설정으로 연결될 수 있게 합니다.

ICE는 실시간 엔드포인트가 음성, 영상 또는 데이터 세션에 가장 적합한 네트워크 경로를 발견하고, 테스트하고, 선택하도록 돕습니다.

실시간 네트워킹에서 ICE가 의미하는 것

단순한 프로토콜 메시지가 아니라 연결성 프레임워크

ICE는 단일 패킷 형식이나 단순한 서버 기능이 아니라 완전한 연결성 프레임워크로 이해하는 것이 가장 적절합니다. 그 역할은 두 엔드포인트 사이에서 후보 발견, 후보 교환, 연결성 검사, 최종 경로 선택을 조정하는 것입니다. IETF는 RFC 8445에서 ICE를 UDP 기반 통신을 위한 NAT 통과 프로토콜로 정의하며, 해당 명세는 ICE가 STUN과 TURN을 사용한다고 명확히 설명합니다.

이러한 넓은 관점이 중요한 이유는 많은 사람이 ICE를 처음 접할 때 WebRTC의 iceServers 배열이나 SIP 플랫폼의 NAT 통과 옵션 같은 설정 필드로만 보기 때문입니다. 그러나 내부적으로 ICE는 완전한 의사결정 과정을 관리합니다. 어떤 로컬 인터페이스를 사용할 수 있는지, 어떤 반사 주소나 릴레이 주소가 가능한지, 어떤 피어 조합을 검사할 가치가 있는지, 그리고 어떤 동작 경로를 세션에 지명해야 하는지를 결정합니다.

인터넷에서 직접 연결이 어려운 이유

단순한 공용 네트워크라면 두 장치가 주소를 교환하고 패킷을 직접 보낼 수 있습니다. 하지만 실제 배포 환경은 그렇게 단순하지 않습니다. 장치는 대개 소스 주소와 포트를 다시 쓰는 NAT 뒤에 있습니다. 방화벽은 요청되지 않은 인바운드 트래픽을 차단할 수 있습니다. 모바일 장치는 Wi-Fi와 셀룰러 네트워크 사이를 전환할 수 있습니다. 기업 사용자는 여러 계층의 보안 게이트웨이 뒤에 있을 수 있고, 클라우드 호스팅 서비스도 자체 입출력 정책을 가질 수 있습니다.

이 때문에 시그널링에 표시된 유효해 보이는 주소만으로는 충분하지 않습니다. 해당 주소는 한 방향으로만 도달 가능하거나, 일시적으로만 동작하거나, 원격 피어에서 전혀 도달할 수 없을 수 있습니다. ICE는 하나의 발표된 주소가 작동할 것이라고 가정하지 않고, 여러 연결 옵션을 수집한 뒤 실제 네트워크 환경에서 테스트함으로써 이러한 불확실성을 해결합니다.

ICE는 완벽한 경로 하나를 미리 추측하지 않습니다. 가능한 경로를 모으고, 검사를 통해 검증한 뒤, 실제 네트워크에서 가장 잘 동작하는 경로를 유지합니다.

ICE의 작동 방식

후보 수집

ICE의 첫 단계는 후보 수집입니다. 각 엔드포인트는 세션에 사용할 수 있을 가능성이 있는 주소와 포트를 수집합니다. 이를 ICE 후보라고 합니다. 브라우저 기반 WebRTC에서는 플랫폼이 후보를 발견하는 즉시 이를 발생시킵니다. MDN은 ICE 후보를 WebRTC가 원격 장치와 통신하는 데 필요한 프로토콜과 라우팅 정보라고 설명하며, 양측이 최적의 후보에 합의할 때까지 일반적으로 여러 후보가 제안된다고 설명합니다.

후보 수집은 보통 여러 유형의 가능성을 생성합니다. 호스트 후보는 엔드포인트의 로컬 인터페이스에서 직접 나옵니다. 서버 반사 후보는 흔히 srflx로 표기되며, STUN을 통해 학습되고 NAT가 할당한 외부에서 보이는 주소와 포트를 반영합니다. 릴레이 후보는 트래픽이 릴레이 서버를 통과해야 할 때 TURN을 통해 할당됩니다. 일부 흐름에서는 연결성 검사 중 피어 반사 후보가 생성될 수도 있습니다. 목표는 승자를 즉시 예측하는 것이 아니라, 사용할 수 있는 옵션 집합을 만드는 것입니다.

시그널링을 통한 후보 교환

후보가 수집되면 엔드포인트는 이를 서로 교환해야 합니다. ICE 자체는 이 단계를 위한 단일 범용 시그널링 시스템을 정의하지 않습니다. WebRTC에서는 후보가 보통 애플리케이션의 시그널링 채널을 통해 전송되며, SIP와 다른 미디어 시스템에서는 SDP 및 관련 시그널링 흐름을 통해 전달될 수 있습니다. 중요한 점은 양측이 테스트를 시작하기 전에 상대방의 가능한 경로를 볼 수 있어야 한다는 것입니다.

이 단계는 ICE가 활성화된 배포에서도 여전히 시그널링 설계가 필요함을 보여 줍니다. ICE는 미디어 연결성을 돕지만, 후보 정보를 피어 간에 전달하기 위해 별도의 메커니즘에 의존합니다. 시그널링이 깨지면 ICE는 자신의 역할을 수행할 충분한 정보를 얻지 못합니다. 잘 설계된 시스템에서는 시그널링과 ICE가 함께 작동합니다. 시그널링은 세션 설명과 후보를 전달하고, ICE는 어떤 후보 쌍이 실제로 도달 가능한지 검증합니다.

후보 쌍 구성과 연결성 검사

교환 후 ICE는 로컬 후보와 원격 후보를 우선순위에 따라 결합하여 후보 쌍을 형성합니다. 그런 다음 STUN 기반 트랜잭션을 사용하여 연결성 검사를 수행합니다. 이러한 검사는 쌍을 이룬 후보 사이에서 패킷이 실제로 흐를 수 있는지 판단합니다. RFC 8445는 이 단계를 후보 쌍이 검사되고, 결국 하나 이상의 동작 가능한 쌍이 세션에 사용되도록 선택되는 단계로 설명합니다.

이것이 ICE의 핵심입니다. 호스트 주소, 반사 주소 또는 릴레이 주소가 작동할 것이라고 가정하는 대신 ICE는 이를 적극적으로 테스트합니다. 일부 쌍은 NAT 필터링이나 방화벽 정책 때문에 즉시 실패합니다. 일부는 작동하지만 릴레이를 포함하기 때문에 덜 선호됩니다. 일부는 빠르게 성공하여 지명될 가능성이 높은 후보가 됩니다. ICE는 이러한 결과를 사용해 정적인 설정 추측이 아니라 가장 실행 가능한 경로로 수렴합니다.

지명과 선택된 후보 쌍

검사가 성공하면 ICE는 선택된 후보 쌍을 고릅니다. 간단히 말해 제어 측이 미디어를 운반할 쌍을 지명하고, 세션은 이후 전송에 그 쌍을 사용하기 시작합니다. 직접 경로가 작동하면 ICE는 보통 릴레이 경로보다 이를 선호합니다. 직접 경로는 대체로 지연 시간과 릴레이 비용을 줄이기 때문입니다. 릴레이만 작동하는 경우에도 ICE는 TURN을 통해 세션을 완료할 수 있습니다.

이 최종 선택 단계가 ICE를 실시간 통신에서 실용적으로 만듭니다. 애플리케이션은 사용자가 어떤 네트워크 인터페이스나 공용 매핑을 사용할지 수동으로 결정하게 할 필요가 없습니다. ICE는 실제 검사 결과를 바탕으로 결정을 내리고, 선택된 경로를 미디어 엔진에 전달하여 통화, 영상 세션 또는 데이터 교환이 진행되도록 합니다.

ICE는 후보를 수집하고, 교환하고, 후보 쌍을 테스트하며, 실제로 성공하는 최적 경로를 선택하는 방식으로 작동합니다.

ICE, STUN, TURN의 관계

STUN이 제공하는 것

STUN은 NAT 통과를 위한 도구 프로토콜이지, 그 자체로 완전한 종단 간 솔루션은 아닙니다. RFC 8489는 STUN을 NAT 통과를 다루는 다른 프로토콜을 위한 도구로 기능하는 프로토콜이라고 설명하며, 엔드포인트가 NAT가 할당한 IP 주소와 포트를 발견하도록 도울 수 있다고 언급합니다. ICE에서 STUN은 후보 수집과 연결성 검사 모두에 사용됩니다.

실무적으로 STUN은 “내 엔드포인트가 로컬 네트워크 외부에서 어떻게 보이는가?”라는 질문에 답하는 데 도움을 줍니다. 그 답은 서버 반사 후보가 됩니다. 많은 경우, NAT 동작이 검사를 통과할 만큼 허용적이라면 이것만으로도 직접 피어 투 피어 경로를 만들 수 있습니다. 하지만 STUN만으로 모든 토폴로지에서 성공을 보장할 수는 없습니다.

TURN이 제공하는 것

TURN은 직접 경로가 불가능할 때의 공백을 메웁니다. RFC 8656은 TURN을 NAT 뒤의 호스트가 중간 노드를 사용해 피어와 패킷을 교환할 수 있게 하는 릴레이 프로토콜로 정의합니다. ICE 관점에서 TURN은 직접 또는 반사 후보 쌍이 실패할 경우 언제든지 대체 경로가 될 수 있는 릴레이 후보를 생성합니다.

TURN은 제한적인 기업 네트워크, 대칭 NAT 환경, 모바일 네트워크 또는 직접 UDP 경로 생성이 불안정한 모든 환경에서 자주 필수적입니다. 단점은 릴레이된 미디어가 일반적으로 지연 시간을 늘리고, 릴레이 대역폭을 소비하며, 인프라 비용을 증가시킨다는 점입니다. 따라서 ICE는 가능하면 직접 연결을 선호하지만, 직접 옵션이 실패했을 때 세션 수립을 신뢰할 수 있게 만드는 것은 TURN입니다.

ICE에 둘 다 필요한 이유

ICE는 STUN과 TURN을 함께 묶는 오케스트레이션 계층입니다. STUN만으로는 발견과 테스트를 제공하고, TURN은 대체 릴레이를 제공합니다. ICE는 이를 어떻게 사용할지 결정합니다. 호스트, 반사, 릴레이 후보를 수집하고, 우선순위를 정하고, 검사를 실행하며, 가장 잘 동작하는 쌍을 지명합니다. 그래서 많은 설명에서 ICE를 단순한 또 하나의 통과 메커니즘이 아니라 NAT 통과의 제어 두뇌라고 부릅니다.

운영 관점에서 잘 운영되는 실시간 플랫폼은 거의 항상 ICE 아래에서 STUN과 TURN을 함께 배포합니다. 이상적인 네트워크 경로가 존재할 것이라고 가정하는 것보다 신뢰성이 더 중요하기 때문입니다. 직접 연결이 선호되는 결과이지만, 릴레이 기반 성공은 통화 실패보다 훨씬 낫습니다.

STUN은 경로를 발견하고 테스트하는 데 도움을 주고, TURN은 직접 경로가 실패할 때 릴레이를 제공하며, ICE는 그중 어떤 옵션이 세션을 운반해야 하는지 결정합니다.

최신 ICE 동작과 Trickle ICE

Trickle ICE가 중요한 이유

기존 ICE는 상당한 후보 집합이 수집될 때까지 기다린 뒤 전체 교환 및 검사 과정을 진행합니다. RFC 8838에 정의된 Trickle ICE는 후보가 사용 가능해지는 즉시 점진적으로 교환할 수 있게 하여 이를 개선합니다. 이 RFC는 후보 수집과 연결성 검사를 병렬로 진행할 수 있게 하며, 이를 통해 세션 수립을 상당히 가속할 수 있다고 설명합니다.

이러한 개선은 사용자 경험에 중요합니다. 모든 후보 수집이 끝나기를 기다린 뒤 검사를 시작하는 대신, 엔드포인트는 초기 후보로 먼저 작업을 시작하고 새 후보가 발견될 때마다 계속 추가할 수 있습니다. 실제로 이는 특히 릴레이 할당이나 다중 인터페이스 발견이 초기 핸드셰이크를 늦추는 상황에서 WebRTC 및 기타 인터랙티브 애플리케이션의 설정 지연을 줄이는 경우가 많습니다.

실패 타이밍과 ICE 견고성

최신 ICE 동작은 RFC 8445 이후에도 개선되었습니다. RFC 8863은 RFC 8445와 RFC 8838을 업데이트하여, 확인할 후보 쌍이 더 이상 남아 있지 않더라도 ICE 에이전트가 ICE 실패를 선언하기 전에 최소한의 시간을 기다리도록 요구합니다. 이 변경은 타이밍 경계 상황에서 너무 이른 실패를 방지하여 견고성을 높입니다.

이 세부 사항은 실제 운영에서 중요합니다. 실제 네트워크는 복잡하고 예측하기 어렵기 때문입니다. 늦게 도착하는 후보, 지연된 시그널링, 순서가 뒤섞인 검사로 인해 타임아웃 로직이 너무 공격적이면 세션이 너무 일찍 실패한 것처럼 보일 수 있습니다. RFC 8863 업데이트는 성공적인 연결 수립에 때로는 약간의 추가 인내가 필요하다는 실무적 교훈을 반영합니다.

ICE의 이점

더 높은 세션 성공률

ICE의 가장 분명한 이점은 신뢰성입니다. 여러 경로 옵션을 수집하고 실제 연결성 검사로 검증함으로써 ICE는 다양한 네트워크에서 통화나 미디어 세션이 성공적으로 연결될 확률을 크게 높입니다. 이는 가정용 광대역, 모바일 접속, 호텔 Wi-Fi, 기업 LAN 및 NAT와 방화벽 동작을 미리 깔끔하게 예측할 수 없는 기타 환경에서 특히 가치가 있습니다.

ICE가 없다면 애플리케이션은 실패할 수 있는 하나의 발표 주소에 의존하거나, 비용이 많이 드는 릴레이 사용으로 너무 빨리 전환하게 됩니다. ICE는 직접, 반사, 릴레이 경로를 우선순위 기반으로 시도하는 구조화된 방법을 제공하여 성공적인 설정 가능성을 높이면서도 가장 효율적인 경로를 추구합니다.

직접 경로가 작동할 때 더 낮은 지연 시간

ICE는 가능한 직접 경로를 릴레이 경로보다 선호하므로, 네트워크가 직접 피어 통신을 허용할 때 낮은 지연 시간과 더 나은 미디어 품질을 유지하는 데 도움이 됩니다. 이는 음성, 영상, 인터랙티브 스트리밍, 클라우드 게임, 원격 협업 및 불필요한 릴레이가 비용과 지연을 추가하는 저지연 실시간 사용 사례에서 중요합니다.

릴레이는 신뢰성을 위해 중요하지만, 성능 측면에서는 일반적으로 직접 전송이 더 좋습니다. ICE는 직접 옵션을 먼저 테스트하고 TURN을 신뢰할 수 있는 대체 경로로 유지함으로써 이 두 목표의 균형을 맞춥니다.

이기종 네트워크 전반의 더 나은 적응성

최신 엔드포인트는 Ethernet, Wi-Fi, VPN 터널, 셀룰러 링크처럼 여러 인터페이스를 갖는 경우가 많습니다. ICE는 이러한 다양한 경로에서 후보를 수집하고, 연결성 검사를 통해 어떤 경로가 실제로 세션에 사용할 수 있는지 드러나게 합니다. 이 때문에 ICE는 고정된 단일 주소 가정보다 훨씬 더 적응력이 높습니다.

이러한 적응성은 클라우드 및 하이브리드 배포에서도 유용합니다. 홈오피스의 브라우저, 통신사 NAT 뒤의 휴대전화, 클라우드의 미디어 서버도 ICE가 네트워크 다양성을 배포 장애물이 아니라 검증된 의사결정 공간으로 바꾸기 때문에 실용적인 경로를 협상할 수 있습니다.

ICE는 저지연 미디어가 최소한의 사용자 개입으로 NAT, 방화벽 및 다중 네트워크 경계를 넘어야 하는 곳에서 널리 사용됩니다.

ICE의 용도와 적용 분야

WebRTC 음성, 영상 및 데이터 채널

ICE의 가장 눈에 띄는 현대적 사용 사례는 WebRTC입니다. 브라우저는 오디오, 비디오, 데이터 채널을 위한 피어 연결을 설정하기 위해 ICE를 사용합니다. MDN의 WebRTC 프로토콜 문서는 ICE를 NAT, 방화벽, 릴레이 필요 가능성에도 불구하고 브라우저가 피어와 연결할 수 있도록 하는 프레임워크라고 설명합니다. 이 때문에 ICE는 브라우저 기반 영상 통화, 음성 채팅, 실시간 협업, 피어 데이터 교환의 핵심입니다.

브라우저 사용자는 매우 다양한 네트워크에서 접속하므로, ICE는 WebRTC가 공용 인터넷에서 대규모로 작동할 수 있는 핵심 이유 중 하나입니다. ICE는 애플리케이션에 연결성을 발견하고 직접 경로가 불가능할 때도 자연스럽게 복구할 수 있는 표준 기반 방식을 제공합니다.

SIP, VoIP 및 통합 커뮤니케이션

ICE는 특히 엔드포인트와 미디어 서버가 NAT 경계를 넘어 통신해야 하는 SIP 기반 음성 및 영상 시스템에서도 사용됩니다. 기업 VoIP에서는 원격 사용자, 지사, 모바일 소프트폰, 클라우드 미디어 서비스가 서로 다른 네트워크 도메인 뒤에 있는 경우가 많습니다. ICE는 이러한 혼합 환경에서 미디어 설정의 신뢰성을 높입니다.

이는 조직이 정적인 일대일 NAT 규칙에 전적으로 의존하지 않고 안전한 원격 통화를 구현하려는 경우 특히 중요합니다. ICE는 엔드포인트가 동적으로 작동 가능한 미디어 경로를 협상하도록 돕기 때문에 현대적인 하이브리드 업무 및 분산 통신 배포에서 가치가 있습니다.

스트리밍 인제스트와 저지연 미디어 워크플로

ICE는 기여 또는 인제스트를 위해 WebRTC 스타일 전송을 사용하는 최신 스트리밍 워크플로에서도 점점 더 중요해지고 있습니다. WebRTC-HTTP Ingestion Protocol인 RFC 9725는 클라이언트와 미디어 서버 간 ICE 및 DTLS 세션을 설정하는 데 SDP offer-answer 교환이 핵심 단계라고 명시합니다. 이는 ICE가 브라우저 대 브라우저 통화를 넘어 실시간 미디어 기여 및 전달 시스템으로 확장됨을 보여 줍니다.

이러한 사용 사례에서도 목표는 동일합니다. 실시간 트래픽에 대해 가능한 가장 효과적인 경로를 설정하는 것입니다. 엔드포인트는 사람이 조작하는 브라우저가 아니라 인코더와 서버일 수 있지만, ICE는 복잡한 네트워크를 통해 경로가 형성되도록 돕는 메커니즘으로 남아 있습니다.

산업, IoT 및 엣지 실시간 시스템

실시간 피어 또는 엣지 통신이 사설 네트워크를 통과해야 하는 곳이라면 ICE가 유용할 수 있습니다. 여기에는 특정 산업용 영상 시스템, 엣지 협업 도구, 원격 측정 세션, 순수한 요청-응답 트래픽이 아니라 인터랙티브 미디어에 의존하는 원격 지원 플랫폼 등이 포함됩니다. ICE의 이점은 산업에만 고유하다는 점이 아니라, 많은 분산 엣지 환경에 공통적인 연결 문제를 해결한다는 데 있습니다.

이러한 시스템이 브라우저 기반 제어, WebRTC 전송 또는 하이브리드 클라우드-엣지 상호작용을 더 많이 통합할수록 ICE는 브라우저 전용 개념이 아니라 통신 스택의 실용적인 구성 요소가 됩니다.

배포 고려 사항

TURN 용량과 지리적 배치

ICE는 직접 경로를 선호하지만, 실제 배포에서는 의미 있는 비율의 세션에 TURN이 필요할 것이라고 가정해야 합니다. 따라서 TURN 용량 계획이 중요합니다. 릴레이 용량이 부족하면 ICE가 릴레이 경로를 식별하더라도 부하 상황에서 미디어 품질이 저하됩니다. 지리적 배치도 중요합니다. 릴레이와의 거리가 지연 시간에 직접 영향을 주기 때문입니다.

따라서 실시간 미디어를 대규모로 배포하는 조직은 TURN을 드물게 사용하는 백업이 아니라 운영 인프라로 다루어야 합니다. 가장 좋은 ICE 설계는 직접 연결이 일반적이면서도, 직접 경로가 차단될 때 장애를 드물게 만들 만큼 릴레이 서비스가 충분히 강한 설계입니다.

관측 가능성과 문제 해결

플랫폼이 단순히 “connection failed” 같은 일반 메시지만 노출한다면 ICE 실패를 진단하기 어렵습니다. 유용한 배포는 후보 유형, 후보 쌍 결과, 릴레이 사용, 타이밍 동작을 기록하여 엔지니어가 시그널링 문제, 연결성 검사 실패, TURN 할당 문제를 구분할 수 있게 합니다. 후보 수준의 가시성은 세션이 직접 성공했는지, 릴레이를 통해 성공했는지, 완전히 실패했는지를 이해하는 데 훨씬 큰 도움을 줍니다.

이는 VPN 클라이언트, 방화벽 정책, 엔드포인트 보안 소프트웨어, 브라우저 차이가 모두 결과에 영향을 줄 수 있는 혼합 기업 환경에서 특히 중요합니다. 좋은 관측 가능성은 ICE를 알 수 없는 백그라운드 메커니즘이 아니라 운영상 관리 가능한 미디어 플랫폼의 일부로 바꿉니다.

보안과 개인정보 보호

ICE 후보 교환은 애플리케이션이 연결을 위해 필요로 하는 네트워크 정보를 드러내므로, 개인정보 처리와 후보 정책이 중요합니다. 최신 브라우저와 플랫폼은 점점 연결성과 개인정보 보호 사이의 균형을 맞추고 있으며, 관리자는 호스트 후보, 릴레이 사용, 로깅 정책이 기업 보안 요구사항과 어떻게 상호작용하는지 이해해야 합니다.

동시에 TURN 자격 증명, 접근 제어, 남용 방지도 신중하게 처리해야 합니다. TURN 서버는 단순한 보조 서비스가 아닙니다. 적절히 보호하고 모니터링하지 않으면 과도하게 소비될 수 있는 리소스이기도 합니다.

운영 환경에서 ICE는 단순한 알고리즘이 아닙니다. 시그널링, 릴레이 용량, 모니터링, 정책 제어를 포함하는 서비스 설계 문제입니다.

FAQ

ICE를 간단히 말하면 무엇인가요?

ICE는 두 엔드포인트가 실시간 미디어 또는 데이터에 사용할 수 있는 경로를 찾도록 돕는 NAT 통과 프레임워크입니다. 가능한 경로를 수집하고, 테스트하고, 가장 좋은 경로를 선택합니다.

ICE가 STUN이나 TURN을 대체하나요?

아닙니다. ICE는 STUN과 TURN을 사용합니다. STUN은 외부에서 보이는 매핑을 발견하고 검사를 수행하는 데 도움을 주며, TURN은 직접 연결이 불가능할 때 릴레이를 제공합니다.

ICE 후보란 무엇인가요?

ICE 후보는 엔드포인트가 통신에 사용할 수 있는 가능한 네트워크 주소와 포트입니다. 일반적인 후보 유형에는 호스트, 서버 반사, 피어 반사, 릴레이 후보가 있습니다.

WebRTC에서 ICE가 중요한 이유는 무엇인가요?

WebRTC 세션에는 NAT, 방화벽, 변화하는 네트워크 뒤에 있는 사용자가 자주 포함됩니다. ICE는 WebRTC가 연결 경로를 발견하고 검증할 수 있는 표준화된 방식을 제공하여 세션이 더 안정적으로 설정되도록 합니다.

Trickle ICE란 무엇인가요?

Trickle ICE는 후보가 발견되는 즉시 점진적으로 교환할 수 있게 하는 확장입니다. 이를 통해 연결성 검사를 더 일찍 시작할 수 있고, 세션 설정이 더 빠르게 완료되는 경우가 많습니다.