브라우저 간 직접 통신을 위한 WebRTC P2P 데이터 전송 아키텍처
WebRTC는 ICE로 직접経路와 TURN 릴레이를 선택하며, 데이터 채널과 미디어 전송은 서로 다른 신뢰성 요구에 맞게 구성됩니다.
발행·오류 제보: infostoa · 편집 기준
이 글의 개별 작성자와 전문 검토자 정보는 제공되지 않습니다.
WebRTC 연결 수립과 ICE 후보 선택
WebRTC는 브라우저와 다른 WebRTC 단말 사이의 실시간 미디어·데이터 통신 API와 프로토콜 집합입니다. W3C는 브라우저 API를, IETF는 여러 전송 프로토콜을 표준화합니다. 응용프로그램은 별도 시그널링 경로로 SDP 제안·응답과 ICE 후보 정보를 교환해야 합니다. WebRTC 규격은 그 시그널링 서버나 전송 방식을 정하지 않습니다.
ICE는 로컬·서버 반사·릴레이 후보를 모아 연결 검사를 하고 사용할 경로를 고릅니다. STUN은 NAT가 외부에 보이는 주소를 알아내는 데 도움을 주며, TURN은 직접 경로가 성립하지 않을 때 트래픽을 중계합니다. 따라서 연결이 항상 순수 P2P인 것은 아니며, TURN 사용 시 서버 대역폭과 지연이 추가됩니다. 직접 연결의 비용·지연 이점도 네트워크와 배치 조건에 따라 달라집니다.
전문가 관점: P2P는 가능한 경로이지 고정 토폴로지가 아님
WebRTC for the Curious는 WebRTC 구현자들이 함께 쓴 공개 기술서로, ICE가 직접 연결을 시도하면서 필요한 경우 TURN 릴레이도 선택하는 구조를 설명합니다. 따라서 WebRTC가 항상 서버를 우회하거나 RTT·대역폭 비용을 줄인다고 말할 수 없습니다. 직접 연결 여부는 양 끝의 NAT, 방화벽, UDP 접근성, ICE 정책에 달려 있습니다. 다자간 영상에서는 각 단말의 업로드와 인코딩 부담을 고려해 SFU를 둘 수 있지만, 이는 제품의 지연·품질·비용 요구에 따른 아키텍처 선택입니다.
데이터 채널과 미디어의 보장 범위
WebRTC 미디어 전송은 ICE가 선택한 경로에서 SRTP/SRTCP를 사용하며, 혼잡 제어·손실 복구 동작은 미디어 스택과 협상된 기능에 따라 달라집니다. “손실 패킷은 재전송하지 않고 최신 프레임만 렌더링한다”는 보편 규칙은 아닙니다. RTCDataChannel은 DTLS로 보호되는 SCTP 기반 채널이며, 순서 및 재전송 동작은 채널의 ordered, maxRetransmits, maxPacketLifeTime 설정으로 달라집니다. 신뢰성 옵션은 전송 계층의 동작을 정할 뿐, 연결 장애를 넘어서는 애플리케이션 수준의 무손실 전달·저장을 약속하지 않습니다.