9. WebRTC

Notice

Recent Posts

Recent Comments

Link

프로젝트 유튜브 영상들

« 2024/11 »
일	월	화	수	목	금	토
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30

Tags more

Archives

Today

Total

관리 메뉴

센로그

9. WebRTC 본문

CS/풀스택서비스네트워킹

9. WebRTC

seeyoun 2023. 12. 8. 11:44

◆ Peer-to-Peer vs Client-Server

우리가 지금부터 볼 WebRTC는 웹 기반 실시간 P2P 통신 기법이다.

WebRTC(Web Real-Time Communication)은 웹 애플리케이션과 사이트가 중간자 없이 브라우저 간에 오디오나 영상 미디어를 캡쳐하고 마음대로 스트리밍 할 뿐 아니라, 임의의 데이터도 교환할 수 있도록 하는 기술임

들어가기 전에 P2P 방식과 클라-서버 방식이 어떻게 다른지 정리해보자.

■ P2P

P2P 통신의 사전적 의미는, 클라이언트들이 별도의 서버 없이 서로 통신을 하는 것임.

(사전적이라는 건, 요즘엔 아예 서버를 안쓰는 경우는 거의 없기 때문. 이따가 설명할 것임)

만약 6개의 노드가 있는 경우, 한 컴퓨터당 5개의 연결을 유지해야 함.
내 정보를 보내고 싶으면 5개에 동시에 다 보내줘야 함.

■ Client-Server

반면 클라이언트-서버 스킴은 중앙집중화된 서버가 있어서, 이를 통해 클라이언트들이 정보를 주고받는 구조.

※ 블록체인
P2P 방식은 사실 별로 인기 없었음. 그러다가 이 기술을 사용해서 히트를 친 게 블록체인.

1. 누군가가 결제를 하고, 결제에 대한 파일(이 결제가 제대로 이루어졌는지에 대한 정보)을 만듦.

2. 블록체인에서는 이 결제에 대한 정보를 쪼개서 주변에다가 뿌버림.
즉 이 파일은 중앙집중화된 은행 서버 같은 곳에 보관되는 게 아니고, 그냥 여기저기 전 세계에 뿌려지는 것

3. 따라서 (이 결제가 제대로 된 건지에 대한 정보가) 여러 곳에 너무 많이 흩어져 있기 때문에, 누구 하나가 이걸 변조했더라도 다른 사람들하고 비교하면 가짜인지가 바로 드러남. 집단지성에 의해서 신뢰할 수 있는 것.

물론 내가 남에게 결제 정보를 뿌리는 만큼, 나 역시 다른 사람들의 결제 정보를 받을 테니, 이런 경우엔 본인과 상관없는 거래에 본인의 CPU와 디스크와 파워가 낭비될 것임. 그러나 나도 이에 대한 대가를 내가 거래에 참여할 때 받을 수 있는 것이다.

◆ WebRTC란?

앞쪽에서 다뤘던 ZMQ 같은 건 보통 로컬 컴퓨터 내 프로세스 간의 통신이나, 로컬 네트워크 안에 있는 컴퓨터끼리의 통신에 사용하는 기술이었음.

WebRTC는 이름에서 보다시피, 다른 네트워크에 있는 컴퓨터들 끼리의 웹 기반 실시간 통신에 사용됨.

가장 대표적인게 구글 미팅. 별도의 SW를 깔지 않더라도, 웹 브라우저 만으로 실시간 음성/화상 전화를 할 수 있음.

UDP 기반 P2P 통신으로 작동한다.

앞으로 살펴볼 WebRTC의 주요 구성요소는 다음과 같다.

◆ WebRTC API의 목적

웹 기반의 실시간 커뮤니케이션

WebRTC(Web Real-Time Communication)은 웹 애플리케이션과 사이트가 중간자 없이 브라우저 간에 오디오나 영상 미디어를 캡쳐하고 마음대로 스트리밍 할 뿐 아니라, 임의의 데이터도 교환할 수 있도록 하는 기술임
WebRTC를 구성하는 일련의 표준들은 플러그인이나 제3자 소프트웨어 설치 없이 종단 간 데이터 공유와 화상 회의를 가능하게 함

이를 위하여 WebRTC는 상호 연관된 API와 프로토콜로 구성되어 함께 작동함

대표적인 3개의 API를 포함한 JavaScript APIs로 이루어짐

RTCPeerConnection( )
연결 설정을 위한 API
getUserMedia( )
비디오 및 오디오 캡쳐를 위함
RTCDataChannel( )
데이터를 주고받기 위함

◆ ICE (Interactive Connectivity Establishment)

ICE는 브라우저가 peer를 통한 연결이 가능하도록 하게 해주는 프레임워크.

p2p 연결 과정을 도와주는 프레임워크이다.

p2p 연결하는데 도움이 필요해? 그냥 피어끼리 연결하면 되는 거 아니야? ㄴㄴ 안됨.

왜 안되냐?

연결을 시도하는 방화벽을 통과해야 할 수 있음
- private address가 방화벽을 뚫고 public으로 나가는 게 쉽지가 않음.
단말에 Public IP가 없다면 유일한 주소 값을 할당해야 할 필요도 있음
- private address를 사용하는 본인은, 자신의 주소가 NAT/PAT를 통과했을 때 어떤 public IP로 바뀔지 알 수가 없음.
라우터가 peer간의 직접 연결을 허용하지 않는 경우도 있음.
- 이런 경우 데이터를 릴레이 해야 함

이런 문제점들이 있기 때문에, 연결을 도와줄 서버가 반드시 필요해짐.

ICE는 이러한 작업을 수행하기 위해 STUN 서버와 TURN 서버 둘다 혹은 하나의 서버를 사용한다!

◆ STUN (Session Traversal Utilities for NAT)

두 컴퓨터가 인터넷을 통해 통신하려면 private IP로는 할 수 없음. 본인과 상대의 public IP 주소를 알아야만 함.

그러나 private IP가 NAT/PAT를 거쳐 바깥으로 나갈때 내 주소가 어떻게 변하는지는 본인도 모름!!

→이걸 알려주는 게 STUN 서버

STUN은 통신 요청자(본인)의 Public IP를 확인하거나, 본인의 라우터가 peer 간의 직접 통신에 제약을 두고 있는지를 확인하기 위한 프로토콜임
Client로 부터 요청은 받은 인터넷 상의 STUN 서버는, Client의 Public IP 주소와 함께, 해당 Client가 라우터의 NAT 뒤에 위치한 상황에서 통신을 위한 접근이 가능한지 여부를 알려줌

◆ NAT

그럼 STUN 서버를 사용해서 내 public IP를 알면 이제 문제없이 p2p 통신 할 수 있냐? ㄴㄴ아님.

NAT에 관한 문제가 남아있다.

NAT는 Private IP를 사용하는 Client가 Public IP의 사용이 가능하도록 하는 기술로, 송수신되는 메시지의 Private IP 와 Public IP 주소 값을 실시간으로 매핑/번역 함
어떠한 라우터들은 NAT를 통한 네트워크 연결에 제한을 갖고 있기도 함.
- 예를 들어, symmetric NAT 방식을 지원하는 라우터는, 이전에 연결한 적이 있는 연결들(혹은 미리 설정된 연결들)에 대해서만 NAT를 지원함
따라서, STUN서버에 의해 공개 IP주소를 발견한다고 해도 모두가 연결을 할 수 있는 건 아니라는 것이다.
→ 이를 위해 TURN이 필요함

◆ TURN (Traversal Using Relays around NAT)

메시지를 전달할 때 Symmetric NAT 제한 등을 우회하기 위해서, peer와 peer 사이에서 메시지를 대신 전달해 주는, 공인 IP 주소를 가진 릴레이 서버

NAT가 보안 문제 따위의 이유로 연결을 제한하는 경우, peer끼리 바로 연결하지 못하는 경우가 생긴다.
이런 경우 TURN 서버와 클라이언트를 연결하고 모든 정보를 그 서버를 통해 전달함으로써 Symmetric NAT 제한 등을 우회할 수 있다.
- TURN 서버에 연결을 한 후, 모든 peer들에게 'TURN 서버에게 패킷을 보내고, 다시 나에게 전달해달라'고 해야함
- 이 릴레이를 경유함으로써 다른 peer들과 연결하는 경로를 뚫은 것임.
- 이것은 명백히 오버헤드가 발생하므로 이 방법은 다른 대안이 없을 경우만 사용하게 됨

◆ SDP (Session Description Protocol)

서로 다른 네트워크에 있는 2개의 디바이스들을 통신하기 위해서는, 각 디바이스들의 위치(IP) 발견 및 미디어 포맷협의가 필요하다. 이 프로세스를 시그널링 signaling 이라 부른다.

이때 주고받는 메시지 포맷이 SDP 이다.

여기에 해상도, 코덱, 암호화 여부 및 방법 등 미디어에 대한 다양한 정보를 실어보낸다.

연결 시 '내가 이런 세션이고 이렇게 통신할거다~' 를 정해야 할텐데, 이에 관한 정보를 설명하는 것을 의미함.

기술적으로 보자면 SDP는 프로토콜이 아님.
그러나 디바이스 간의 미디어를 공유하기 위한 연결 정보 포맷을 제공한다.

WebRTC에서 SDP는 미디어 스트리밍, 네트워크 주소 및 코덱 정보를 포함한, 두 Peer 간의 통신 세션 매개 변수를 정하는데 사용 된다. 과정은 다음과 같다.

WebRTC peer 간 공유하는 세션 정보를 담은 SDP 오퍼를 생성하고, 다른 peer 에게 전달한다.
수신 peer는 SDP 오퍼를 분석하고, 수신 할 수 있는 미디어 유형과 연결 할 수 있는 네트워크 주소가 포함된 SDP 응답을 반환한다.
SDP 제안/응답을 교환하고, 세션 세부 정보 제공에 동의하면, 협상된 매개 변수로 peer간 연결을 설정한다

결론적으로 SDP는 두 피어 간의 연결 설정을 하는데 사용되는 WebRTC 통신 세션 필수 구성 요소이다.

◆ WebRTC 동작 구성 예시

WebRTC가 어떻게 동작하는지를 담은 그림이다.

public IP를 알려주는 게 STUN 서버이고, peer간 메시지를 릴레이해주는 서버가 TURN 서버이다.
그런데 이들은 서로를 식별하거나 트래픽을 주고받는 이야기를 한 것이지, 어떻게 연결하고 어떤 미디어를 주고 받을지, 압축을 어떻게 할 등 실질적 미디어 교환 포맷이 협의되지는 않았다.
시그널링 서버는 이런 걸 해주는 서버이다.
두 디바이스들 사이에 WebRTC 커넥션을 만들기 위해, 인터넷 네트워크에서 그 둘을 연결 시키는 작업을 한다.
- 시그널링 서버를 통해 SDP 형태의 프레임을 주고받아서, 연결 설정 및 해지를 한다.

이처럼 WebRTC가 p2p 기반으로 동작함에도, 서로를 식별하거나 연결 설정하는 부분에는 대부분 서버가 관여함.
단 실제 미디어에 관한 트래픽은 직접 peer 간에 주고받게 하는 것. (여기 턴 서버가 등장하기는 했지만 주로 턴 서버 없이 주로 직접 주고받음)

◆ WebRTC 장점

Near Real-time. 본질적으로 지연이 적다.
웹 기반으로 동작하기 때문에 Platform이나 Device에 독립적이다.
오픈소스이며, 표준화 되어있다.
네트워크 컨디션에 적응할 수 있다.
Simulcasting: 보내는 쪽에서 다양한 품질(해상도 등)의 트래픽들을 모두 보낸다. 받을 때에 본인이 받고 싶은 것만 받아서 보여줄 수 있다.

◆ WebRTC 단점

Scalability. 확장성이 떨어진다.
WebRTC는 각 peer 간에 직접적인 연결을 설정하므로, 사용자 수가 증가할수록 P2P 연결의 수도 증가한다.
많은 peer 간의 연결을 관리하려면 네트워크 및 자원 사용에 있어서 복잡성과 부하가 증가한다.
Broadcast Quality가 떨어질 수 있다.
화질이 구리다는 뜻.