<div id="readability-page-1" class="page"><section>
 
 <img alt="썸네일" title="썸네일" src="https://juneyr.dev/static/3de2c7e96ffe2eb9230250f023e54e6c/96791/thumb.png" sizes="(max-width: 482px) 100vw, 482px" loading="lazy">
 
WebRTC 를 공부하기로한다. <h2>WebRTC가 뭔데 - 이름 그리고 비전</h2>webRTC는 plugin-free web - Real Time Communication 이다. 그러니까 별도의 플러그인 설치없이 실시간 소통(비디오, 오디오) 이 가능하도록 만들어주는 기술. 기존에는 내가 영상통화를 하고 싶으면 디스코드, 스카이프, 구글 행아웃을 설치하는 과정이 필요했는데, webRTC를 사용하면 크롬 / 오페라 / 사파리 브라우저에서 바로 실시간 소통을 사용해볼 수 있다. <a href="http://appr.tc/">appr.tc</a> 에서 테스트 가능! WebRTC는 구글이 VoIP 회사인 GIPS 를 인수한 후, 해당 회사의 음성 / 영상 코덱 및 에코캔슬링 기술을 갖게 되었다. 이 기술을 WebRTC라는 이름으로 공개한 케이스다. 이게 2011년.기본적으로는 P2P (Peer to Peer), 즉 두 단말이 서로 1:1 통신을 하게 되어있다. 따라서 대규모 방송 서비스를 구축하거나 컨텐츠 가공이 필요할 경우에는 중앙 서버를 구축할 필요성이 생긴다. 이런 경우 목적에 따라 두가지 아키텍처를 고려해볼 수 있다. 그것이 바로 SFU와 MCU인데, 이는 아래에서 다루도록 한다. 🙂<h2>어떻게 되어있는 거야</h2>생각해보면, 두 기기가 실시간 소통을 하기 위해서는 다음과 같은 사항이 필요하다. <ol><li>기기의 스트리밍 오디오 / 비디오 / 데이터를 가져올 수 있을 것 </li><li>소통하고자 하는 기기의 IP 주소와 포트 등 네트워크 데이터가 필요하다</li><li>에러의 보고, 세션의 초기화를 위한 신호 통신을 관리해야한다 </li><li>서로 소통할 수 있는 해상도인지, 코덱은 맞는지 등 capability 정보를 교환해야한다 </li><li>실제로 연결을 맺는다</li><li>그 이후에 스트리밍 오디오 / 비디오 / 데이터를 주고 받을 수 있어야한다.</li></ol>이를 위해서 WebRTC 는 API 를 제공하는데 <ul><li>MediaStream : 사용자의 카메라 혹은 마이크 등 input 기기의 데이터 스트림에 접근한다.</li><li>RTCPeerConnection: 암호화/ 대역폭 관리 기능. 오디오 / 비디오 연결을 한다.</li><li>RTCDataChannel: 일반적인 데이터 P2P 통신</li></ul>이는 위 사항의 일부만 만족시킨다. 나머지 자잘한 일들은 Signaling 이라는 과정을 통해 관리한다. 즉, 크게 보면 WebRTC를 사용한 통신은 두 덩이라고 할 수 있다.<ol><li>Signaling을 통해 통신할 peer 간 정보를 교환한다. 네트워크 정보, capability 정보, 세션 수립 등.</li><li>WebRTC를 사용해 연결을 맺고, peer 의 기기에서 미디어를 가져와 교환한다. </li></ol>이제 다 된 거나 다름없다. 🙂<h2>WebRTC가 해주지 않는 것 : Signaling</h2>Signaling은 통신을 조율할 메시지를 주고 받는 일련의 과정을 의미한다. Signaling을 위한 구체적인 구현 방법과 프로토콜은 WebRTC에 명세되어 있지 않기 때문에, 개발자들이 편한 방식을 선택해야 한다. 예를 들어 <a href="http://appr.tc/">appr.tc</a> 에서는 XHR과 Channel API를 사용해 Signaling을 구현했고, 구글 코드랩에서는 Node 서버 위에 <a href="http://socket.io/">socket.io</a> 를 사용해서 만들었다. 그래서 이게 하는 역할이 뭐냐고 물으면, <ul><li>Session control messages: 통신의 초기화, 종료, 그리고 에러 리포트</li><li>Network configuration : 외부에서 보는 내 컴퓨터의 IP 주소와 포트는 뭐지?</li><li>Media capabilites : 내 브라우저와 상대 브라우저가 사용 가능한 코덱, 그리고 해상도는 뭐지?'</li></ul>이 작업은 스트리밍이 시작되기 전에 완료되어야만 한다. 구체적으로 내용을 좀더 살펴보자. 👽<ol><li>네트워크 정보 교환 Network configuration<ul><li>ICE 프레임워크를 사용해서 서로의 IP 와 포트를 찾는 과정</li><li><code>candidate</code> 에 서로를 추가</li></ul></li><li>미디어 정보 교환 Media Capabilities<ul><li>미디어 정보 교환은 offer 와 answer 로직으로 진행</li><li>형식은 SDP(Session Description Protocol, 엄청 간단한 형식이다)</li></ul></li></ol>그리고 위에서 말한 Session Control messages는 위 과정에서 필요한 마이너한 과정들을 채워준다. Signaling 을 성공적으로 잘 마치고 나면, 실제 데이터(= 미디어, 영상이든 음성이든)는 Peer To Peer (불가능한 경우 중계서버를 거쳐서) 로 통신하게 된다.<h2>잠깐만 ! 여기서 서버 역할</h2>WebRTC에서 서버! 라고 하면 단순히 P2P에 왜 서버가 필요해? 그냥 클라이언트(=peer, 기기, 종단) 끼리 연결하면 되잖아? 하는 생각을 할 수 있다. 하지만 P2P로만 WebRTC 연결을 한다고 해도 서버가 필요한 경우가 있다. 이 기술에서 서버는 다음과 같은 역할을 한다.<ul><li>사용자 탐색과 통신 / Signaling</li><li>NAT / 방화벽 탐색</li><li>Peer to Peer 통신 서버 시 중계서버</li></ul><blockquote>NAT(Network Address Translation) 은 기기에 공인 IP를 부여하는 기술이다. 라우터에 설정하는데, 라우터는 공인 IP 를 갖고, 라우터에 연결된 모든 기기는 사설 IP 를 갖는다. 기기가 요청할 것이 생기면, 라우터의 고유한 포트를 사용해서 사설 IP 에서 공인 IP 로 변환한다(translation). 어떤 라우터는 접근할 수 있는 노드를 제한 할 수 있다.</blockquote>ICE 프레임워크가 등장한다. ICE 프레임워크는 기기를 발견하고 연결하기 위한 프레임워크이다.<ol><li>ICE는 UDP 를 통해 기기들을 서로 직접 연결시도한다.<ol><li>🙂 예이! 연결이 되었습니다. 이제 미디어를 교환합시다. </li><li>😡 왜 연결이 안되지? NAT 혹은 방화벽 뒤에 있나봅니다. </li></ol></li><li>기기가 NAT 뒤에 있다. STUN 서버가 이를 해결해 줄 수 있겠다.<ul><li>STUN (Session Traversal Utilities for NAT) 는 기기의 공인 IP 를 알려준다. 기기의 NAT가 직접 연결을 허용하는지, 아닌지 파악하는 역할도 한다.</li><li>클라이언트는 STUN 서버에 요청을 보낸다. STUN 서버는 클라이언트의 공인 주소와, 클라이언트가 NAT 뒤에서 접근이 되는지 알려준다.</li><li>그 이후에 직접 다른 기기와 통신한다.<ol><li>🙂 예이! 연결이 되었습니다. 이제 미디어를 교환합시다. </li><li>😡 왜 연결이 안되지? TURN 서버가 나설 때 입니다. </li></ol></li></ul></li><li>어떤 라우터는 <code>Symmetric NAT</code> 를 적용한다. Symmetric NAT : 목적지에 따라서 <code>같은 private IP 의 노드</code>를 <code>다른 공인 IP 와 포트</code>로 매핑해준다. 이런 경우 라우터는 이전에 연결했던 기기에서의 연결만 허용한다. <ul><li>TURN ( Traversal Using Relays around NAT) 는 Symmetric NAT 의 제약조건을 우회하기 위해서 만들어졌다. TURN 서버와 연결을 맺고, 이 서버가 모든 교환 과정을 중개해준다. 모든 기기는 TURN 서버로 패킷을 보내고, 서버가 이를 포워딩한다. 당연히, 오버헤드가 있고 =) 다른 대안이 없을 때만 사용한다.</li></ul></li></ol><h2>이제 우리 정말 데이터 교환하자 😨 WebRTC 부분</h2>RTCPeerConnection 은 당사자들 간 데이터를 안정적이고 효율적으로 통신하게 해주는 요소다. 아래 그림에서 초록색 부분은, 원래라면 개발자가 처리해야 부분이다.
 
 <img alt="WebRTC/Untitled.png" title="WebRTC/Untitled.png" src="https://juneyr.dev/static/4d6ac83d65c81386aef57b93cde76511/a7269/Untitled.png" sizes="(max-width: 740px) 100vw, 740px" loading="lazy">
 원래라면, <ul><li>패킷 로스를 가려주고</li><li>에코 캔슬링 (echo cancellation, 에코를 제거해서 통화 음질을 향상시키는 방법)</li><li>대역폭 조절</li><li>dynamic jitter buffering</li><li>automatic gain control (아마 음량 조절이나 그런부분까지)</li><li>노이즈 제거와 압축</li><li>이미지 클리닝</li></ul>직접 해야한다.<h2>스트리밍, 그리고 다자 간 통신</h2>위에서 말한 것처럼, 기본적으로는 P2P (Peer to Peer), 즉 두 단말이 서로 1:1 통신을 하게 되어있다. 따라서 대규모 방송 서비스를 구축하거나 컨텐츠 가공이 필요할 경우에는 중앙 미디어 서버를 구축할 필요성이 생긴다. 이런 경우 목적에 따라 두가지 아키텍처를 고려해볼 수 있다. 바로 MCU와 SFU. <h2>P2P</h2>그럼 원래 우리의 P2P는 어떨까. 중앙 미디어 서버 없이 종단 간 직접 연결하므로, 비용 측면에서 이득이 있다. 다만 peer 수가 증가할수록 개별 기기의 높은 성능을 요구한다. 1:1, 최소한 소규모 미디어 교환에 적합하다. <h3>MCU (Multipoint Control Unit)</h3>한쪽 Peer에 서버를 두고, 들어오는 트래픽을 서버에서 믹싱해서 다시 내보내는 방식이다. 클라이언트와 네트워크의 부담이 줄어드는 반면, 중앙서버의 컴퓨팅 파워가 많이 요구된다. 참고한 블로그에서는 낡은 기술이고 + 서버 운용 비용이 높아, WebRTC와 같은 실시간성 보장이 우선인 서비스인 경우 장점이 상쇄된다고 언급되어있다. <h3>SFU (Selective Forwarding Unit)</h3>믹싱하지않고 트래픽을 선별적으로 배분해서 보내주는 방식. 각 peer 연결 할당과 encrypt / decrypt 역할을 서버가 담당한다. 1:N 스트리밍 구조에 적합하다고 한다. 
 
 <img alt="WebRTC/sfu.png" title="WebRTC/sfu.png" src="https://juneyr.dev/static/fc433343c69f857c5f44ce221b3bd9d7/7d769/sfu.png" sizes="(max-width: 960px) 100vw, 960px" loading="lazy">
 그림 출처 : <a href="https://www.slideshare.net/tnoho/sfu">https://www.slideshare.net/tnoho/sfu</a> 의 일본어 부분만 치환했습니다. <h2>마치며</h2>실제로 WebRTC를 상용서비스로 변환하려면 고려해야할 점들이 더 있는데, 차차 보완하도록한다. <h2>참고</h2><a href="https://www.html5rocks.com/ko/tutorials/webrtc/basics/">https://www.html5rocks.com/ko/tutorials/webrtc/basics/</a> <a href="https://codelabs.developers.google.com/codelabs/webrtc-web/#7">https://codelabs.developers.google.com/codelabs/webrtc-web/#7</a><a href="https://blog.xenomity.com/P2P-vs-SFU-vs-MCU/">https://blog.xenomity.com/P2P-vs-SFU-vs-MCU/</a><a href="http://www.authorstream.com/Presentation/kangsik-3609452-webrtc/">http://www.authorstream.com/Presentation/kangsik-3609452-webrtc/</a><a href="https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Protocols">https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Protocols</a><a href="https://brunch.co.kr/@linecard/154">https://brunch.co.kr/@linecard/154</a></section></div>

Juneyr.dev RSS Feed

June Kim

WebRTC 를 공부하기로한다.  WebRTC가 뭔데 - 이름 그리고 비전 webRTC는 plugin-free web - Real Time Communication 이다. 그러니까 별도의 플러그인 설치없이  실시간 소통(비디오, 오디오)  이 가능하도록 만들어주는 기술. 기존에는 내가 영상통화를 하고 싶으면 디스코드, 스카이프, 구글  행아웃을 설치하는 과정이 필요했는데, webRTC…

실시간 통화 어떻게 하는 거지 : WebRTC 기초

댓글