개발하는데 다 이유가 있겠지

WebRTC(Web Real-Time Communication)

 

정의

---

브라우저 간 플로그인의 도움 없이 서로 통신할 수 있도록 설계된 API

P2P(Peer to Peer) 화상회의, 음성 채팅, 화상 채팅, 데이터 교환 등

 

 

통신 원리

---

서버 기반과 P2P

WebRTC는 P2P 통신에 최적화

* P2P란?
    - Peer to Peer의 줄임말로 중앙 서버를 거치지 않고 클라이언트 간 직접 통신하는 방식

 

클라이언트 간의 시그널링하는 과정

시그널링(Signaling)
- WebRTC를 연결하기 위해서는 Caller와 Callee가 정보를 주고 받는 과정
- 정보를 주고 받기 위해서 중간 역할을 하는 시그널링 서버가 필요

시그널링 서버(Signaling Server)
- WebRTC는 기본적으로 P2P 연결로 화상 연결 / 음성 연결을 위한 별도의 서버가 존재하지 않음
- 각 Peer는 연결하고자 하는 Peer가 어디에 존재하는지 알 수 없음
- 연결하고자 하는 Peer와 정보를 교환해주는 서버

 

 

용어

---

STUN 서버, TURN 서버

• Peer간의 서로가 어디에 있으며, 어디로 통신해야 하는지 알려주는 서버

STUN(Session Traversal Utilities for NAT) 서버

• 해당 Peer의 Public IP 주소를 보내는 역할
• 두 엔드 포인트 간의 연결을 확인하고 NAT 바인딩을 유지하기 위한 연결 유지 프로토콜로 사용

STUN(Session Traversal Utilities for NAT) 서버

*NAT(Network Address Translation)
    - 통상적인 네트워크 상황에서 데이터를 주고 받기 위해서는 Public IP가 필요
    - NAT는 Private IP를 Public IP로 1대 1로 대응시켜 변환하는 장치(Private IP -> Public IP)
    - Public IP는 요청을 보낼 때마다 NAT에 의해 바뀜(동일한 Public IP로 통신할 수 없는 문제 발생)

---

TURN(Traversal Using Relays around NAT)

• STUN의 확장으로 NAT 환경에서 릴레이하여 통신
• NAT 보안 정책이 엄격하거나, NAT 순회를 하기 위해 필요한 NAT 바인딩 성공적으로 생성할 수 없는 경우 사용
• TURN 서버는 인터넷 망에 위치하고 각 Peer들이 사설망(Private IP) 안에서 통신
• 각 Peer들이 직접 통신하는 것이 아닌 릴레이 역할을 하는 TURN 서버를 사용해 경유
• STUN에 비해 리소스 낭비가 심함(최후의 수단으로 사용)

TURN(Traversal Using Relays around NAT)

* 정리
- 시그널링 서버 : 클라이언트 간 연결 설정 정보 교환
- STUN 서버 : 클라이언트의 공인 IP 주소 및 포트 정보 제공
- TURN 서버 : P2P 연결 불가 시 데이터 중계


* 주의할 점
TURN 서버를 사용하면 데이터가 항상 서버를 거쳐 가기 때문에 직접 통신하는 것보다 속도가 느리고 서버에 부하가 걸릴 수 있음
가능하면 STUN 서버를 이용해 직접 통신을 시도하고, 필요한 경우에만 TURN 서버 사용

---

ICE(Interactive Connectivity Establishment)

• 브라우저가 Peer간의 연결이 가능하도록 해주는 프레임 워크
• 클라이언트가 모든 통신 가능한 주소를 식별

1. Server Reflexive Address : NAT가 맵핑한 클라이언트의 공인망 (Public IP, Port)
2. Local Address : 클라이언트의 사설 주소 (Private IP, Port)
3. Relayed Address : TURN 서버가 패킷 릴레이를 위해 할당하는 주소

---

Candidate

• IP와 포트의 조합으로 표시된 주소
• ICE를 통해 확보된 3개의 주소를 우선 순위를 정해 SDP 내에 포함해 전송
• 연결을 확인한 후 연결이 됐다면 RTP, RTCP 패킷을 전송해 통화가 가능

* RTP(Real-time Transport Protocol)
    - 실시간 음성, 영상 및 데이터를 IP 네트워크로 전송하는 표준 프로토콜

* RTCP(Real-time Transport Control Protocol)
    - 송수신 서비스 품질 관련 정보를 클라이언트간에 주기적으로 교환하도록 하는 역할
    - 정보에 따라 전송 속도, 코덱 조정

---

SDP(Session Description Protocol)

• WebRTC에서 스트리밍 미디어의 해상도나 형식, 코덱 등의 멀티미디어 컨텐츠의 초기 인수를 설명하기 위한 프로토콜
• 비디오 해상도, 오디오 전송 또는 수신 여부 등을 송수신 할 수 있음

 

 

구현 방식

---

Peer간 offer, answer를 통한 session 정보를 중계해줘야 함

WebRTC 구현 방식

 

Mesh 방식(Signaling 서버)

• 특징
  • Peer간 offer, answer 라는 session 정보 signal만을 중계함
  • 처음 WebRTC가 Peer간의 정보를 중계할 때만 서버에 부하가 발생
  • Peer간 연결이 완료된 후에는 서버에 별도의 부하가 없음
• 장점
  • 서버의 부하가 적기 때문에 서버 자원이 적게듬
  • peer간의 직접 연결로 데이터를 송수신하기 때문에 실시간성이 보장됨
• 단점
  • N:N 또는 N:M 연결에서 클라이언트의 과부하가 급격하게 증가
  • 예를 들어, 5명이서 통신을 하는 경우에는 Uplink(나의 데이터를 연결된 다른 사용자에게 전달) 4개, Downlink(연결된 다른 사용자의 데이터를 받아옴) 4개로 한 명당 총 8개의 link를 유지해야 함 -> 클라이언트의 부담이 커짐

 

MCU 방식(Multi-point Control Unit 서버)

• 특징
  • 다수의 송출 미디어를 중앙 서버에서 혼합(Mixing) 또는 가공(Transcoding)해 수신측으로 전달하는 중앙 서버 방식
    (자신을 제외한 다른 Peer의 데이터를 하나의 video, audio 데이터를 편집해 한 명에게 보냄)
    - 가공 : 코덱 변환, 해상도 조절, 레리아웃 변경
    - 혼합 : 오디오 믹싱, 비디오 믹싱
  • 클라이언트 Peer간 연결이 아닌, 서버와 클라이언트 간의 Peer를 연결
  • 서버에게만 자신의 영상 데이터만 보내면 됨(Uplink 1개)
  • 서버에게서 하나의 Peer로 데이터를 받으면 됨(Downlink 1개)
  • 중앙 서버의 높은 컴퓨팅 파워가 요구됨
• 장점
  • 클라이언트의 부하가 현저히 줄어듬(항상 Uplink, Downlink 1개)
  • N:M 구조에 사용 가능
• 단점
  • 실시간성이 저해됨
  • video, audio를 혼합, 가공하는 과정에서 비용이 많이 듬

 

SFU 방식(Selective Forwarding Unit 서버)

• 특징
  • 종단 간 미디어 트래픽을 중계하는 중앙 서버 방식
  • 클라이언트 Peer간 연결이 아닌, 서버와 클라이언트 간의 Peer를 연결
  • 모든 사용자에게 데이터를 보낼 필요없이 서버에게만 자신의 영상 데이터를 보냄(Uplink 1개)
  • 상대방의 수만큼 데이터를 받는 Peer를 유지(Downlink 연결된 다른 사용자의 수)
  • 1:N 또는 소규모 N:M 형식의 실시간 스트리밍에 적합
• 장점
  • Mesh 방식을 사용할 때보다 느리지만 비슷한 수준의 실시간성을 유지
  • Mesh 방식보다 클라이언트가 받는 부하가 줄어듬
• 단점
  • Mesh 방식보다 서버 비용이 증가
  • 대규모 N:M 구조에서는 클라이언트가 많은 부하를 감당(Downlink가 연결된 다른 사용자의 수이기 때문에)