RFC8836: Congestion Control Requirements for Interactive Real-Time Media 정리

학교 프로젝트 진행 중 정리한 RFC8835의 내용을 블로그에 포스팅해봅니다. 필요한 내용만 정리하였기 때문에 일부 내용은 생략되었을 수 있습니다.

개요

인터넷에서 오가는 모든 데이터는 Congestion Control이 필요하다. 그런데 WebRTC와 같이 상호 작용, 낮은 딜레이, 약간의 신뢰성을 필요로 하는 실시간 p2p 미디어 전송 프로토콜의 경우, FTP나 웹 페이지에서 필요로 하는 것과는 다소 다른 요구사항을 가진다. 따라서 이런 프로토콜의 트래픽을 처리하기 위한 Congestion control 방법이 필요하다.

스트리밍되는 실시간 데이터는 다음과 같은 요구사항을 가진다.

• 제한된 Time window 안에 데이터를 끊임없이 전송해야 함.
• 일부 packet의 loss가 일어나더라도 데이터를 실시간으로 보내는 게 더 높은 우선순위

원리

WebRTC IP 처리의 중요 원리는 다음과 같다.

1. 기본적으로 WebRTC 트래픽은 전통적인 IP 라우팅 방식을 따르며(HTTP 트래픽과 동일한 인터페이스를 사용함), application이 시스템의 public 주소를 볼 수 있어야 함.

   • 하지만 최적의 미디어 퀄리티를 위해 WebRTC는 모든 네트워크 인터페이스에서 최적의 경로를 찾을 수 있어야 함.

2. WebRTC는 NAT 순회 또는 TURN을 사용하지 않고 엔드포인트간의 직접적인 p2p 연결이 가능한 경우, 그렇게 해야 함. 이로써 p2p 라우팅을 필요로하는 애플리케이션이 성공적으로 동작할 수 있음.

3. WebRTC가 private IP를 공개하지 않기를 원한다면, 이를 설정할 수 있어야 함. 단 이게 기본 설정은 아님.

4. 기본 설정으로 WebRTC 트래픽은 프록시 서버를 통해 전송되지는 않아야 함. 이는 프록시를 사용하여 통신하는 경우 WebRTC 트래픽이 TCP를 통해 전송되기 때문에 성능 문제가 발생하기 때문임. 또한 WebRTC의 long-lived, high bandwidth인 연결이 프록시를 통하면 성능 문제가 생김. 하지만 클라이언트가 원할 경우 프록시를 통하여 WebRTC 연결을 보내도록 설정할 수 있어야 함.

이러한 원리에 기반하여, WebRTC 동작에 대한 4개의 모드를 정의할 수 있음.

1. 모든 주소를 열거함

   • WebRTC는 모든 네트워크 인터페이스를 사용하여 STUN, TURN, 피어와 통신을 시도함.
   • 이를 통해 최선의 미디어 경로를 찾음.
   • 미디어 성능이 최우선적으로 중요할 때 사용하지만 많은 정보가 공개됨.

2. 기본 경로 + 연관된 로컬 주소

   • WebRTC는 커널의 라우팅 테이블을 따라야 하며, 이 경우 일반적으로 미디어 패킷이 HTTP 트래픽과 같은 경로를 타게 됨.
   • 만약 TURN 서버가 존재하는 경우, TRUN 서버를 통과하는 경로를 선호함.
   • 인터페이스가 선택되면, 이 인터페이스와 연관된 private ipv4 및 ipv6 주소를 찾아 호스트 후보로 어플리케이션에 전달됨. 이로써 이 모드에서 직접적인 연결이 생성될 수 있음.

3. 기본 경로만 사용

   • 이 모드는 (2)의 모드와 비슷하지만, 연관된 private 주소가 제공되지 않음.
   • 수집된 IP주소는 기본 경로에서 STUN 및 TURN과 같은 매커니즘을 통해 검색된 IP주소 이외엔 없음.
   • 하지만 트래픽이 NAT를 통과하거나, TURN 서버를 통하거나, 모두 실패하여 품질에 영향을 미칠 수 있음.

4. 프록시 강제

   • (3)의 모드와 동일하지만 HTTP 트래픽이 프록시를 통하는 경우, WebRTC의 트래픽도 프록시를 통하게 됨.
   • 만약 프록시가 UDP를 지원하지 않거나 WebRTC 구현이 UDP 프록시를 지원하지 않는경우, WebRTC는 UDP를 사용하지 않고 TCP를 사용하여 프록시를 통해 전송 및 수신함.
   • TCP를 사용하면 미디어 품질 및 전송시 성능이 감소함.

이때 사용자 동의가 없는 한 모드 1을 사용하지 않는다. 사용자 정의에 관련된 부분은 getUserMedia 등에서 얻을 수 있는 듯 함. 동의가 없는 경우 모드 2를 사용한다.

• 즉, 모드 2는 별다른 동의 없이 최적의 네트워크 성능을 달성할 수 있게끔 하는 합리적인 절충안이라고 볼 수 있음
• 직접 연결을 달성하는데 필요한 최소 정보만 동의 없이 어플리케이션에 제공
• 하지만 사용자 요구에 따라, 필요하다면 더 엄격한 모드를 선택함.

제안된 기본값음 모든 외부 WebRTC 트래픽이 프록시나 TURN 서버를 통과하게끔 원하는 조직도 사용 가능함

• WebRTC 트래픽이 프록시나 TURN 서버를 통해서만 나가도록 조직의 방화벽 정책을 설정하면 됨
• 프록시나 TURN 서버가 외부 트래픽에 사용되지만, 조직 내 트래픽에 직접 연결될 수 있으며, 프록시의 경우 성능 문제를 방지할 수 있음

구현 가이드

위 정책을 구현하는 방법에 대한 WebRTC 구현 지침

1. 정상 라우팅 보장

   • 모드 2 또는 모드 3과 같은 전통적인 IP 라우팅을 시도하는 경우, 가장 간단한 방법은 와일드카드 주소(IPv4의 0.0.0.0 및 IPv6의 ::)로 소켓을 bind()하는 것임.
     • 이렇게 하면 OS는 HTTP 트래픽과 동일한 방식으로 WebRTC 트래픽을 라우팅할 것이며, STUN과 TURN도 평소대로 사용되고, 호스트 후보는 아래 언급된 것처럼 여전히 결정될 수 있음.

2. 연관된 로컬 주소 결정

   • 와일드카드 주소를 바인딩할 때, 모드 2에 필요한 연관된 로컬 주소를 결정하려면 추가적인 작업이 필요함.
     • 로컬 주소는 웹 애플리케이션 호스트로 전송되는 모든 패킷의 source address로 정의됨.
     • 웹 애플리케이션 호스트를 destination으로 사용하면 애플리케이션의 위치에 관계 없이 올바른 source address가 선택됨.
   • 웹 애플리케이션 URI의 호스트 컴포넌트를 resolve하여 적절한 remote IPv4/IPv6 주소를 얻음. 클라이언트가 프록시 뒤에 있고 DNS를 통해 IP를 resolve할 수 없는 경우, 프록시의 주소를 대신 사용함.
   • 일단 적절한 원격 IP가 결정되면, UDP 소켓을 적절한 와일드카드 주소에 bind()하고 원격 IP에 connect()함.
     • 일반적으로 이 소켓은 네트워크를 통해 패킷을 보내지 않고 커널의 라우팅 테이블을 바탕으로 로컬 주소를 할당받음.
     • 결과적으로 이 소켓으로 getsocketname() 등을 호출하여 적절한 로컬 주소를 확인할 수 있음.

3. 어플리케이션 동작

   WebRTC를 사용하는 애플리케이션이 잘못 동작하지 않게끔, 다음과 같은 가이드라인을 제공함.

   • 모드 3 및 4를 지원하기 위해서는 UDP 및 TCP 연결을 모두 지원하는 TURN 서버를 배포해야 함.
   • 어플리케이션은 host candidate의 존재 유무를 확인하여 모든 ICE candidates에 접근할 수 없는 경우를 감지할 수 있어야 함. host candidate가 없다면 모드 3 및 4를 사용중인 경우임.