[WebRTC] 개념 및 용어 정리

개요

시그널링 서버 구현에 앞서 WebRTC 개념 이해하는데만 해도 한 세월이 걸렸다. 공식 문서를 읽는데 처음 보는 단어와 개념이 너무 많았고 그냥 지나치기에는 마치 영단어 모르고 영어 책 읽는 기분.. 어떤 건지 정도만 알아도 이해하는데 큰 도움이 될 거라 생각되어 간략하게 정리해보았다.

 

---

WebSocket vs. Socket.io vs. WebRTC

 

WebSocket

• 양방향 통신을 위한 프로토콜이다. stateless, connectionless 한 HTTP와 달리 연결을 유지하여 서버와 클라이언트 간에 실시간 데이터 교환이 가능하다.
• “ws://example.com” 과 같은 형태의 url을 갖는다.

Socket.io

• 웹소켓을 기반으로 한 JS 라이브러리로 이벤트 기반 통신 등 추가적인 기능을 제공한다.
• 웹소켓을 지원하지 않더라도 fallback을 통해 다른 통신 메카니즘(ex. polling)을 선택할 수 있다.

 

→ WebSocket은 표준 프로토콜이고 Socket.io는 그 프로토콜을 기반으로 하는 라이브러리이다.

WebRTC (Web Real-Time Communication)

• 브라우저 간 실시간 음성, 영상 및 데이터 통신을 지원하는 오픈 소스 프로젝트다. 클라이언트 간의 통신(P2P, Peer-to-Peer)을 지원하며 멀티미디어 통신에 특화되어 있다.
• Socket.io는 브라우저끼리 통신하는 것처럼 보이지만 사실 중개 서버가 존재한다. 반면 WebRTC는 실제 브라우저끼리 소통하기 때문에 속도가 빠르고 지연 시간이 짧다.
• Signaling 메시지 교환, P2P 연결 상태 관리 등 추가적인 기능을 위해 Socket.io가 함께 사용된다.

언제 어떤 걸 사용해야할까?

• 간단하고 지연 시간이 짧은 양방향 통신이 필요하다면 WebSocket이 용이하다.
• 브라우저 간의 호환성 및 fallback 등 추가적인 기능이 필요하다면 Socket.io이 용이하다.
• 영상 및 음성 통화, 화면 공유 등 실시간 스트리밍 및 P2P 통신이 필요하다면 WebRTC가 용이하다.

 

---

WebRTC에서 다루는 프로토콜

 

스트림 제어 전송 프로토콜 (SCTP, Stream Control Transmission Protocol)

• SCTP는 전송 계층에 속하며 쉽게 말해 TCP와 UDP의 기능을 결합한 데이터 전송 프로토콜이다. TCP의 연결형 및 신뢰성을 유지하면서도 UDP와 유사한 메시지 지향 데이터 전송을 제공한다. 이러한 특징으로 WebRTC와 같은 실시간 통신 시스템에서 UDP 대신 SCTP를 사용하는 경우가 많다.

세션 기술 프로토콜 (SDP, Session Description Protocol)

• SDP는 멀티미디어 세션을 설정하고 관리하기 위해 사용된다. 통신에 필요한 매개변수, 설정 등 세션 정보를 교환하고 이를 바탕으로 세션을 설정한다. 세션 정보로는 미디어 유형, 코덱, 대역폭 등이 포함된다. SDP는 제안과 수락 모델(Offer & Answer Model)을 사용하여 서로의 capability를 협상하고 수락한다.
• WebRTC에서 P2P 연결을 설정하기 위해 사용되며 RTP와 함께 사용된다.

실시간 통신 프로토콜 (RTP, Real-time Transport Protocol)

• RTP는 실시간으로 음성, 영상 및 멀티미디어 데이터를 전송하는데 사용하는 프로토콜이다. 데이터를 패킷화 하여 네트워크를 통해 전송하며 각 패킷은 시간 정보, 시퀀스 번호, 타임스탬프 등 메타데이터를 포함한다. RTP는 일반적으로 UDP 위에서 동작하고 RTP 세션을 제어하고 모니터링하는 RTP Control Protocol(RTCP)과 함께 사용된다.

데이터그램 전송 계층 보안 (DTLS, Datagram Transport Layer Security)

• TCP 기반 통신인 HTTP을 암호화할 때(HTTPS) SSL/TLS을 사용한다. 이 TLS에서 파생된 DTLS는 UDP 기반 통신의 보안을 위해 고안된 프로토콜이다.
• WebRTC에서 RTP 데이터 스트림의 보안을 위해 사용되며 피어 간의 연결을 안전하게 보호한다.

 

---

WebRTC 용어

 

Signaling 서버

• P2P 통신을 위해서는 브라우저들이 서로의 정보를 알고 있어야한다. 이러한 연결 설정 및 정보를 교환하는 과정을 Signaling 이라고 하고 시그널링 서버에서 이를 중개하고 관리한다.
• 이때 교환되는 정보가 SDP 이다. SDP는 제안/수락 모델에 따라 한 피어가 제안을 보내면(Offer) 다른 피어가 응답한다(Answer). 이 과정을 통해 데이터를 교환하고 통신이 설정된다.

Offer/Answer vs. Caller/Callee vs. Sender/Receiver

• Offer: 통신을 시작하는 피어가 다른 피어에게 연결을 설정하기 위한 정보를 보낸다. 제안 받은 피어는 이 제안을 수락 또는 거절할 수 있다.
• Answer: 제안 받은 피어는 자신의 환경 및 설정 정보를 응답으로 보낸다. 제안 했었던 피어가 응답을 받으면 연결이 설정된다.
• Caller: 통신을 시작하는 측을 의미한다.
• Callee: Caller가 통신을 시도하고자하는 대상, 즉 통신을 받는 측을 의미한다.
• Sender: 데이터를 생성하고 전송하는 측을 말한다. WebRTC에서는 미디어 스트림을 생성하고 전송하는 역할을 한다.
• Receiver: Sender로부터 전송된 데이터를 받는 측을 말한다. WebRTC에서는 전송된 미디어 스트림을 받는 역할을 한다.

 

→ Caller가 Offer를 생성해서 보내고 Callee가 Answer를 생성해서 응답한다.
→ P2P 연결이 수립된 후 미디어 스트림을 보내는 주체가 Sender, 받는 주체가 Receiver

ICE (Interactive Connectivity Establishment)

• ICE는 두 피어 간에 안정적인 연결을 설정하기 위해 사용되는 기술이다. ICE는 여러 경로 후보를 제안하고 가장 최적의 경로를 찾아 통신을 설정한다. 이를 통해 NAT, 방화벽 등 네트워크 제약 상관없이 안정적인 연결을 수립할 수 있다.
• 이때 여러 경로 후보들을 ICE Candidate라고 한다. 이는 로컬 및 공용 IP 주소, 포트 번호 등을 포함한다.
• STUN, TURN 서버 등을 사용한다.

NAT (Network Address Translation)

• 네트워크 기술 중 하나로 여러 장치들이 하나의 공용 IP 주소를 공유할 수 있도록 하는 방법이다. 장치들의 각각의 로컬 IP를 갖고 있는데 NAT은 이 로컬 IP에 공용 IP를 할당하여 외부와 소통한다.

STUN (Session Traversal Utilities for NAT)

• NAT 환경에서는 각 피어들이 별도의 로컬 IP를 갖고 있고 피어끼리 소통하기 위해서는 공용 IP를 알아야한다. STUN은 피어가 자신의 공용 주소를 알아내는데 사용되는 서버이다. 이 공용 주소를 사용해서 시그널링 과정을 거친다.
• STUN 서버는 피어 간 직접적인 통신이 가능할 때 사용된다.

TURN (Traversal Using Relays around NAT)

• TURN 서버는 직접적인 통신이 불가능 할 때 사용된다. 예를 들어 공용 IP 주소가 동적으로 할당 된다거나 방화벽 문제 등이 있다.
• 이때는 TURN 서버가 중계 서버가 된다. 각 피어는 TURN을 통해 데이터를 교환하고 TURN 서버가 중계 역할을 수행한다.

 

---

개인적으로 헷갈렸던 부분 정리

• 웹소켓, Socket.io, WebRTC 차이
  • 웹소켓은 실시간 통신을 위한 프로토콜 중 하나이고 Socket.io와 WebRTC은 실시간, 양방향 통신을 구현하는 데 도움을 주는 기술이다. Socket.io는 웹소켓을 기반으로 하는 라이브러리이며 WebRTC는 웹소켓과 별개로 P2P 통신 규약을 따르고 있다. → Socket.io나 WebRTC 중 하나만 사용하는 것이 아니라 상황에 따라 병행하여 사용할 수 있다.
  
  
  
• WebRTC는 서버 없이 통신한다고 했는데, 그렇다면 시그널링 서버는 무엇인가
  • WebRTC는 서버와의 통신 없이 브라우저 간 통신을 지원한다. 그렇다고 서버가 아예 필요없는 것은 아니다. 실제 통신 할 때 서버를 거치지 않을 뿐 초기 시그널링을 위한 서버 구축이 필요하다.
  
  
  
• SDP vs. RTP, 둘 다 실시간/양방향 통신 프로토콜 같은데..
  • SDP는 통신을 설정할 때 사용되는 프로토콜이고 RTP는 실제 데이터를 주고 받을 때 사용되는 프로토콜이다. → P2P 초기 설정할 때 사용되는게 SDP, 연결 수립 후 실제 미디어 스트림을 주고 받을 때 사용되는게 RTP

구현하면서 동작은 하지만 이해는 되지않는, 뒤죽박죽이던 머릿 속이 정리된 기분이다. 읽어도 이해가 잘 되지 않는다면 실제 구현해보고 다시 읽어보자! 다음에는 실제 WebRTC, mediasoup 통신 과정이 어떻게 되는지 정리해보고자 한다.