WebRTC01_기초개념

1 minute read



WebRTC란?

  • 웹 애플리케이션과 사이트가 중간자 없이 브라우저 간에 오디오나 영상 미디어를 스트림하고, 교환하는 기술
  • 드라이버나 플러그인 설치 없이 P2P연결로 데이터 교환을 가능하게 하는 기술.
  • 다양한 플랫폼과 브라우저에서 동일한 경험을 제공해야하지만 아직까지는 표준화가 완전히 구현되지 않음.
  • 크로스 브라우징 이슈 해결 : adapter.js라이브러리 필수로 사용해야함.


1. P2P절차

  1. 각 브라우저가 P2P커뮤니케이션에 동의
  2. 서로의 주소를 공유
  3. 보안사항 및 방화벽 우회
  4. 멀티미디어 데이터를 실시간으로 교환
    • 브라우저는 웹서버가 아니므로, 외부에서 접근할 수 있는 주소가 없다. (중재자 역할 필요)

2. NAT 트래버셜

  • 공인 IP만을 알아낸다고 해서 특정한 사용자를 가리킬 수 없음.
  • 라우터는 외부에서 접근하는 공인 IP와 포트 번호를 확인하여 현재 네트워크 내의 사설 IP를 매핑해준다.
  • 그러나 일부 라우터는 방화벽 설정으로 연결이 차단되어 있을 수도 있음.
  • 라우터를 통과해서 연결할 방법을 찾는 과정이 바로 NAT traversal.

3. STUN, TURN

3-1. STUN

  • NAT traversal은 STUN서버에 의해 이루어짐.
  • 자신의 공인 IP주소와 포트를 확인하는 과정에 대한 프로토콜
  • STUN서버는 인터넷의 복잡한 주소 중 유일하게 자신을 식별할 수 있는 정보 반환
  • WebRTC연결을 시작하기 전에 STUN서버를 향해 요청을 보내면, NAT뒤의 Peer들이 서로 연결할 수 있도록 공인IP와 포트를 찾아줌.

3-2. TURN

  • STUN서버를 통해 자신의 주소를 못찾았을 경우, TURN서버를 대안으로 이용
  • 네트워크 미디어를 중개하는 서버를 사용
  • 엄밀히 이야기 하면 P2P통신이 아님.(중간에 서버를 거치기 때문)
  • 지연발생 가능
  • 최후의 수단느낌?

4. ICE와 Candidate

  • STUN, TURN서버로 획득한 IP주소와 프로토콜, 포트의 조합으로 구성된 연결 가능한 네트워크 주소 후보
    1. 자신의 사설IP와 포트 넘버
    2. 자신의 공인 IP와 포트넘버(STUN, TURN서버로부터 획득 가능)
    3. TURN서버의 IP와 포트넘버(TURN서버로부터 획득 가능)
  • 이 모든 과정은 ICE라는 프레임워크 위에서 이루어지며, 두 개의 단말이 P2P연결을 가능하게 하도록 최적의 경로를 찾아주는 프레임워크

5. SDP

  • WebRTC에서 스트리밍 해상도나, 코덱 등의 초기 인수를 설명하기 위해 채택한 프로토콜

6. Trickle ICE

  • ICE는 후보들을 수집해서 한꺼번에 목록을 교환, 이는 SDP(제안응답모델)와 맞물리면서 단점으로 작용
  • 비효율적 후보교환작업을 병렬 프로세스로 수행할 수 있게 만드는 것

7. 시그널링

  • 위의 모든 과정
  • RTCPeerConnection통신에 사용할 프로토콜, 채널, 미디어 코덱 및 형식, 데이터 전송 방법, 라우팅 정보와 NAT 통과 방법을 포함한 통신 규격을 교환하기 위해 두 장치의 제어정보를 교환하는 과정
  • 아마존의 Kinesis Video Stream, 구글의 AppRTC




WebRTC의 한계

  1. 브라우저간 호환성.(사파리, 엣지)
  2. 시그널링 서버에 대한 명시적 표준 없음.(개발자의 자율성을 보장하지만 입문하기 쉽지 않음)
  3. UDP위에서 동작하므로 중요 파일 전송시 데이터 손실 문제 가능.(몇바이트지만 전체가 동작하지 않을수도..)
  4. TCP방식도 사용할 수 있지만 모든 브라우저가 지원하는 것은 아님