싸피 1학기 공통프로젝트 주제로 WebRTC를 이용한...을 선택하게 되었다. 프로젝트를 진행하기 앞서 WebRTC의 동작방식에 대해 이해하며 어떤 서비스를 만들 수 있을지 생각하는 시간을 가지려 한다.
WebRTC(Web Real-Time Communication)은 웹 애플리케이션과 사이트가 중간자 없이 브라우저 간에 오디오나 영상 미디어를 포착하고 마음대로 스트림 할 뿐 아니라, 임의의 데이터도 교환할 수 있도록 하는 기술입니다.
websocket으로 채팅프로그램을 만들면 pub-sub 방식으로 소통하기에 중개서버의 역할이 중요하다.하지만 WebRTC의 경우 서버와 같은 중간자를 거치지 않고 브라우저 간을 P2P로 연결하는 기술이다. 1) P2P연결은 중개 서버를 거치지 않기에 빠른 속도가 보장되며, 2) HTTPS가 강제되기 때문에 중간자 공격에 대한 보안이 보장된다. 그리고 3) 실시간으로 상호작용 할 수 있다는 특성을 바탕으로 더욱 개인화 되고 참여 유도적인 웹 어플리케이션을 제작할 기회가 되기도 한다.
WebRTC 커넥션을 우선 만들어야 하고 이를 위한 signaling server 구축이 선행되어야 하기 때문에 시그널링 서버 자체를 구축하는 방법을 중점적으로 자료를 찾아보았다.
시그널링
RTCPeerConnection 통신에 사용할 프로토콜, 채널, 미디어 코덱 및 형식, 데이터 전송 방법, 라우팅 정보와 NAT통과 방법을 포함한 통신 규격을 교환하기 위해 두 장치의 제어 정보를 교환하는 과정까지 시그널링 이라고 부른다.
시그널링은 WebRTC자체에서 지원하는 기능은 아니다. WebRTC 를 사용하기 전에 미리 준비해야하는 과정이다. 일반적으로 두 개의 장치를 연결할 수 있는 시그널링 서버를 직접 구축하거나, 시그널링 서버를 제공해주는 외부 솔루션을 적용할 수 있다.
P2P 방식의 커뮤니케이션
- 각 브라우저가 P2P 커뮤니테이션에 동의
- 서로의 주소를 공유
- 보안 사항 및 방화벽 우회
- 멀티미디어 데이터를 실시간으로 교환
여기서 2,3 단계는 웹브라우저에서는 해결하기 어렵다. 따라서 P2P기반이긴 하지만 통신 초기 단계에서 중재자의 역할을 필요로 한다.
SDP
SDP(Session Description Protocol)은 WebRTC에서 스트리밍 미디어의 해상도나 형식, 코덱 등의 멀티미디어 컨텐츠의 초기 인수를 설명하기 위해 채택한 프로토콜이다. 예를 들어 화상통화시 웹캠 비디오의 해상도를 보낼 수 있고, 오디오 전송 또는 수신 여부를 보낼 수 있다.
SDP 기반의 Offer와 Answer 메시지를 주고 받는 과정
- Alice 가 SDP 형태의 Offer 메시지를 생성한다.
- Alice가 생성된 Offer 메시지를 본인의 LocalDescription으로 등록한다.
- Alice가 Offer메시지를 시그널링 서버에게 전달한다.
- 시그널링서버는 상대방 Bob을 찾아서 SDP 정보를 전달한다.
- Bob은 전달받은 Offer메시지를 본인의 RemoteDecsription에 등록한다.
- Bob은 Answer 메시지를 생성한다.
- 생성된 Answer 메시지를 본인의 LocalDescription으로 등록한다.
- Bob은 Answer 메시지를 시그널링서버에게 전달한다.
- 시그널링서버는 상대방 Alice를 찾아서 Answer 메시지를 전달한다.
- Alice는 전달받은 Anser 메시지를 본인의 RemoteDescription에 등록한다.
현 시점에서 두 피어들은 이 call에 대해 어떤 코덱들과 어떤 video
parameter들이 사용될지 알게 된다. 하지만, 그들은 여전히 미디어 데이터 자체를 전송하는 방법을 모른다. 여기서 Interactive Connectivity Establishment (ICE)가 사용된다.
ICE Candidate
각 피어들의 ICE layer에서 candidate들을 교환하는 과정
각 피어들은 candidate 들을 전송하고, 준비가 되면 받은 candidate 들을 처리한다. Candidate들은 양 피어들이 동의할 때까지 계속 교환되며, 미디어가 송수신 되도록 만든다. 올바르게 작동할 경우, 각 피어들은 모두 소진되거나 서로 동의할 때까지 상대방에게 제안할 candidate 들을 계속 전송한다.
(만약 조건들이 바뀐다면, 예를들어 네트워크 커넥션이 악화되면, 하나 혹은 양 피어들은 낮은 bandwidth의 미디어 해상도로 바꾸거나 다른 코덱을 사용하자고 제안할 것이다. 다음 candidate 교환에서 양 피어 모두 새로운 포맷에 동의한다면, 다른 미디어 포맷 혹은 다른 코덱으로 바뀔 수도 있음.)
STUN,TURN
STUN 방식은 단말이 자신의 공인 IP주소, 포트 를 확인하는 과정에 대한 프로토콜이다.즉 인터넷의 복잡한 주소들 속에서 유일하게 자기 자신을 식별할 수 있는 정보를 반환해 준다.
WebRTC연결을 시작하기 전에 STUN 서버를 향해 요청을 보내고, STUN서버는 NAT뒤에 있는 피어(Peer)들이 서로 연결할 수 있도록 공인IP 와 포트를 찾아준다.
여기까지 하면, 두개의 장치가 P2P연결을 시도할 수 있는 고유한 주소를 알아냈다는 것이고 2단계를 해결한 것이다.
하지만 STUN 서버 만으로 항상 자신의 정보를 알아내는 것은 어려울 수 도 있다.이럴 경우에 대안책으로 이용되는게 TURN 서버 이다.
TURN 방식은 네트워크 미디어를 중개하는 서버를 이용하는 것이다. 중간에 서버를 한 번 거치기 때문에, P2P 통신이 아니게 되며 그 구조상 지연이 필연적으로 발생하게 된다. 하지만 보안 정책이 엄격한 개인 NAT 내부에 위치한 브라우저와 P2P통신을 할 수 있는 유일한 방법이기 때문에 최후의 수단으로 사용된다고 한다.
WebRCT 활용 사례
https://engineering.fb.com/2020/12/21/video-engineering/rsys/ (meta)
https://tech.kakaoenterprise.com/101 (카카오 워크)
참고자료
https://webrtc.org/ (공식문서)
https://www.baeldung.com/webrtc(springboot 를 활용하여 시그널링 서버 구축 과정)
