webRtc
: Peer to peer communication(브라우저와 브라우저 간 연결), suited for 비디오 오디오 실시간 채팅. UDP(User Data Program, tcp와는 다르게 port정보 정도만 들어있어서 빠름) 기반.
통신과정
우리는 네트워크에서 정보를 주고 받을때 public ip가 필요하다. 하지만 회사망 처럼 private ip를 쓰는 경우, public ip를 제공받아야 한다. 이때 필요한 것이 NAT이다(Network Address Translation). 참고로 public ip는 인터넷에 접근될때 부여되고 사용하지 않으면 다른 사용자에게 다시 할당 된다.
webRtc를 통해 서로 정보를 주고 받을때, 상대의 ip가 동일해야한다.
그러나 nat에 의해 매번 새로운 public ip가 할당되면 곤란해지게 되는 것.
그래서 ICE('I'nteractive 'C'onnectivity 'E'stablishment.)라는 프레임워크를 사용한다.
ICE를 사용하면, nat가, 두 peer사이에 통신가능한 모든 포트를 열어두게 된다. 즉, 완전한 정보를 얻게 된다.
ICE는 STUN(Session Traversal Utilities for NAT)이라는 서버를 이용해서 작동한다. STUN은 쉽게 말해 해당 peer로 public ip 주소를 보내는 역할을 한다.
최종적으로, ICE는 가장 최적의, 가장 빠른 ip주소 candidate로 선별하고 이중 가장 best ip를 뽑아 연결에 사용한다.
sdp는 무엇이냐?? sdp(session description protocol)는 프로토콜이다. sdp를 이용해 주고받을 미디어와 네트워크에 대한 정보를 공유한다.
어느 한쪽에서 offer sdp를 보내면 다른 쪽에서 answer sdp를 보내 연결에 동의 한다.
그럼 각자의 peer가 수집한 ICE후보중 최적의 후보를 고르는 과정과 , 패킷을 보내봄으로써 최적의 ip를 추리는 과정을 거치게 된다.
이렇게 선정되면 ip주소, 포트, 미디어 정보가 합의되면서 최종 연결된다.
sdp는 third party 에 의해 저장되고 통신에 사용되는데, 이것을 signaling이라고 한다.
통신에 의한 정보만 signaling 되고 실제 음성, 영상 통신은 양쪽 브라우저에 의해 제어된다. signaling은 webRtc의 스펙에 없기 때문에 따로 구현해야한다., firebase나 web socket 등으로 구현 가능하다.
Trickle ICE
ICE를 이용해 최적의 ip를 찾아내는 과정에서, 양쪽 모두에서 완료되어야만 최종적으로 best ip를 찾아낸다. 또한 sdp 교환 과정과 맞물리게 될 수 있고, 네트환경에 따라 지연이 될 수 있다.
즉 동기적으로 이루어지면서 속도가 느려질 수 있다는 것. 이 동기적 ICE 후보찾기 과정을 비동기적으로 바꾸는 게 Trickle ICE이다. 되도록 활성화하는게 좋다고 그런다.
built-in javascript만으로 구현하는 방법은 아래 영상 참고
https://www.youtube.com/watch?v=WmR9IMUD_CY
만약 built-in이 이해하기 힘들다면, peer.js를 써보길!
https://www.youtube.com/watch?v=DvlyzDZDEq4
아래 링크에서는 NAT / ICE / STUN에 대해서 더 알기 쉽게 설명해놓았으니 참고
https://gh402.tistory.com/45
https://velog.io/@gojaegaebal/210307-%EA%B0%9C%EB%B0%9C%EC%9D%BC%EC%A7%8090%EC%9D%BC%EC%B0%A8-%EC%A0%95%EA%B8%80-%EB%82%98%EB%A7%8C%EC%9D%98-%EB%AC%B4%EA%B8%B0-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-WebRTC%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%802-ICE-SDP-Signalling
