도구스개발

WebRTC ICE 후보 우선순위 계산기

RFC 8445가 정한 공식으로 ICE(Interactive Connectivity Establishment) 후보의 우선순위 정수를 계산합니다. host·server-reflexive·relayed 후보 중 왜 항상 host가 먼저 선택되는지 자릿수 구조로 보여 줍니다.

고르면 RFC 권장 type-preference로 채워집니다. 아래에서 직접 바꿀 수 있습니다

RTP=1, RTCP=2

우선순위 (priority)

2,130,706,431

값이 클수록 먼저 시도됩니다

type-preference 항 (2²⁴×)2,113,929,216
local-preference 항 (2⁸×)16,776,960
component-id 항 (256−id)255
합계2,130,706,431

priority = 2²⁴×type-preference + 2⁸×local-preference + (256−component-id)입니다. 세 항이 자릿수로 완전히 분리돼 있어 type-preference가 1만 높아도 local-preference를 최댓값(65535)까지 채운 다른 후보를 항상 앞섭니다.

host 후보가 항상 relayed보다 먼저 시도되는 이유가 이 공식에 있습니다.
type-preference에 2²⁴(약 1,677만)을 곱하기 때문에, host(126)의 type 항만으로도 relayed(0)가 local-preference를 최댓값까지 채운 값보다 훨씬 큽니다. 사설망에서 직접 붙는 경로가 TURN 중계보다 빠르고 저렴하니 항상 먼저 시도하도록 설계된 것입니다.

사용 방법

  1. 1후보 종류(host·peer-reflexive·server-reflexive·relayed)를 고르면 RFC 권장 type-preference가 채워집니다. 직접 바꿀 수도 있습니다.
  2. 2local-preference(같은 종류 후보가 여럿일 때의 순위)와 component-id(RTP=1, RTCP=2)를 입력합니다.
  3. 3계산된 우선순위 정수와, 세 항이 각각 얼마나 기여하는지 자릿수별로 확인합니다.

자주 묻는 질문

RFC 8445 §5.1.2.1의 공식 priority = 2^24×type-preference + 2^8×local-preference + 2^0×(256−component-id)로 계산합니다. 세 항이 24비트·8비트·8비트로 자릿수가 완전히 분리돼 있어 상위 항(type-preference)이 하위 항(local-preference)을 절대 뒤집지 못합니다.

type-preference가 2^24를 곱해 최상위 자릿수를 차지하기 때문입니다. host(126)의 type항만으로도 2,113,929,216이 되는데, relayed(0)는 local-preference를 최댓값 65535로 채워도 local항이 16,776,960에 그쳐 host의 type항 근처에도 못 미칩니다. 사설망에서 직접 붙는 경로가 TURN 중계보다 빠르고 저렴하니 항상 먼저 시도하도록 설계된 것입니다.

공식이 (256−component-id)로 빼는 형태라 그렇습니다. RTP(component-id=1)가 255, RTCP(component-id=2)가 254가 되어 RTP 쪽이 1만큼 높습니다. 미디어 스트림 본체인 RTP를 제어 채널인 RTCP보다 우선하려는 의도입니다.

RFC의 권장값일 뿐 강제는 아닙니다. 0~126 사이에서 자유롭게 정할 수 있지만, 같은 에이전트가 보내는 같은 종류의 모든 후보에는 동일한 값을 써야 하고, host > peer-reflexive > server-reflexive > relayed 순서는 지키는 것이 상호운용성 관례입니다.

전송되지 않습니다. 계산은 모두 브라우저 안에서 이루어지고 넣은 값은 이 기기에만 남습니다.

알아두면 좋은 점

  • 이 계산기는 RFC 8445가 정의한 후보 우선순위 정수 하나만 계산합니다. 실제 연결에 쓰이는 후보쌍(candidate pair) 우선순위나 ICE 상태 전이(checking·connected 등)는 다루지 않습니다.
  • type-preference·local-preference는 브라우저나 라이브러리(WebRTC 구현체)가 내부적으로 정하는 값으로, 애플리케이션 코드에서 직접 지정할 수 없는 경우가 대부분입니다. 이 계산기는 SDP에 이미 적힌 candidate 줄의 우선순위 값을 검산하거나 원리를 이해하는 용도입니다.

함께 보면 좋은 도구

핸드셰이크 지연RTT(왕복시간)와 TLS 버전·재개 여부로 연결 수립에 걸리는 왕복 횟수와 지연시간을 계산합니다.프리플라이트 판정메서드·Content-Type·직접 추가한 헤더를 넣으면 브라우저가 CORS 프리플라이트(OPTIONS) 요청을 먼저 보낼지 판정합니다.gRPC 상태 코드gRPC 상태 코드(0~16)의 뜻과 언제 나는지 찾아봅니다.gitignore 판정.gitignore 규칙과 경로를 넣으면 그 파일이 무시되는지, 어느 줄이 마지막으로 이겼는지 알려줍니다.울프람 규칙규칙 번호 0~255를 8비트로 풀어 세 칸 이웃에 대응시키고 세대를 쌓아 무늬를 그립니다.

마지막 검증: 2026년 9월 7일 · 결과는 참고용 추정치입니다.