WebRTC 시그널링 서버 (Spring Boot로 구현)

📌 이 기술을 공부한 계기!

항해99 실전 프로젝트에서 게임 사이트를 제작하면서 화상 및 음성 채팅이 필요했고 우리는 WebRTC를 채택했다.

그런데 구현하는 과정에서 백엔드 입장에서 구현해야할 부분이 있었는 데, 백엔드는 뭘 해야줘야 하는 지부터 몰라서 많이 헷갈렸다. 공부를 하면서 백엔드는 WebRTC에 필요한 시그널링 서버를 구현해야 한다는 걸 알게되었고 따로 정리를 해보게 되었다 (백엔드 입장에서만 정리)

 

---

📍WebRTC Signaling 서버를 설명하려면.. 

시그널링 서버를 소개하려면 WebRTC를 소개해야하고, WebRTC를 소개하려면 Websocket을 소개해야하고, Websocket을 소개하려면 HTTP를 알아야한다. 

 

HTTP는 브라우저와 서버가 소통하는 프로토콜로 인터넷 데이터 교환의 가장 기본이 된다.
그런데 Http는 요청 방식을 보면 단방향이다. 브라우저가 요청하면 서버가 응답하고 그리고 끝!

상태를 유지하지도 않고 금방 우리가 뭐했는지도 잊어버리는 stateless 무상태로 돌아간다. 심지어 브라우저의 요청에만 반응하기 때문에 단반향이라 실시간에 적합하지 않아 뭐가 새로 업데이트를 했는지 보려면 계-속 뭐가 새로 바뀌었니 하면서 서버에 요청을 해야한다.

그래서 실시간성에 HTTP가 적합하지 않자 Websocket이 등장했다.
Websocket은 브라우저와 서버간의 연결이 유지한다. 서로 계속 연결할 뿐만 아니라 양방향으로 가능한 통신이라 브라우저는 물론이고 서버도 요청없이 변화가 생기면 바로바로 브라우저에게 메세지를 보낼 수 있게 되었고 그 연결은 누군가 끊기 전까지 계속 된다.

하지만 웹소켓도 중개자인 서버가 필요하고 서버가 일일이 상대방을 포워딩해서 내용을 다른 사람에게 전달해야하다 보니 서버의 성능, 비용등의 많은 문제가 생긴다.

그럼 중개자가 없어지고 브라우저들 끼리만 연결하면 어떨까?
이게 바로 WebRTC가 하는 기능이다. 이름도 Web Real Time Communication의 약자인 이유가 서버 없이 서로 메세지, 음성, 영상등을 주고 받아 중개자인 서버가 없으니 속력이 빨라 실시간에 적합하기 때문이다.

 

📍WebRTC (Web Real-Time Communication) 란?

웹과 앱에서 별 다른 드라이버나 플러그인 없이 실시간으로 데이터를 교환할 수 있어 카메라와 마이크를 사용해 P2P(Peer to Peer) 실시간 커뮤니케이션이 가능을 하게 하는 기술

 

WebRTC는 별개의 플러그인을 설치하는 등의 귀찮은 작업도 필요없이 브라우저만 있으면 되기 때문에 편리하다.
게다가 서버는 계속 전달해줘야 하는 역할에서 빠지니 서버가 가져야하는 부담이 줄어 좋다. 

그럼 잠깐 여기서 서버가 할일이 여기서 어딘데? 

바로 WebRTC 시작지점에서 서버가 해줘야 할일이 있다.  WebRTC는 그냥 이뤄지는 게 아니라 처음으로 서로에 대해 소개를 하는 시간이 필요하고,  이 부분에 있어서는 서버가 중개자로서의 역할을 해줘야 하는데 이를 시그널링 서버라고 한다.

 

📍WebRTC에 필요한 시그널링(Signalling) 이란?

서로 다른 네트워크에 있는 미디어 포맷 등을 상호 연동하기 위해 협의 과정을 거치는 데 이를 시그널링 이라고 한다. 이 과정에서 네트워크 주소 변환 및 방화벽에 대응하게 된다. 이 협의과정에서 중간 단계 역할을 하는 시그널링 서버를 백엔드가 구현해줘야한다!

 

 

📍WebRTC 시그널링 서버의 "대략적인" 흐름을 만화로 그려봄!

 

 

📍 시그널링 다이어그램

https://github.com/satanas/simple-signaling-server

 

 

📍 용어 설명

 

✒ WebSocket

브라우저에서 지원하는 API 종류로 서버와 클라이언트 간의 메세지 교환을 위한 통신 규약 (프로토콜). 단방향으로 한번 Request/Response를 보내면 사라지는 HTTP의 stateless 속성과 달리 연결지향 양방향 전이중 통신이 가능한 프로토콜로 연결을 지속하여 상태를 유지한다. 주로 데이터의 빠른 업데이트, 실시간을 위해 많이 사용된다. 

 

✒ Session

브라우저(클라이언트)와 서버 간의 연결 상태로 브라우저가 웹서버에 접속한 시점부터 브라우저를 종료하여 연결을 끝낼 때까지 같은 사용자로 부터 오는 요청을 하나의 상태로 보면서, 그 상태를 일정하게 유지하는 기술.  웹 서비스에서 브라우저 당 하나의 Session을 갖는다.

 

✒ offer 와 answer

WebRTC 메세지는 아니지만 SDP라는 포맷으로 세션 정보를 생성하여 먼저 offer(제안)를 보내면 이에 대한 대답으로 answer(응답)를 보내며 서로 SDP를 교환한다. 

 

✒ SDP (Session Description Protocol)

Peer가 가진 세션의 정보들을 포함하고 있다. 

포함된 정보

SDP를 생성한 Peer의 식별자 (유저이름, 세션아이디, 세션 버젼, 네트워크 타입, 주소 타입, 유니캐스트 주소 등), 미디어라인 (미디어 타입(음성인지 영상인지등), 포트 번호, 미디어 형식(코덱) 등), 실시간 트래픽을 주고 받을 IP, RTCP에 사용될 IP, ICE 파라미터, DTLS 파라미터, BUNDLE행에 사용되는 식별자, 밴드위드스, 미디어 방향, opus 코덱 등등

 

✒ ICE (Interactive Connectivity Establishment) candidate

웹 브라우저 간의 직접적인 Peer to Peer를 접속할 수 있도록 해주는 프레임워크. SDP가 미디어에 대한 정보를 준다면 네트워크에 대한 정보를 교환하는 것을 ICE candidate라고 한다. 각각의 Peer는 가장 좋은 후보에서 나쁜 후보 순서로 제안하며 서로가 맞는 최적의 주소값을 찾는다.

 

 

📍 구현 코드

GitHub - littlezero48/Study-Storage: 📒 다양한 공부 흔적을 남기는 곳

 

 

---

참고 자료:

[WebRTC] Signaling Server ( 시그널링 서버 )

WebRTC 연결성 및 NAT 통과 기법