느뤼는 Google Korea에서 개최하는 2012년 Google HackFair에 참가를 위해 "WebRTC를 이용한 다중 화상채팅"을 준비하였습니다.
이 준비 기간중 습득하게된 WebRTC에 대한 정보와 개인적인 고찰(!?)을 글로 남겨 봅니다.
WebRTC? - Web Real-Time Communication (http://www.w3.org/TR/webrtc/)
- 말그대로 웹을 이용한 실시간 통신을 이야기합니다. 오잉? 그럼 이전에는 실시간 통신이 없었단 말인가? 하고 반문하시는 분들이 있을 텐데 차분하게 뒤쪽에서 기존의 실시간 통신들과의 차이점을 하나하나 알아보도록 하겠습니다. WebRTC는 현재 W3C와 IETF의 주도하에 WebKit API가 정의되어가고 있습니다. 링크로 들어가 확인해보시면 알 수 있지만 아직 진화중에 있습니다. Chrome에서 현재 가장 활발하게 진행중이기 때문인지 웹사이트도 그렇고 포럼도 그렇고 Googler 들이 주도적인 모습입니다.
WebRTC를 이해하기 위한 주변 필요지식들
- WebRTC를 이해하기위해 각종 문서들을 접하다 보면 보게되는 선수지식들을 정리해봅니다. 물론 제가 몰랐던 것들을 위주로 정리가 되었으니 이미 알고 계시다면 Pass!
1) GETUSERMEDIA (http://www.w3.org/TR/mediacapture-streams/)
- WebRTC를 이용한 화상채팅에서 가장 기본이되는 Video, Audio Stream을 Webkit으로 부터 제공받는 API입니다. 만약 이것이 구현되지 않은 webkit browser에서 WebRTC 화상채팅 페이지를 접근하게 된다면....삐~ 동작이 안하게 됩니다. 현재는 Chrome, Safari, Firefox 가 지원됩니다.
2) SDP (Session Description Protocol , http://tools.ietf.org/html/rfc3264)
- SDP는 각 Peer가 가진 세션의 정보들을 포함한 프로토콜입니다. 특히 제가 준비한 화상채팅의 경우에는 화상통신을 위한 Video, Audio Stream 연결을 위한 Peer Session 정보들이 담겨져 있습니다.
3) ICE (Interactive Connectivity Establishment , http://tools.ietf.org/html/rfc5245)
- 위 링크를 따라 들어가면 ICE에 대한 장황한 설명이 들어있지만 요약해서 간단히 이야기한다면 네트워크상에서의 Peer간 응답 프로토콜입니다.
다시 말해, 한쪽의 Peer가 다른 한쪽의 Peer에거 "Offer" - 전화를 겁니다. 그러면 "Offer"를 받은 Peer가 "Answer" - 전화를 받음으로써 서로 연결이 된다는 간단한 프로토콜입니다. 이때 연결은 서로의 SDP 정보를 교환함으로써 이루어집니다. 이미 VOIP서비스에서 사용되고 있는 Protocol입니다.
4) JSEP (Javascript Session Establishment Protocol , http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-02)
- Javascript session 정보를 ICE를 통해 통신하는 프로토콜에 대한 내용입니다. 아직 정의가 완료되지 않고 현재 진행중으로 2012-11 현재 02 버전이 나와 있습니다.
5) STUN Server (Session Traversal Utilities for NAT, http://en.wikipedia.org/wiki/STUN)
- STUN 서버는 WebRTC를 이용한 Peer간의 통신 연결시에 내부 IP 또는 DHCP로 설정된 Peer가 Public 망에서의 연결이 가능하도록 해줍니다. 뒤에 예제를 들어가면서 설명할때 나오겠지만 인터넷 세상에 STUN Server 서비스를 무료로 제공하는 곳이 많이 존재합니다. VOIP등의 서비스를 위해 열려있는데 저는 구글에서 제공하는 STUN서버를 사용하였습니다.
자 위의 정보들을 대강이나마 머리속에 집어 넣으셨다면 거침없이 WebRTC에 대해 알아봅니다.
WebRTC는 HTML5와 Javascript를 통한 Webkit API를 사용하여 구현이 됩니다. 다시말해 WebRTC가 지원되는 Webkit Browser의 경우에는 화상 통신을 위한 추가적인 플러그인 설치없이 웹페이지에서 바로 접근 가능하다는 이야기 입니다. 현재 지원되는 Webkit Browser는 Chrome이 대표적이며 2012년 4Q또는 2013년 1Q에 Firefox, Safari가 지원될 예정입니다. 안타깝게도 IE는 아직 지원에 대한 소식이 없고, W3C에서 정의하는 표준과는 다른 표준안으로 구현될 것이라는 아주 MS스러운 루머가 돌고 있습니다. WebRTC가 브라우저 상에서 완전한 표준으로 자리잡게 된다면 Mobile 에서도 특별한 플러그인이나 앱의 추가 설치 없이 화상채팅 서비스를 사용가능하게 됩니다. 이런 Amazing한!
WebRTC는 P2P 통신을 사용합니다. WebRTC API에 정의되어있는 PeerConnection API를 통해 P2P통신이 가능하게 됩니다. 기존의 WebSocket은 웹서버와의 C/S 통신에 사용되었지만 PeerConnection은 Peer간의 MediaStream 공유를 가능하게 해줍니다. 제가 희망하기로는 FileStream까지 연결이 가능하다면 브라우저상의 토렌트가!? ㅋ
자 이제 그럼 WebRTC 교양은 그만하도록 하고 실제 WebRTC 연결을 StepByStep으로 확인해보도록 하겠습니다.
1. 두 Peer간의 PeerConnection이 연결이되려면 SDP를 서로 주고 받아야합니다. 하지만 PeerConnection도 연결되지 않은 상태에서 상대방에게 정보를 전달하는 방법은 불가능 합니다. 이로인해 불가피하게 Peer사이에 ICE 통신을 가능하게 해줄 중계서버가 하나 필요합니다. 중계서버라고 해서 거창한 무엇인가가 아니고 단순 채팅서버와 같은 메세지 C/S 서버만 있으면 됩니다. Google에서 기본 예제로 제공하는 (https://apprtc.appspot.com) 사이트에서는 이 중계서버를 GAE의 Channel API를 사용하였습니다. 저도 처음 구현시에 Channel API로 시작하였지만 GAE에서 제공하는 무료 Channel 생성 API 호출 횟수가 100번으로 제한되어있어 그냥 하나의 중계서버를 만들었습니다.
2. Peer간의 메세징 서버가 구성이 되었다면 이제 다음의 순서로 메세지를 주고 받습니다.
3. 이제 각 Peer간의 PeerConnection에 SDP 정보를 공유하면 연결이 끝!....이 아니고 이제 실제 연결은 ICE를 통해서 이뤄집니다.
PeerConnection을 생성할때 사용할 STUN Server의 정보를 입력하게 되어있는데 SDP 공유시에 이 정보도 공유가 됩니다. 그래서 ICE가 시작이되면 우선적으로 UDP를 통해 자신이 가진 SDP에 해당하는 상대방을 탐색하게 됩니다. 만약 UDP로의 탐색이 실패하게 되면 TCP로 HTTP, HTTPS 순으로 탐색을 다시 시작합니다. 이후 탐색이 완료가 되면 비로소 실제 PeerConnection간의 연결이 완료가 되어 상대방의 PeerConnection에서 받은 MediaStream을 사용할 수 있게됩니다.
이렇게 WebRTC에 대한 연결 방식까지 이해가 되셨으면 WebRTC를 처음 접하시는 분들의 바이블 Post인 HTML5Rocks의 Article(http://www.html5rocks.com/ko/tutorials/webrtc/basics/)을 참고해보세요.
다시 복습의 느낌으로 보게되니 느낌이 팍팍 오실겁니다.
아래 동영상은 HTML5Rocks에도 연결되어있지만 2012 Google I/O에서 발표된 WebRTC 소개 동영상입니다.
다음 포스트에서는 실제 HackFair에서 사용한 저의 코드를 보면서 1:1 P2P가 아닌 n:n P2P Trick까지 확인해보겠습니다.
아래는 HackFair에 제출한 WebRTC 동영상입니다. Draft 버전이었기에 UI가 ㅋ
Let's Hack!!
