WebRTC는 브라우저 간에 플러그인의 도움 없이 통신할 수 있도록 설계된 API이다.
즉 따로 소프트웨어를 설치할 필요가 없이 여러 종류의 데이터들을 교환할 수 있게 해준다.
WebRTC는 다음 그림과 같이 동작한다.
각각의 용어들에 대해서 알아보자.
그 전에 NAT에 대해서 알 필요가 있다.
만약 NAT에 대해서 모른다면 아래 포스팅을 보고 오는 것을 추천한다.
https://growth-coder.tistory.com/192
[Network] DHCP와 NAT
우리가 일반적으로 사용하는 IPv4의 경우 IP주소가 40억개쯤 되는데 시간이 많이 지남에 따라 거의 고갈되어 가고 있다. 이를 해결하기 위한 방안을 알아보려고 한다. DHCP (Dynamic Host Configuration Proto
growth-coder.tistory.com
SDP (Session Description Protocol)
SDP는 문자열 기반 프로토콜로 세션 정보, 미디어 정보, 네트워크 정보 등등을 전달하는데 사용된다.
- 송신자는 SDP offer를 생성하고 로컬에 저장 후 수신자에게 보낸다.
- 수신자는 SDP를 받아서 원격에 저장한다.
- 수신자는 SDP answer를 생성하고 로컬에 저장 후 송신자에게 보낸다.
- 송신자는 SDP를 받아서 원격에 저장한다.
위 과정을 진행하고나면 peer 끼리 양방향 소통을 할 수 있게 된다.
이 중간 과정을 중개해주는 서버가 바로 signaling server이다.
Signaling server
이 signaling server가 SDP 기반의 문자열 데이터와 아래에 나올 ICE 후보를 전달하여 peer끼리 통신을 할 수 있게 해준다.
이 signaling server에 WebSocket 기술이 주로 사용된다고 한다.
ICE (Interactive Connectivity Establishment)
peer끼리 서로 통신을 할 때 NAT이나 방화벽 때문에 직접적인 통신이 불가능할 때가 있다.
그럴 때 stun server와 turn 서버를 통해 통신에 필요한 데이터를 받아서 통신을 할 수 있게 된다.
STUN server (Session Traversal Utilities for NAT)
STUN server는 public IP를 알기 위한 용도로 사용한다.
한 peer는 다른 peer에게 데이터를 보내기 위해서 자기 주소를 알려줘야 한다.
그 때 먼저 STUN server로부터 자신의 public IP를 알아낸 뒤 이를 보내는 것이다.
그러나 만약 public IP 주소가 같다면 STUN server 이외에도 TURN server를 사용해야 한다.
TURN server (Traversal Using Relays around NAT)
같은 public IP를 사용하는 환경처럼 STUN server 만으로는 통신이 불가능할 수도 있기 때문에 TURN server를 추가로 사용한다.
우선 연결을 하려는 두 peer가 STUN server로부터 public IP 주소를 받고 private IP 주소와 함께 TURN server로 보낸다.
이 때 TURN server로 보낸 주소는 ICE 후보가 된다.
만약 A가 B에게 연결을 하려고 한다면 A가 TURN server에게 B에게 보내달라고 요청하고 TURN server는 모든 peer에 대해서 해당 요청을 보내는 것이다.
만약 B에게 그 요청이 닿았다면 B가 응답을 A에게 주는 것이다.
높은 확률로 연결에 성공할 수 있지만 부담이 심하다.
여기까지 WebRTC가 동작하는 방식에 대해서 알아보았다.
이제 WebRTC를 구현하는 세가지 방법 Mesh, MCU, SFU에 대해서 알아보자.
다음은 Mesh, MCU, SFU의 차이를 보여주는 그림이다.
위에서 보이는 Mesh는 다대다 통신에서 각각의 peer마다 모두 연결을 맺고 있기 때문에 클라이언트의 부담이 크다.
Mesh 방식은 1:1 통신에서 효율적인 방식이지만 위 사진처럼 1:N 혹은 N:N 방식에서는 비효율적인 방식이다.
MCU 방식은 uplink와 downlink가 하나씩 있는 모습을 확인할 수 있다.
당연하게도 client의 부담이 매우 적은 대신 server의 부담이 크다.
SFU 방식은 uplink 하나, downlink 여러개가 있어서 MCU 방식에 비해서 서버의 부담이 적다.
Media Server
Mesh 방식의 경우 통신하려는 인원이 많을수록 client의 부담이 커진다.
Mesh 방식은 twitch 처럼 스트리밍 서비스와 같이 1:N 구조에 적합한 방식은 아니다.
그래서 1:N이나 N:N에서는 주로 MCU 혹은 SFU 방식을 주로 사용한다.
그리고 이 방식에는 중간에 media를 전달해주는 media server가 필요하다.
media server를 사용해서 통신하는 과정은 아래 그림에 잘 나와있다.
그리고 KMS(Kurento Media Server)가 바로 Media server이다.
OpenVidu
KMS는 단순히 WebRTC 애플리케이션을 생성하기 위한 저수준 플랫폼이다.
우리가 여러 명이서 미디어를 주고받는 환경을 만들기 위해 signaling server, stun server, turn server, media server, application server를 전부 만든다면 상당히 번거로운 작업이 될 것이다.
OpenVidu는 무료 화상 채팅 플랫폼이다.
직접 내가 모든 리소스들을 구성하고 관리하는 것보다 OpenVidu를 사용하면 보다 쉽게 멀티 미디어 환경을 구성하고 관리할 수 있다.
openvidu는 client에서 사용할 수 있는 openvidu browser 라이브러리와 서버에서 사용할 수 있는 openvidu server 라이브러리를 제공한다.
이제부터 이 OpenVidu를 사용하여 화상 회의를 구현해보려고 한다.
'공부 > Spring' 카테고리의 다른 글
| [Spring/Kotlin] Java와 Kotlin의 의존성 주입 방법 비교 (0) | 2024.04.04 |
|---|---|
| [Spring][Android/Kotlin] FCM으로 안드로이드에 푸쉬 알람 보내기 (1) (0) | 2023.08.14 |
| [Spring] LocalDate, LocalDateTime의 serializer와 deserializer 커스텀하기 (Json과 LocalDate 혹은 LocalDateTime 변환) (0) | 2023.08.07 |
| [Spring] 스프링 부트 Redis를 사용하여 refresh token 저장하기 (2) - docker-compose 사용법 (0) | 2023.07.17 |
| [Spring][Redis] 스프링 부트 RedisRepository 사용법 (0) | 2023.07.15 |
댓글