1. 시작하며
WebRTC의 첫 개념정리부터 시작하여 하이퍼커넥트의 경우, 해당 아키텍처를 어떻게 구축하였는지 개괄적으로 알아보도록 하자.
2. 용어 정리
webRTC의 동작을 알기 위해선 각각의 용어를 알아야 한다.
[SDP]
SessionDescriptionProtocol의 약자로, 이는 webRTC통신 전, 각 Peer들의 미디어 데이터 교환 방식이 메타 데이터 형태로 정의된 프로토콜을 의미한다. 내부적으로 어떤 코덱을 사용할지, 미디어의 샘플레이트는 어떤지 등이 기술되어 있다.
[NAT 타입]
공인IP와 사설IP를 상호 변환해주는 네트워크 기술
[ICE candidates]
Interactive Connectivity Establishment의 약자이다. Peer들의 상호 연결 설립에 필요한 주소값 데이터를 의미한다. 내부적으로 Peer의 공인IP/포트/NAT 타입 등이 기술되어있다.
[STURN 서버]
ICE candidates정보를 추출해주는 역할
[TURN 서버]
1. STURN서버가 ICE candidates추출 실패 시, 대신 추출해준다.
2. SDP세션, ICE candidates를 Peer들간 교환이 성공적이었음에도 불구, P2P연결 실패 시 중개를 하여 Peer들끼리 연결해주는 서버
[SIGNALING 서버]
Peer들은 연결되기 전, 사전 준비 단계를 거친다.
1. Offer/Answer단계 : SDP세션을 상호 교환함으로써 미디어 데이터 교환 방식을 상대 Peer에게 알림
2. ICE candidates 교환 단계 : TURN/STURN서버로부터 Peer의 네트워크 주소 정보를 받아 Peer들간의 교환을 진행
3. 기본 동작 구조
위 이미지를 통해 webRTC의 연결 방식을 개략적으로 알 수 있다 생각한다.
1. SDP 세션 정보 교환
첫 번째로, 연결을 희망하는 Peer의 Offer단계이다. 이 단계에선 해당 Peer의 SDP세션 정보를 Signal서버로 전송한다. 해당 서버는 이를 다른 Peer로 전달한다. 그 후, Peer2는 Answer단계를 수행하여 자신의 SDP세션 정보를 응답해준다. 이를 통해 Peer1과 Peer2는 어떠한 형태의 미디어 데이터를 어떠한 프로토콜로 어떠한 인코딩/디코딩 방식으로 주고받을지 약속할 수 있게된다.
2. ICE Candidates 주소 정보 교환
STURN서버로부터 ICE Candidates데이터를 요청한다. 하지만 만약 실패할 수도 있는데, 이럴 경우, TURN서버로부터 해당 정보를 요청한다. STURN서버든, TURN서버든, ICE Candidates데이터를 수신받았을 경우 이를 각각의 Peer들에게 응답해준다. 그 후, 각 Peer들은 해당 데이터를 상호 교환할 필요가 있는데, 이를 위해 Signal서버를 통해 교환하게 된다. 이를 통해 각 Peer들은 상대방 Peer의 공인IP/포트/NAT 타입 등을 알게 됨으로써, 네트워크 상 어떻게 찾아가야할지를 알 수 있게된다.
3. Connection
SDP세션 정보와 ICE Candidates주소 정보 교환을 통해 두 Peer들은 미디어 통신 방식에 대해 알게되었으며, 상대방 Peer를 어떻게 찾아가야할지를 알게되었다. 이제 연결 단계만 남았다. 첫 번째로 두 Peer간 직접 연결을 시도할 수 있다. 이 연결은 주로 1:1 연결시에 쓰이며 중계서버가 없다. 하지만 실패하거나, 1:N 또는 N:N연결을 위해 TURN서버를 경유하여 릴레이 연결을 할 수 있다.
4. 하이퍼커넥트의 라이브 스트리밍 미디어 서버
하이퍼커넥트는 크게 미디어 서버를 2가지가 존재한다고 추측한다. 한 개는 1 : N 방식으로 단방향으로 방송을 송출하는 '라이브 스트리밍 미디어 서버'이다. 또 다른 1개는 N : N 방식으로 양방향으로 소통하는 그룹콜 미디어 서버이다.
문제1. 사용자 리소스 낭비
- 1:N 방송을 위해 1명의 호스트를 중심으로, 중계서버 없이 다른 시청자들과 직접 연결
- 호스트와 사용자의 직접 연결로, 지연시간이 가장 짧음
- 시청자 수에 비례한 호스트의 부하 증가(배터리 소모, 데이터 낭비)
- 추가적인 아키텍처 고안 필요
- 미디어 서버(=TURN서버)추가 및 시그널 서버와의 통합
- 호스트의 수신Peer 연결 : 호스트는 수신Peer에 미디어를 전송하며 이를 송신Peer에 전달
- 시청자의 송신Peer 연결 : 시청자는 송신Peer를 통해 미디어 수신
- 최종적으로 호스트의 리소스 부하 해결
- 하지만 대규모 시청자 수용 불가 문제로 서버의 수평확장 필요
문제2. 대규모 시청자 수용 불가
- 수평확장은 진행
- 한계점
- 송신Peer(=시청자)의 위치는 수신Peer(=호스트)가 있는 미디어 서버에서 만들어져야만 함
- 1개의 미디어 서버 내, 송신Peer 생성 상한선 존재(=대규모 시청자 수용 불가)
- 송신Peer의 존재 위치 자유도 재고 필요
- Origin-Edge구조 설계
- 수신Peer와 송신Peer는 다른 미디어 서버에 존재 가능
- 호스트는 Origin서버로, 시청자는 Edge서버로 항상 Peer를 생성
- 송신Peer의 생성 위치가 자유로워짐에 대규모 시청자 수용 가능
- 글로벌 서비스화에 따른 네트워크 문제 발생.
문제3. 국가적 네트워크 지연
- 호스트와 시청자는 각각 자국 미디어 서버를 이용
- 미국 시청자가 한국 호스트의 방송 참여 시, 자국의 서버 및 네트워크를 이용하므로 지연시간이 줄어듦
참고
