RTCPeerConnection 개요
RTCPeerConnection은 WebRTC(Web Real-Time Communication)의 핵심 구성 요소 중 하나로, 웹 브라우저 간의 실시간 미디어 스트림(예: 비디오, 오디오)과 데이터 채널을 설정하고 관리하기 위한 API를 제공한다. WebRTC의 전반적인 목적이 웹 브라우저 간의 P2P 통신을 가능하게 하는 것이라면, RTCPeerConnection은 이러한 P2P 연결을 실질적으로 구성하고 관리하는 역할을 수행한다. RTCPeerConnection은 WebRTC의 실제 네트워크 통신 부분을 담당하며, 다양한 네트워크 조건에서 최적의 연결을 유지하기 위해 복잡한 시그널링과 네트워크 처리를 포함하고 있다.
RTCPeerConnection의 구조와 구성 요소
RTCPeerConnection은 여러 구성 요소와 하위 시스템으로 이루어져 있으며, 이들은 각기 다른 역할을 통해 P2P 연결의 설정과 관리를 담당한다.
ICE (Interactive Connectivity Establishment)
RTCPeerConnection의 가장 중요한 기능 중 하나는 다양한 네트워크 환경에서 연결을 설정할 수 있도록 하는 ICE(Interactive Connectivity Establishment) 프로토콜의 구현이다. ICE는 NAT(Network Address Translation) 및 방화벽을 우회하여 두 피어 간의 연결을 설정하는 데 필요한 방법을 제공한다.
-
Candidate Gathering: ICE는 로컬, 서버 기반(STUN/TURN 서버를 통한) 및 피어 연결 후보군을 수집한다. 이 후보들은 다양한 네트워크 경로를 통해 연결을 시도할 수 있게 한다.
-
Connectivity Checks: 수집된 후보군을 사용하여 실제로 연결 가능한 경로를 찾기 위한 연결성 테스트를 수행한다. 이 과정에서 최적의 경로가 선택된다.
-
ICE Candidate: ICE Candidate는 피어 간의 연결을 설정하기 위한 네트워크 경로의 정보이다. RTCPeerConnection은 이들을 수집하고 테스트하여 최적의 경로를 결정한다.
SDP (Session Description Protocol)
SDP(Session Description Protocol)는 멀티미디어 통신 세션의 매개변수를 기술하기 위한 프로토콜이다. RTCPeerConnection에서 SDP는 피어 간의 연결을 설정하기 위해 필수적으로 사용되며, 미디어 스트림의 형식, 코덱, 네트워크 정보 등이 포함된다.
-
SDP Offer/Answer 모델: RTCPeerConnection은 "Offer/Answer" 모델을 통해 두 피어 간의 협상 과정을 진행한다. 한 피어가 연결을 제안하면(Offer), 다른 피어가 이에 대한 응답을 제공한다(Answer). 이 과정에서 각 피어는 연결할 미디어 스트림의 형식과 조건을 협상하게 된다.
-
Codec Negotiation: SDP를 통해 서로 사용할 코덱을 협상하게 된다. 이는 두 피어가 동일한 코덱으로 미디어를 전송하고 수신할 수 있도록 보장한다.
Signaling
RTCPeerConnection은 피어 간의 직접적인 통신을 설정하기 전에 시그널링(Signaling) 과정을 필요로 한다. 이 시그널링은 보통 WebSocket이나 다른 커뮤니케이션 채널을 통해 이루어지며, 시그널링 서버는 RTCPeerConnection이 서로의 네트워크 상태를 교환하고, ICE 후보군을 공유하며, SDP 오퍼와 응답을 주고받을 수 있도록 돕는다.
-
Signaling Server의 역할: 시그널링 서버는 피어 간의 초기 통신을 중계하고, 필요한 정보를 교환하는 중간 단계에서 중요한 역할을 한다. RTCPeerConnection 자체는 시그널링 방법이나 서버 구현에 대해 관여하지 않지만, 시그널링이 없으면 P2P 연결을 설정할 수 없다.
-
Signal Exchange: 시그널링 서버를 통해 피어들은 서로의 SDP와 ICE 후보를 교환한다. 이 정보가 성공적으로 교환되면, 피어 간의 직접적인 P2P 연결이 가능해진다.
RTCPeerConnection의 데이터 흐름과 제어
RTCPeerConnection은 실제 미디어 스트림과 데이터 채널을 관리하고 제어하는 중요한 역할을 한다. 여기에는 미디어 전송의 시작과 중지, 대역폭 관리, 오류 처리 등이 포함된다.
Media Streams 관리
RTCPeerConnection은 비디오 및 오디오 스트림을 전송하고 수신할 수 있다. 각 미디어 스트림은 트랙(track)으로 구성되며, 이러한 트랙들은 각각 개별적으로 제어될 수 있다.
-
AddTrack와 RemoveTrack: RTCPeerConnection은 addTrack과 removeTrack 메서드를 통해 미디어 스트림을 추가하거나 제거할 수 있다. 이를 통해 연결된 피어에게 전송되는 미디어를 동적으로 변경할 수 있다.
-
Bandwidth Management: RTCPeerConnection은 사용 가능한 네트워크 대역폭을 모니터링하고 관리하여, 스트림의 품질을 최적화한다. 이를 통해 네트워크 상태에 따라 적절한 품질로 미디어를 전송할 수 있게 된다.
DataChannel 관리
RTCPeerConnection은 미디어 스트림뿐만 아니라, 데이터 채널을 통해 일반적인 데이터(텍스트, 바이너리 데이터 등)를 전송할 수 있다.
-
DataChannel 생성: createDataChannel 메서드를 통해 데이터 채널을 생성할 수 있다. 이 채널은 전이중 방식으로 운영되며, 낮은 지연과 높은 신뢰성을 보장한다.
-
Message Handling: 데이터 채널은 메시지 기반으로 운영되며, onmessage 이벤트를 통해 수신된 메시지를 처리할 수 있다.
연결 상태 모니터링과 오류 처리
RTCPeerConnection은 연결 상태를 지속적으로 모니터링하며, 필요한 경우 연결 상태를 재조정하거나 재협상할 수 있는 기능을 제공한다.
-
Connection State: RTCPeerConnection은 다양한 연결 상태를 관리한다. 연결 상태가 변화할 때마다 oniceconnectionstatechange 이벤트가 발생하며, 이를 통해 개발자는 연결 상태를 모니터링하고 대응할 수 있다.
-
Error Handling: 연결 과정에서 발생할 수 있는 다양한 오류를 처리하기 위한 메커니즘을 제공한다. 예를 들어, ICE 연결 실패, 시그널링 오류 등이 있을 수 있다. 이러한 오류는 연결의 재시도 또는 재협상을 통해 해결될 수 있다.
RTCPeerConnection의 최적화 기법
RTCPeerConnection의 성능은 연결 안정성과 효율성에 직접적인 영향을 미치므로, 다양한 최적화 기법이 적용된다.
Connection Time Optimization
연결 설정 시간을 최소화하기 위한 여러 가지 최적화 기법이 있다. 예를 들어, ICE 후보 수집을 비동기적으로 수행하거나, 초기 연결에서 우선적으로 사용할 후보군을 미리 결정하는 방식 등이 있다.
Bandwidth Adaptation
대역폭 적응 기법은 네트워크 조건에 따라 실시간으로 전송 속도와 스트림 품질을 조정하는 것을 의미한다. 이를 통해 끊김 없는 미디어 전송이 가능해진다.
Codec Selection and Adaptation
코덱 선택은 미디어 전송 품질에 중요한 요소이다. RTCPeerConnection은 사용 가능한 코덱 목록을 기반으로 최적의 코덱을 선택하고, 필요 시 동적으로 코덱을 전환할 수 있다.
관련 자료: - WebRTC 1.0: Real-time Communication Between Browsers, W3C, https://www.w3.org/TR/webrtc/ - Justin Uberti, Cullen Jennings, Eric Rescorla, WebRTC API: Real-Time Communication for the Open Web, Google Developers, https://developers.google.com/web/updates/2018/12/webrtc - Philipp Hancke, Demystifying WebRTC's RTCPeerConnection, webrtchacks.com, https://webrtchacks.com/sdp-anatomy/