WebRTC란?
- 웹 애플리케이션과 사이트가 중간자 없이 브라우저 간에 오디오나 영상 미디어를 스트림하고, 교환하는 기술
- 드라이버나 플러그인 설치 없이 P2P연결로 데이터 교환을 가능하게 하는 기술.
- 다양한 플랫폼과 브라우저에서 동일한 경험을 제공해야하지만 아직까지는 표준화가 완전히 구현되지 않음.
- 크로스 브라우징 이슈 해결 : adapter.js라이브러리 필수로 사용해야함.
1. P2P절차
- 각 브라우저가 P2P커뮤니케이션에 동의
- 서로의 주소를 공유
- 보안사항 및 방화벽 우회
- 멀티미디어 데이터를 실시간으로 교환
- 브라우저는 웹서버가 아니므로, 외부에서 접근할 수 있는 주소가 없다. (중재자 역할 필요)
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주소와 프로토콜, 포트의 조합으로 구성된 연결 가능한 네트워크 주소 후보
- 자신의 사설IP와 포트 넘버
- 자신의 공인 IP와 포트넘버(STUN, TURN서버로부터 획득 가능)
- TURN서버의 IP와 포트넘버(TURN서버로부터 획득 가능)
- 이 모든 과정은 ICE라는 프레임워크 위에서 이루어지며, 두 개의 단말이 P2P연결을 가능하게 하도록 최적의 경로를 찾아주는 프레임워크
5. SDP
- WebRTC에서 스트리밍 해상도나, 코덱 등의 초기 인수를 설명하기 위해 채택한 프로토콜
6. Trickle ICE
- ICE는 후보들을 수집해서 한꺼번에 목록을 교환, 이는 SDP(제안응답모델)와 맞물리면서 단점으로 작용
- 비효율적 후보교환작업을 병렬 프로세스로 수행할 수 있게 만드는 것
7. 시그널링
- 위의 모든 과정
- RTCPeerConnection통신에 사용할 프로토콜, 채널, 미디어 코덱 및 형식, 데이터 전송 방법, 라우팅 정보와 NAT 통과 방법을 포함한 통신 규격을 교환하기 위해 두 장치의 제어정보를 교환하는 과정
- 아마존의 Kinesis Video Stream, 구글의 AppRTC
WebRTC의 한계
- 브라우저간 호환성.(사파리, 엣지)
- 시그널링 서버에 대한 명시적 표준 없음.(개발자의 자율성을 보장하지만 입문하기 쉽지 않음)
- UDP위에서 동작하므로 중요 파일 전송시 데이터 손실 문제 가능.(몇바이트지만 전체가 동작하지 않을수도..)
- TCP방식도 사용할 수 있지만 모든 브라우저가 지원하는 것은 아님
