[언택트 기술 시리즈]webrtc 서버 구축 2편 -시그널링 서버를 구축 하자.

드디어 webrtc 서버 구축 2탄~~ 시그널링 서버를 구축하자!!

webrtc 시그널링 서버가 무엇인지 모르겠다면 시리즈 전편을 확인하자.

https://kid-dev.tistory.com/4

[언택트 기술 시리즈]webrtc 서버 구축 1편 -기초

 

필자는 webrtc 시그널링 서버는 만남의 약속을 위한 서버라고 말한바 있다. 컴퓨터는 약속이란 무엇인가? 바로 프로토콜 아닌가?

 

프로토콜, protocol

명사

1. 복수의 컴퓨터 사이나 중앙 컴퓨터와 단말기 사이에서 데이터 통신을 원활하게 하기 위해 필요한 통신 규약. 신호 송신의 순서, 데이터의 표현법, 오류(誤謬) 검출법 등을 정함. 통신 규약(通信規約).

그럼 webrtc 시그널링 서버의 대표 프로토콜은 무엇일까?

 

sdp

 

 

오늘 주로 이야기 하게 될건 바로 sdp 라는 프로토콜이다. 그리고 추가적으로 ice negotication에 대해서 설명하게 될것이다. 시그널링 서버는 sdp와 ice negotication을 이해하지 못하면 절대 만들수 없다. 집중하도록 하자! 기본은 항상 중요한 법이다.

 

세션 기술 프로토콜(Session Description Protocol, SDP)은 스트리밍 미디어의 초기화 인수를 기술하기 위한 포맷이다. 이 규격은 IETF의 RFC 4566로 규정되어 있다.
-위키 백과-

 

sdp 는 기본적으로 제안과 수락 모델(offer/answer)로 정의 되어 있다.

1. Alice는 offer를 생성한다.  

2. Alice는 생성한 offer를 LocalDescription에 등록한다.

3. Alice는 생성한 offer를 Bob에게 보낸다.

4. Bob은 받은 offer를 RemoteDescription에 등록한다. 

5. Bob은 answer를 생성한다.

6. Bob은 생성된 answer를 LocalDescription에 등록한다.

7. Bob은 생성된 answer를 Alice에게 보낸다.

8. Alice는 Bob에게서 받은 answer를 RemoteDescription에 등록한다.

9. ice candidate를 교환한다.

 

제안과 수락 모델(offer/answer Model)은 Negotiation이라도 불리기도 한다.

 

자 그럼 offer/answer를 보내고 받기위해서는 중계서버가 필요한데, 그게 바로 webrtc 시그널링 서버이다. 당연히 중계를 위해서, 시그널링 서버(signaling server)는 양방향 통신 기술을 지원해야만 한다. 예를들면, socket.io나 websocket 같은? 물론 네티를 사용할수도 있다.( 추후에 한번 어떤 플랫폼이 최선일지 비교분석을 해보겠다.)

 

시그널링 서버의 양방향 통신

 

자~ 그럼 시그널 서버 끝?!! 아니다. 좀더 생각을 확장해보자. 위 예제는 단순히 1:1 연결에 대한 내용일 뿐이다. N:M을 연결할수 있는 구조로 어떻게 만들수 있을까?

 

N:M부터는 room이라는 개념이 필요하다. 마치 채팅방과 같다.

시그널링 서버 -N:M 연결

 

 

Alice와 Bob 그리고 Aiden은 서로 통화를 하고 싶다.  그렇다면 세명이서 모일 room이 필요한데, 이를 roomA라고 정의하자.

1. Alice는 시그널링 서버(signaling server)에게 roomA에 들어가고 싶다고 요청(request)을 보낸다.

2. 시그널링 서버는 room 정보(room에 누가 있는지, 몇명이 있는지 등의 정보)와 성공 여부를 Alice에게 response 한다. 만약 성공했다면 Alice는 roomA에 들어간것이다. 하지만 roomA에는 아무도 없기에 혼자있는 방이다.

3. 이제 Bob이 roomA에 들어가기 위해 시그널링 서버에게 요청을 보냈다.

4. Bob도 roomA의 room 정보(roomA에 누가 있는지, 몇명이 있는지 등의 정보)와 성공 여부를 받게 된다.

5. Bob은 roomA에 있는 모든이들과 offer/answer 교환을 통한 negotiation을 하면 된다.

6. 늦게 들어온 Aiden도 Bob과 똑같은 과정을 겪는다. 

 

사실 로그인 과정은 없어도 무관하다. 필자가 단지 필요에 의해서 만든것일 뿐이니 enterRoom만 먼저 해도 된다.

 

자! 먼 여정이었다. 하지만 webrtc 시그널링 서버는 단지 하나의 서버로만 구성하면 안된다. 무슨말이냐? 

시그널링 서버는 두가지 종류의 서버가 필요하다. 

 

세션 서버: room에 누가 있는지, 그리고 누가 들어오는지 나가는지를 관여할 Http 서버

채널 서버: offer/answer를 중계하기 위한 websocket 서버

 

물론, 세션서버가 없이 채널서버만으로 request, respnse 처리 및 room 관리를 해도 무관하다. 채널 서버를 분산처리 하지 않을것이라면 말이다. 이말은 즉슨, 세션서버는 채널서버의 분산처리까지 담당한다는 뜻이다. 

 

자, 그럼 이걸 어떻게 코딩할수 있을까? 위에 재료는 전부 제공 했으니, 자유롭게 코딩 해보길 바란다

위 내용를 이해 했다면 충분히 webrtc N:M 연결을 구현할수 있을 것이다.

 

필자는 현재 webrtc 시그널링 서버를 소스 공개 예정이니, 기대해도 좋다. 

 

자! 이제 정말 이렇게만 만들면 시그널링 서버가 끝난것일까? 아니다. 우리의 big 이슈가 남았다. 

 

traffic이 몰렸을때 어떻게 분산처리를 할것인가?

 

LB 달면 되지 않나요? 이렇게 안일하게 생각하고 있다면 한참더 고생해야 할것이다. 다음 시간에는 '시그널링 서버는 어떻게 분산처리를 할것인가?' 집중적으로 설명해보겠다!! 이것이야 말고 서버개발자의 정수 아니겠는가? 기대하시라 개봉박두!!  

 

참고 문헌

위키 백과 -https://ko.wikipedia.org/wiki/%EC%84%B8%EC%85%98_%EA%B8%B0%EC%88%A0_%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C

세션 기술 프로토콜 - 위키백과, 우리 모두의 백과사전

그리고 나의 머리와 경험