WebRTC 2 : Signaling Server
WebRTC 두 번째 시간입니다. 지난 시간에 WebRTC를 통해서 우리는 Peer To Peer의 realtime communication이 가능하다고 했는데요. 하지만 이 말이 전적으로 맞는건 아닙니다. 다시 말해서 어쨋든! 서버가 필요하다는 거죠. 그럼 어떤 서버들이 있을까요?
- Signaling
- ICE & STUN / TURN
- Media Servers (option)
지난 시간에 눈으로만 익현던 친구들입니다. 하나 하나 알아가보겠습니다!
1. Signaling Server 란?
WebRTC는 사용자 간의 Peer to Peer Connection을 통해서 Object를 교환합니다. 하지만 단순한 P2P 연결만 있다고 해서 통신이 가능한건 아니겠죠? 상대방, 즉 Object를 보내는 주체가 누구인지를 알아야 합니다. 그래서 Signaling Server가 존재하고 필요한 것이죠! Signaling Server는 사용자 간의 WebRTC를 위한 P2P 통신을 할 때 모르는 사용자를 서로 엮어주는 역할을 합니다. 그래서 Always Needed!
순서는 다음과 같습니다.
- 브라우저가 사용자의 장치에 접근을 합니다.
- Signaling Server를 통해서 상대방의 정보를 얻습니다.
- Peer to Peer Connection을 통해 통신을 합니다.
이렇게 각 사용자는 원하는 최종 연결, Peer to Peer Connection을 만들기 위해 Signaling Server에 먼저 접근하고 상대방의 정보, 위치를 알아냅니다. 다시 말해서, Signaling Server는 이런 저런 메시지를 주고 받으면서 사용자 간의 Communication을 조정하는 프로세스라고 보시면 될 것 같습니다.
*이런 저런 메시지? Codec(코덱), Bandwidth(대역폭), Media Type(미디어 유형), IP 주소, 통신을 열고 닫기 위한 세션 컨트론 메시지들 (Session Control Messages) 등...
2. 그럼 Signaling Server가 어떻게 동작하는 건가요?
유저의 미디어 장치에 접근해서 허가를 받고 RTCPeerConnection를 생성한 뒤에 브라우저는 갖은 정보를 담고 있는 Offer를 생성합니다. 그리고 각각의 Offer는 Signaling Server로 전달되고 또 다른 Peer에게 전달됩니다. 이 Offer가 전달되면 Answer를 생성합니다. 각 Answer는 Offer를 보낸 Peer와 Signaling Server 모두에게 돌아갑니다. 이 메시지는 기본적으로 Session Description Protocol(sdp)을 사용합니다. 그리고 그 안에 우리가 언급한 모든 정보들이 들어있는 거죠.
또 다른 프로세스는 ICE Candidate인데, 요걸로 대체해서 사용할 수도 있습니다. 기본 동작 방식은 Signaling Server랑 비슷합니다. 여기서 ICE란 Interactive Connectivity Establishment로 브라우저가 Peer를 통한 연결이 가능하게 하는 프레임워크입니다.
아무쪼록 Signaling은 WebRTC의 확장자가 아니기 때문에 별개로 구축해야 합니다. 흠 저도 아마 이 작업을 착수해야 할 것 같습니다... 백앤드라니? ㅠㅠ
자! 그럼 이제 Signaling Server도 구축했겠다! 안정적인 Connection이 가능할까요? 아뇨!.. 아직 더 남았습니다. 이제 최적의 ICE를 찾는 것 그리고 STUN/TURN에 대해서 알아봐야 할 차례죠.
하지만 오늘은 여기까지 그럼 안녕!
참고자료:
https://www.youtube.com/watch?v=YWjfs4aWKMc&list=PLayYqdnyegt0qX8EfEGExxZF3DxkyA1Dj&index=3