-
Notifications
You must be signed in to change notification settings - Fork 2
WebRTC
웹 애플리케이션과 사이트가 중간자 없이 브라우저 간에 오디오나 영상 미디어를 포착하고 마음대로 스트림 할 뿐 아니라, 임의의 데이터도 교환할 수 있도록 하는 기술 즉, 드라이버나 플러그인 없이 웹 브라우저 간에 P2P통신을 통해 오디오 , 미디어 , 파일 등의 데이터를 교환할 수 있는 기술.
P2P이기 떄문에 중개 서버를 거치지 않음 -> 빠른 속도가 보장됨 HTTPS가 강제 -> 중간자 공격에 대해 보안
- 구글이 주도한 오픈소스 프로젝트 기반 웹 표준
- 크롬, 파이어폭스, 오페라는 웹 표준을 잘 따르기 때문에 호환성이 높음
- 사파리는 애플의 정책상 지원 설정도 적고 호환성도 떨어짐
- WebRTC는 1.0 버전이 표준이지만 준수하는 브라우저가 많지 않음 -> 벤더 프리픽스가 많이 붙어있음
WebRTC에는 크로스 브라우징 이슈가 존재하고 이를 해결하기 위해 adapter.js 라이브러리를 함께 사용하는게 필수.
adpater.js에서 폴리필을 이용해 크로스 브라우징 이슈를 사전에 처리할 수 있음
또한 벤더 프리픽스를 신경 쓸 필요없이 동일한 api를 호출할 수 있게 해줌
일반 컴퓨터에는 공인 IP가 없으며 NAT,DHCP 때문에 공인 IP를 안다고 하더라도 사용자를 특정할 수 없음 (하나의 IP에 여러 사용자가 있을 수 있기 떄문에)
따라서 해당 공인 IP에 연결된 사설 IP 주소까지 알아야 사용자를 특정할 수 있음
즉, 2개의 브라우저가 서로 통신하기 위해선 라우터의 IP주소(공인)와 포트번호(사설)을 알아야 함.
이처럼 NAT를 통과해 2개의 브라우저가 연결할 방법을 찾는 과정을 NAT traversal이라 함.
즉 NAT에서 각자의 정확한 IP 주소를 찾아내는 과정.
NAT traversal 작업은 STUN 서버에 의해 이루어짐.
STUN은 자신의 공인 IP 주소와 포트번호를 확인하는 프로토콜.
STUN 서버는 자신의 공인 IP주소와 포트 번호를 반환해주는 서버.
따라서 WebRTC 연결을 하기 전 STUN 서버로 요청을 보내 Peer들이 서로 연결할 수 있도록 공인 IP와 포트를 찾아낸다.
STUN 서버를 이용하더라도 방화벽 정책, 보안 정책때문에 자신의 IP 주소를 찾아낼 수 없는 경우가 발생할 수 있음.
따라서 이 경우엔 TURN 서버를 대안으로 사용하여 자신의 IP 주소를 찾아 냄.
TURN 서버의 경우 중개 서버를 이용하는 방법.
P2P통신이 아닌 중개서버를 거치므로 네트워크 지연이 무조건 발생하지만 STUN 방식이 안되는 경우 사용할 수 있는 유일한 방법.
NAT traversal 과정은 ICE라는 프레임워크 위에서 이루어짐. ICE는 두 개의 단말이 P2P 연결을 가능하도록 최적의 경로를 찾아주는 프레임 워크.
STUN, TURN 서버를 통해 얻어낸 네트워크 주소들을 후보라고 부르며 이 후보들에게서 최적의 경로를 찾아줌.
따라서 ICE 프레임워크를 통해 두 단말간의 p2p 통신을 위한 최적의 네트워크 주소를 찾아냄.
WebRTC에서 교환하는 멀티미디어 컨텐츠의 형식을 설명하기 위해 채택한 프로토콜.
해상도, 수신여부, 코덱 등의 정보를 담음.
제안 응답 모델을 가지고 있으며 Peer 가 어떤 미디어 스트림에 대한 제안을 하면 상대방으로 부터 응답이 올때까지 기다림.
만약 Peer가 응답을 받게 된다면 ICE 프레임워크 상에서 최적의 경로를 결정하는 프로세스가 발생.
최적의 경로를 설정하면 P2P 연결을 위한 모든 합의가 완료됨. (경로, 미디어 타입 협의 완료)
그 이후 P2P 연결이 완전히 활성화 되고 데이터 스트림의 엔드포인트가 생성되어 양방향 통신이 가능해짐.
만약 TURN 서버를 사용할 때는 P2P를 통해 데이터를 연결할 필요가 없으므로 데이터를 중개하는 공용 TURN 서버를 알기만 하면 된다.
위에서 말한 모든 과정(NAT traversal, SDP)을 일컬어 시그널링이라 함.
시그널링은 WebRTC 자체에서 지원하는 기능이 아니며 개발자가 미리 준비해야하며 딱 한가지로 정해진 방법이 없음.
그 이유는 두 단말이 어떤 방식으로 연결될 지 예측하는 게 불가능 하기 때문.
일반적으로 두개의 장치를 연결할 수 있는 시그널링 서버를 직접 구축하거나 외부 솔루션을 적용할 수 있음.
만약 직접 시그널링 서버를 직접 구축한다면 웹 소켓이나 SSE를 적용할 수 있음.