WebRTC란 무엇인가?

WebRTC는 Web Real-Time Communication의 약자로, 웹 브라우저 간에 실시간으로 오디오, 비디오, 데이터 스트림을 주고받을 수 있도록 지원하는 기술이다. WebRTC를 통해 사용자는 플러그인 없이 웹에서 직접 영상 통화, 파일 공유, 게임 등 다양한 실시간 커뮤니케이션 서비스를 구현할 수 있다. WebRTC는 P2P(Peer-to-Peer) 기술을 사용하여 두 클라이언트 간의 직접적인 연결을 제공한다. 이를 통해 데이터가 서버를 거치지 않고 바로 전송되어 지연을 줄이고 네트워크 부하를 줄이는 장점이 있다.

---

Peer-2-Peer에서도 서버가 필요한 이유: 시그널링 서버

WebRTC는 Peer-to-Peer 연결을 사용하지만, 실제로 P2P 연결이 성립되기 위해서는 시그널링(Signaling) 서버가 필요하다. 시그널링은 두 클라이언트가 서로 연결될 수 있도록 정보를 주고받는 초기 과정이다. WebRTC는 시그널링을 처리하는 구체적인 방식을 제공하지 않기 때문에 이를 개발자가 구현해야 한다.

 

시그널링 서버의 역할은 다음과 같다:

 

1. Peer 간 정보 교환: WebRTC 연결을 시작하기 위해 각 Peer는 상대방의 연결 정보를 알아야 한다. 시그널링 서버는 각 Peer의 SDP(Session Description Protocol)와 ICE(Interactive Connectivity Establishment) 후보군 정보를 전달해 준다. (SDP와 ICE는 아래에서 후술)
2. 네트워크 상태 확인: Peer들이 서로 직접 연결할 수 있는지 확인하고, 필요한 경우 적절한 서버(TURN 서버 등)를 통해 간접적으로 연결을 할 수 있도록 돕는다.

이 과정이 완료되면, 시그널링 서버는 더 이상 사용되지 않고, Peer 간의 직접적인 P2P 연결이 형성된다.

---

SDP와 ICE Candidate

SDP(Session Description Protocol)와 ICE(Interactive Connectivity Establishment) Candidate는 WebRTC 연결 과정에서 매우 중요한 역할을 한다.

• SDP: 각 Peer의 미디어 혹은 연결 설정을 정의한다. 여기에는 오디오 및 비디오 코덱, 해상도, 네트워크 설정 등이 포함된다. 이를 통해 Peer 간에 어떤 방식으로 데이터를 주고받을지 설정한다.
• ICE Candidate: 각 Peer의 네트워크 주소 정보를 나타낸다. Peer 간 연결을 시도하기 위해 서로의 IP 주소와 포트를 교환하는데, 이것을 ICE Candidate라고 한다. Peer는 여러 개의 ICE Candidate를 제공하며, 가장 적합한 경로를 선택하여 연결을 시도한다.

SDP와 ICE Candidate는 P2P 연결이 성립되기 위한 필수적인 정보들이며, 시그널링 서버를 통해 교환된다.

 

cf) Session 이라는 키워드가 다양한 분야에서 많이 쓰이게 되는데, 웹의 사용자 정보를 저장할때도 Session이라는 키워드를 쓰고, 구글 검색에서 사용자들을 분석할때도 Session이라는 키워드가 사용된다. Session의 사전적 의미는 '기간' 이지만 다양한 사용처에서 쓰이는 의미는 '사용자의 일시적 연결 상태'를 나타낸다.

 

cf) DataChannel로 연결할 경우 Peer간 하나만 필요하다. 양쪽에서 모두 생성하지 않는다.

---

Peer간 SDP 주고받기:  offer와 answer

WebRTC 연결을 시작하기 위해서는 두 Peer가 서로 연결 요청과 응답을 주고받아야 한다. 이 과정에서 핵심적인 두 메시지가 Offer와 Answer이다.

 

1. Offer: 연결을 시작하려는 쪽이 먼저 Offer 메시지를 상대 Peer에게 보낸다. 이 메시지에는 연결하고자 하는 미디어 스트림의 설정 정보(SDP)가 포함된다.
2. Answer: Offer를 받은 Peer는 이에 대한 Answer 메시지를 보내어 연결 요청에 응답한다. 이때도 SDP 정보를 포함하여 Offer에서 제시한 연결 설정을 수락하거나 조정할 수 있다.

 

이러한 Offer와 Answer 교환 과정을 통해 두 Peer 간의 연결 설정이 완료되고, 본격적인 미디어 스트림이나 데이터 전송이 시작된다.

---

Peer간 연결 방식 정하기: ICE Candidate

1. ICE Candidate 수집(Gathering): Offer 혹은 Answer가 생성되면, 자동으로 ICE Gathering(ICE 수집) 단계가 시작된다. 이때 WebRTC는 Host Candidate(로컬 IP), Server Reflexive Candidate(STUN 서버를 통해 공인 IP 확인), Relay Candidate(TURN 서버를 통한 중계)를 차례로 수집하며, ICE Candidate가 생성된다.
2. ICE Candidate 이벤트 발생: ICE Candidate가 생성될 때마다 onicecandidate 이벤트가 발생하며, 생성된 Candidate는 시그널링 서버를 통해 상대 Peer에게 전달해야 한다.

---

TURN 서버와 STUN 서버

WebRTC 연결에서는 Peer들이 NAT(Network Address Translation) 환경에 있을 경우 직접 연결이 어려울 수 있다. 이때 STUN과 TURN 서버가 도움을 준다.

 

• STUN (Session Traversal Utilities for NAT): STUN 서버는 각 Peer가 자신의 공인 IP 주소와 포트를 확인할 수 있도록 도와준다. 이를 통해 NAT 뒤에 있는 Peer들도 서로 직접 연결을 시도할 수 있다. STUN 서버는 일종의 위치 조회 서비스로 동작하며, 연결 과정에서 아주 잠시 사용된다.
• TURN (Traversal Using Relays around NAT): NAT 환경이 너무 복잡하거나 Peer 간에 직접 연결이 불가능할 때, TURN 서버를 이용하여 데이터를 중계할 수 있다. TURN 서버는 STUN 서버와 달리, 연결 이후에도 데이터가 서버를 통해 중계되기 때문에 더 많은 대역폭이 필요하다. 따라서 TURN 서버는 최후의 수단으로 사용되며, Peer 간에 직접 연결이 불가능할 때만 사용된다. 그래서 TURN 서버를 통한 ICE Candidate가 선정된다면 사실상 Peer-2-Peer가 아니게 된다. 

 

이 두 서버를 통해 다양한 네트워크 환경에서도 안정적으로 P2P 연결을 성립할 수 있다.

---

 

시그널링

---

Mdn web Docs | WebRTC API

https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API

WebRTC API - Web APIs | MDN

 

---

참고

• https://youtu.be/bWcNEk0H4Y0?si=vZRaXZNDuSOJs8-i
• https://github.com/satanas/simple-signaling-server