Tools & Libraries/WebRTC

WebRTC로 화상채팅 구현하기 1 (WebRTC와 용어 정리)

대기업 가고 싶은 공돌이 2024. 8. 7. 03:57

WebRTC

webRTC(Web Real-Time Communications)란, 웹 어플리케이션, Android, IOS 환경에서

별도의 소프트웨어 없이 음성, 영상 미디어, 텍스트, 파일 같은 데이터를 피어끼리 주고받을 수 있게 만든

오픈소스이다.

 

비디오, 영상 미디어 등의 데이터가 P2P 방식으로 전송되도록 지원한다.

 

문제점

P2P 방식으로 데이터를 주고받기 위해서는 주고 받는 각 피어의 public IP를 알고 있어야 한다.

그러나 public IP 주소는 NAT에 의해 계속 바뀌기 때문에 동일한 public IP로는 통신을 지속할 수 없다는 문제점이 발생한다. 이를 해결하기 위해 STUN 서버와 TURN 서버를 사용해야 한다.

 

STUN SEVER

STUN(Session Traversal Utilities for NAT)

 

STUN이란 public IP를 찾거나, 피어 간의 직접 연결을 막는 등 라우터의 제한을 결정하는

프로토콜을 의미한다.

 

사용자는 다른 피어의 ip 주소에 접근할 수 있을지를 판단하기 위해
STUN 서버에 요청을 보낸다.

 

STUN 서버에서는 요청을 보낸 사용자의 public IP 주소와 포트 번호를 반환한다.

(사용자는 private IP 주소만 알지 NAT의 public IP 주소는 알지 못 하기 때문이다.)

 

이제 STUN 서버를 통해 알아낸 자신의 public IP 주소를 통해 다른 피어와 연결을 시도할 수 있다.

 

출처: Mozilla

 

 

TURN SERVER

몇몇의 라우터들은 Symmetric NAT 라고 불리는 제한을 걸기 위한 NAT를 사용한다.

이전에 연결한 적 있거나 특수한 제한을 걸어, 특정 피어들의 연결만 허용시키는 NAT를 사용하는 경우가 있다는 말이다.

 

Traversal Using Relays around NAT(TURN)은 TURN 서버를 통해 두 피어를 연결 시키고

모든 정보를 TURN 서버를 통해 전달하는 것으로 Symmetric NAT 제한을 우회하는 프로토콜을 의미한다.

 

당연히 모든 패킷을 TURN 서버에게 보내기 때문에 오버헤드가 굉장히 크다.

출처 : Mozilla

 

SIGNALING SERVER

시그널링이란?

  • 서로 다른 네트워크에 있는 디바이스들을 통신하기 위해서는, 각 디바이스들의 IP주소 및 미디어 포맷 협의가 필요하다. IP 주소와 미디어 포맷을 결정하는 과정을 시그널링이라 부르고, 시그널링 이후 각 디바이스들을 특정 서버에 연결시킨다.

시그널링 서버란?

  • 각 디바이스들의 연결을 위해 서로의 정보들이 각각의 디바이스들에게 전달돼야 한다.
    해당 역할을 중계해주고, 각 디바이스를 연결해주는 서버가 바로 시그널링 서버이다. 

시그널링 흐름

  1. Exchanging session description
    1. A와 B는 화상통화를 위해 시그널링 프로세스를 진행하려 한다.
    2. A는 B에게 화상통화를 요청한다. 
    3. A가 Offer라는 이름의 세션 정보를 만든다
      Offer는 SDP(session description protocol) 포맷으로 만들어졌으며 이는 B에게 전달돼야한다.
    4. B는 Offer를 받고 문제가 없다면 Answer을 똑같이 SDP 포맷으로 만들어 A에게 전달해야한다.

      해당 과정이 끝나면 A와 B는 서로의  세션 정보와 어떤 데이터 타입이 사용될지를 알게 된다.
      하지만 아직 미디어 데이터를 어떻게 전송 해야할지 모른다. 
      이 문제를 해결하기 위해 ICE(Interacvice Connectivity Establishment)가 사용된다.

SDP 형식

출처: Mozilla

 

2. Exchanging ICE candidates

ICE candidate는 위에서 설명했던 것 처럼 통신을 할 수 있는 방법을 설명한다.

 

ICE candidate 형식

출처: Mozilla

통신을 할 수 있는 방법이라 함은 당연히 ip 주소와 port 번호의 조합을 의미한다.

 

각 디바이스는 검색되는 순서대로 ice candidate를 보내고, 두 디바이스가 서로 호환되는 candidate가 나타났다면,

미디어는 통신을 시작한다. 만약 나중에 더 나은 방법이 있다면, 그 스트림은 필요에 따라 포맷을 바꿀 수도 있다.

 

ice candidate는 

  1. 로컬 네트워크에서 얻은 사용자의 ip 주소와 port 번호
  2. STUN 서버를 통해 얻은 퍼블릭 ip 주소와 port 번호
  3. TURN 서버를 통해 얻은 주소

와 같이 구성된다.

 

  candidate: "candidate:842163049 1 udp 1677729535 192.168.1.2 53832 typ srflx raddr 192.168.1.2 rport 53832 generation 0 ufrag EEtu network-id 3 network-cost 10",

candidate의 예시는 다음과 같으며, tcp, udp, ip주소, 포트넘버, 커넥션 타입 등등을 제안한다.

 

3. 흐름 정리

  1. A가 B에게 영상 통화를 요청한다.
  2. A는 SDP Offer를 생성하여 video-offer 타입의 메세지를 B에게 보낸다.
  3. B는 SDP Offer를 수신하고, SDP Answer를 생성하여 A에게 반환한다.
  4.  이후 A와 B 둘 다, 가능한 ice candidate를 수집한다.
  5. 가능한 ice candidate가 나올 때마다 서로에게 ice candidate를 전송한다.
  6. ice candidate 전송이 끝난 후 서로는 수집한 ice candidate를 조합해보며 가능한 쌍을 찾는다.
  7. 연결을 시도하고 만약 연결이 성공했다면 미디어 스트림 교환이 시작된다.

 

 

다음 포스트에는 WebRTC 구현 방식에 대해 다뤄 보겠다.

 

참고한 블로그 및 사이트:

https://jmdwlee.tistory.com/17   https://medium.com/@hyun.sang/webrtc-webrtc%EB%9E%80-43df68cbe511     https://web.dev/articles/webrtc-infrastructure?hl=ko      https://velog.io/@kkj53051000/WebRTC%EC%99%80-%EC%8B%9C%EA%B7%B8%EB%84%90%EB%A7%81%EC%9D%B4%EB%9E%80-%EC%8B%9C%EA%B7%B8%EB%84%90%EB%A7%81-Mozilla-%EB%B6%84%EC%84%9D     https://developer.mozilla.org/ko/docs/Web/API/WebRTC_API/Signaling_and_video_calling

'Tools & Libraries/WebRTC'의 다른글

  • 현재글WebRTC로 화상채팅 구현하기 1 (WebRTC와 용어 정리)

티스토리툴바