면접 준비

1. 1분 자기소개

 

2. webRTC

1. WebRTC란 무엇일까?

• WebRTC(Web Real-Time Communication)란 웹 브라우저 환경 및 Android, IOS 애플리케이션에서도 사용 가능한 비디오, 음성 및 일반 데이터가 피어간에 실시간으로 전송되도록 지원하는 오픈 소스이다.
• 공개 웹 표준으로 구현되며 모든 주요 브라우저에서 일반 JavaScript API로 제공한다. (Apple, Google, Microsoft 및 Mozilla가 지원)

2. WebRTC의 기술 및 프로토콜 소개

2-1. ICE(Interactive Connectivity Establishment)

• 브라우저가 peer를 통한 연결이 가능하도록 해주는 프레임 워크이다.
• peer간 단순 연결 시 작동하지 않는 이유들
  • 연결을 시도하는 방화벽을 통과해야 함
  • 단말에 Public IP가 없다면 유일한 주소값을 할당해야 한다.
  • 라우터가 peer간의 직접 연결을 허용하지 않을 때 데이터를 릴레이해야 하는 경우
• ICE는 위의 작업들을 수행하기 위해 STUN과 TURN 서버 둘 다 혹은 하나의 서버를 사용한다.

2-2. STUN(Session Traversal Utilities for NAT) 서버

• 클라이언트 자신의 Public Address(IP:PORT)를 알려준다.
• peer간의 직접 연결을 막는 등의 라우터의 제한을 결정하는 프로토콜 (현재 다른 peer가 접근 가능하지 여부 결정)
• 클라이언트는 인터넷을 통해 클라이언트의 Public Address와 라우터의 NAT 뒤에 있는 클라이언트가 접근 가능한지에 대한 답변을 STUN서버에 요청한다.
•  

2-3. NAT(Network Address Transilation)

• 단말에 공개 IP(Public IP) 주소를 할당하기 위해 사용한다.
• 라우터는 공개 IP 주소를 갖고 있고 모든 단말들은 라우터에 연결되어 있으며 비공개 IP주소(Private IP Address)를 갖는다.
• 요청은 단말의 비공개 주소로부터 라우터의 공개 주소와 유일한 포트를 기반으로 번역한다. 이 덕분에, 각각의 단말이 유일한 공개 IP 없이 인터넷 상에서 검색 가능하다.
• 몇몇의 라우터들은 Symmetric NAT이라고 불리우는 제한을 위한 NAT을 채용한다. 즉, peer들이 오직 이전에 연결한 적 있는 연결들만 허용한다. 따라서 STUN서버에 의해 공개 IP주소를 발견한다고 해도 모두가 연결을 할수 있다는 것은 아니다. (위의 설명에서 STUN 서버에 다른 peer가 접근 가능한지 여부를 요청하는 이유)
• 이를 위해 TURN이 필요하다.

• NAT: 사설 IP를 공인 IP로 변경에 필요한 주소 변환 서비스입니다.

2-4. TURN(Traversal Using Relays around NAT) 서버

• TURN 서버와 연결하고 모든 정보를 그 서버에 전달하는 것으로 Symmetric NAT 제한을 우회하는 것을 의미한다.
• 이를 위해 TURN 서버와 연결을 한 후 모든 peer들에게 저 서버에 모든 패킷을 보내고 다시 나(TURN서버)에게 전달해달라고 해야 한다.
• 명백히 오버헤드가 발생하므로 이 방법은 다른 대안이 없을 경우만 사용해야 한다.

• SDP(Session Description Protocol)
  • 해상도나 형식, 코덱, 암호화등의 멀티미디어 컨텐츠의 연결을 설명하기 위한 표준이다.
  • 두 개의 peer가 다른 한쪽이 데이터가 전송되고 있다는 것을 알게 해준다.
  • 기본적으로 미디어 컨텐츠 자체가 아닌 컨텐츠에 대한 메타데이터 설명이다.
  • 기술적으로 보자면 SDP 는 프로토콜이 아니다. 그러나 데이터 포멧은 디바이스간의 미디어를 공유하기 위한 연결을 설명하기 위해 사용한다.

1. 서론

저번 포스트에서 작성했듯이 WebRTC는 ICE, STUN, TURN, SDP로 작동된다. 이 서버들과 프로토콜로만 작동이 된다면 매우 간편하겠지만 현실은 그렇지 않다. P2P 연결을 완성시키기 위해서는 개발자가 peer간의 offer와 answer를 통한 session 정보를 중계해주는 서버를 만들어줘야한다. 하지만 P2P 연결로 3인, 4인 그리고 그 이상의 인원의 데이터 송수신을 지원하게 되면 클라이언트 측면에서의 과부하가 심하게 오기 때문에 권장하지 않는다. 이러한 문제의 해결책으로 나온 것이 SFU와 MCU 방식의 미디어 서버를 두는 것이다.

2. 서버의 종류

WebRTC를 위해 개발자가 구현할 수 있는 서버는 크게 세 종류가 있다. Signaling, SFU 그리고 MCU이다. 그렇다면 하나씩 알아보도록 하자.

2-1. Signaling 서버(위 그림의 Mesh)

• 특징
  • peer 간의 offer, answer라는 session 정보 signal만을 중계한다. 따라서 처음 WebRTC가 peer간의 정보를 중계할 때만 서버에 부하가 발생한다.
  • peer간 연결이 완료된 후에는 서버에 별도의 부하가 없다.
  • 1:1 연결에 적합하다.
• 장점
  • 서버의 부하가 적기 때문에 서버 자원이 적게 든다.
  • peer간의 직접 연결로 데이터를 송수신하기 때문에 실시간 성이 보장된다.
• 단점
  • N:N 혹은 N:M 연결에서 클라이언트의 과부하가 급격하게 증가한다. 예를 들어, 위의 그림같이 5인이 WebRTC 연결을 한다고 가정하면 Uplink(나의 데이터를 연결된 다른 사용자에게 보내는 갯수) 4개, Downlink(연결된 다른 사용자의 데이터가 나에게 들어오는 갯수) 4개로 한 명당 총 8개의 link를 유지하며 데이터를 송수신하게 된다. (그림에서는 데이터를 주고 받는 것을 하나의 링크로 표현했다.)

2-2. SFU(Selective Forwarding Unit) 서버

• 특징
  • 종단 간 미디어 트래픽을 중계하는 중앙 서버 방식이다.
  • 클라이언트 peer간 연결이 아닌, 서버와 클라이언트 간의 peer를 연결한다.
  • 1:1, 1:N, N:N 혹은 N:M 등 모든 연결 형식에서 클라이언트는 연결된 모든 사용자에게 데이터를 보낼 필요없이 서버에게만 자신의 영상 데이터를 보내면 된다.(즉, Uplink가 1개다.)
  • 하지만 1:N, N:N 혹은 N:M 형식이라면 상대방의 수만큼 데이터를 받는 peer를 유지해야한다.(Downlink는 P2P(Signaling서버)일 때와 동일하다.)
  • 1:N 형식 또는 소규모 N:M 형식의 실시간 스트리밍에 적합하다.
• 장점
  • 데이터가 서버를 거치고 Signaling 서버(P2P 방식)를 사용할 때 보다 느리긴하지만 비슷한 수준의 실시간성을 유지할 수 있다.
  • Signaling 서버를 사용하는 것보다 클라이언트가 받는 부하가 줄어든다.
• 단점
  • Signaling 서버보다 서버 비용이 증가한다.
  • 대규모 N:M 구조에서는 여전히 클라이언트가 많은 부하를 감당한다.

2-3. MCU(Multi-point Control Unit) 서버

• 특징
  • 다수의 송출 미디어를 중앙 서버에서 혼합(muxing) 또는 가공(transcoding)하여 수신측으로 전달하는 중앙 서버 방식이다. 예를 들어, 5인이 WebRTC 연결을 한다면 자신을 제외한 다른 4인의 video 데이터를 하나의 video 데이터로 편집하고, audio 데이터도 마찬가지로 편집하여 한 명에게 보낸다. 이 작업을 남은 4명에게도 동일하게 적용한다.
  • 클라이언트 peer간 연결이 아닌, 서버와 클라이언트 간의 peer를 연결한다.
  • 모든 연결 형식에서 클라이언트는 연결된 모든 사용자에게 데이터를 보낼 필요없이 서버에게만 자신의 영상 데이터를 보내면 된다.(즉, Uplink가 1개다.)
  • 모든 연결 형식에서 클라이언트는 연결된 사용자의 수와 상관없이 서버에게서 하나의 peer로 데이터를 받으면 된다.(즉, Downlink가 1개다.)
  • 중앙 서버의 높은 컴퓨팅 파워가 요구된다.
• 장점
  • 클라이언트의 부하가 현저히 줄어든다.(항상 Uplink 1개, Downlink 1개로 총 2개)
  • N:M 구조에 사용 가능하다.(적합...하다고 할 수 있을 지는 잘 모르겠다. 다른 서버들보다는 적합하다.)
• 단점
  • WebRTC의 최대 장점인 실시간성이 저해된다.
  • video, audio를 결합하는 과정에서 비용이 많이 든다.

3. 느낀 점

항상 느끼지만 정답인 기술은 없다. 항상 상황에 맞게 최적의 기술을 사용하고 구현해내는 것이 개발자의 일인 것 같다. 늘 새로운 것을 배우고 다음 프로젝트에서 비슷한 업무를 맡았을 때 여러 가지 선택의 폭을 갖게 된다면 그것만으로도 충분히 공부한 의미가 있다고 생각한다. WebRTC를 공부하는 사람들에게 이 포스팅이 조금이나마 도움이 됐으면 한다.

 

3. socket.Io

4. CI/CD

5. mocha

6. HTTPS AWS

7. 토폴로지

8. 트러블슈팅