WebRTC(Web Real Time Communication)

WebRTC(Web Real Time Communication)

---

• webRTC
  • 개관
  • 
    

    • WebRTC는 브라우저간 플러그인 없이 저지연 실시간 P2P통신을 가능하게 하는 표준 기술/API이다. 화상통화, 음성통화, 파일전송, 실시간 데이터교환 등 다양하게 활용되고 있다. 현재는 Web/모바일/데스크톱에서도 지원되는 크로스플랫폼 기술이다. 
    • 이를 활용한 서비스로는 대표젹으로 디스코드가 있다.
  • 특징
  • 
    

    • 서버를 최소화할 수 있다. 설계상 서버리스P2P통신을 지향하는 것으로 보이나, ISP 관리환경 내에서 안정적인 서비스를 위해 서버는 두되 그 개입을 최소화하려는 것으로 보인다.
      • 이런 맥락에서 WebRTC는 사용자들에게 서버를 전가하지 않기 때문에, 분산네트워킹을 뜻하는 전통적인 의미의 P2P통신과는 아예 거리가 멀다. 반면 일상적으로 연상되는 P2P 이미지는 직접연결로, WebRTC가 분명 이에 더 가깝다. 사견으로 전통적 P2P는 거의 사기에 가까운 네이밍이라 본다. 이질적인 정의를 머릿속에 한땀한땀 입력한 사람을 제외하면, 분산 네트워킹을 떠올리며 P2P를 찾는 사람은 상상하기 어렵다. 이런 용어와 인상의 혼잡은 사람을 그 맥락과 오래 함께한 사람을 제외한 많은 이들을 혼란에 빠뜨린다.말똑바로안해? 
    • 그리고 저지연(Low-Latency)이 상당히 두드러지는 특성이다. 최적의 환경에서는 실시간에 가까운 지연 시간을 보여준다. 또한 대체로 많은 부분이 표준화되어 제공되기 때문에, 개발자 입장에서 신경쓸 부분은 많지 않다. 사용자 개발자 모두 쾌적하다. 시그널링과 랜더링은 신경써야 한다.
    • 다만 모바일-모바일간 UDP Hole Pucnhing 성공률이 보장되지 않아 결국 TURN으로 가고, 이는 WebRTC를 사용하는 목적과 벗어나는 결과를 초래한다.
  • 연결수립과정
    • 시그널링(Signalling) - NAT Traversal - 연결수립 - 데이터 전송

    •  

      • 시그널링은 두 피어가 실제로 데이터를 주고받기 전에 서로 어떤 방식으로 통신할 수 있는지를 합의하기 위한 사전 협상단계라고 볼 수 있다. 이 단계에서는 미디어 종류, 지원 코덱, 암호화 방식, 네트워크 후보 정보처럼 연결에 필요한 메타데이터가 교환된다. WebRTC표준은 시그널링 방식 자체를 정의하지 않기 때문에 개발자는 WebSocket, HTTP, MQTT등 임의의 서버 기반 채널을 선택해 구현해야 한다.  
    • 
      

      • NAT Traversal은 사설 네트워크나 이동 통신망 뒤에 있는 두 피어가 직접 연결될 수 있도록 경로를 탐색하는 과정이다. 대부분의 클라이언트는 NAT나 방화벽 내부에 위치해 있어 외부에서 직접 접근이 불가능하며, WebRTC는 이를 전제로 설계되어 있다. STUN(Session Traversal Utilities for NAT)서버를 통해 각 피어는 외부에서 자신이 식별되는 IP/포트를 확인하고 ICE(Interactive Connectivity Establishment)프레임워크를 통해 가능한 네트워크 경로를 수집/비교한다. ICE 프레임워크가 확보하는 후보는 다음과 같다.
        
        1. 직접 연결 탐색 : STUN에서 드러난 IP/포트로 UDP Hole Punching으로 직접 연결. STUN 서버가 연결을 최초에 중계하게 되면 각 호스트의 NAT입장에서는 사설 단말이 앞서 요청을 보냈고, 이에 대한 응답을 받는 셈이 된다. 따라서 이후의 INBOUND패킷들을 허용하게 되고, 여기서부터는 서버가 없어도 통신이 가능해진다. 단 NAT 정책이 엄격한 경우 그렇지 않을 수 있다.
        2. 기타 경로 우선순위 탐색
        3. TURN(Traversal Using Relays around NAT) fallback : 안 되면 서버가 중계 

    •  

      • 연결 수립(Connection Establishment) 은 NAT Traversal 과정에서 수집된 여러 후보 경로 중 실제로 사용할 하나의 통신 경로를 선택하고, 이를 안전한 연결로 확정하는 과정이다. ICE는 각 후보 경로에 대해 연결 가능성을 테스트한 뒤, 가장 안정적이고 우선순위가 높은 경로를 선택한다. 이후 선택된 경로를 기반으로 DTLS(Datagram Transport Layer Security) 핸드셰이크가 수행되며, 이 단계에서 암호화/보안 설정이 이루어진다. WebRTC에서는 암호화가 선택 사항이 아니라 필수이기 때문에, 이 단계가 완료되기 전에는 어떤 데이터도 전송될 수 없다. 연결 수립이 완료되면 두 피어는 논리적으로 하나의 지속적인 세션을 공유하게 되며, 이후 데이터 전송은 이 세션을 통해 이루어진다.  
      • WebRTC는 연결 상태를 자체적으로 계속 확인한다. 연결 상태 변동에 따라 직접연결에서 중계연결로 강등되기도, 중계연결에서 직접연결로 승격되기도 한다. 이 경우에도 TURN은 보충적으로 기능한다. 
        • 여기서 P2P연결의 재미있는 점은 서버가 죽어도 그것을 이유로 통신이 끊기지는 않는다는 점이다. 서버가 죽어도 이와 무관하게 P2P연결은 유지된다. 다만 네트워크 핸드오버(Network Handover) 등 서버 외적인 이유로 통신이 끊길 수 있고, 그 때 연결 재수립이 불가능해질 뿐이다. 반면 TURN fallback 환경에서는 서버가 죽으면 당연히 통신이 끊긴다.

       

    • 
      

      • 데이터 전송 단계(Data Transfer)는 실제 음성, 영상, 또는 애플리케이션 데이터가 피어 간에 교환되는 단계다. 음성과 영상 데이터는 SRTP(Secure Real time Transport Protocol)를 통해 전송되며, 지연을 최소화하기 위해 일부 패킷 손실을 허용하는 방식으로 처리된다. 애플리케이션 데이터는 DataChannel을 통해 전달되며, 이는 SCTP를 기반으로 하여 신뢰성과 순서를 선택적으로 조절할 수 있다. 이로 인해 WebRTC는 실시간 게임 상태 동기화처럼 빠른 응답이 중요한 경우와, 메시지 전달처럼 신뢰성이 중요한 경우를 모두 지원할 수 있다. 데이터 전송은 연결 수립 단계에서 확정된 단일 경로를 따라 이루어지며, 해당 경로가 TURN 서버를 포함하는 경우에는 모든 데이터가 서버를 경유하게 된다. 따라서 이 단계에서의 성능과 비용 특성은 앞선 NAT Traversal 결과에 직접적으로 의존한다.

       

• 정리
  • 
    

    • WebRTC는 STUN 서버의 도움을 받아 NAT를 통과한 뒤, 가능한 경우 단말 간 직접 연결을 맺어 저지연 통신을 수행하는 P2P(직접연결) 통신 기술이다.
    • 안 되는 경우 보충적으로 TURN서버로 중계(Relay)한다.