Skip to content

Interactive Connectivity Establishment

Interactive Connectivity Establishment (ICE) is a technique used in computer networking to find ways for two computers to talk to each other as directly as possible in peer-to-peer networking. This is most commonly used for interactive media such as Voice over Internet Protocol (VoIP), peer-to-peer communications, video, and instant messaging. In such applications, you want to avoid communicating through a central server (which would slow down communication, and be expensive), but direct communication between client applications on the Internet is very tricky due to network address translators (NATs), firewalls, and other network barriers.

ICE is developed by the Internet Engineering Task Force MMUSIC working group and is published as RFC 8445, as of August 2018, and has obsoleted both RFC 5245 and RFC 4091. 

peer-to-peer 간 다이렉트로 통신을 위한 기술

Categorires

Projects

RFC

  • RFC 8445 - Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal
  • REC 8839 - Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)

ICE Candidate Type

host
Host Candidates.
  • 클라이언트의 사설 주소. 랜과 무선-랜 등 다수 인터페이스에 IP가 매핑되어 있으면 모든 주소가 후보가 된다.
  • 후보는 RTCIceCandidate.address속성에 지정된 IP 주소 가 실제로 원격 피어의 실제 주소인 호스트 후보 입니다.
srflx
Server Reflexive Candidates.
  • NAT 장비가 매핑한 클라이언트의 공인망 주소로 STUN에 의해 판단한다.
  • IP는 STUN 서버가 후보자의 피어를 익명으로 나타내기 위해 할당한 중개 주소를 나타냅니다.
prflx
Peer Reflexive Candidates.
  • ICE 에이전트가 연결성 시험을 하는 과정에서 피어가 포트 보존이 되지 않는 Symmetric NAT 뒤에 위치하는 경우, STUN에 의해 새로운 바인딩 경로를 찾을 수 있다.
  • Symmetric NAT는 바인딩을 위한 포트를 임의로 생성하기 때문.
  • IP는 익명으로 후보자의 피어를 나타내기 위해 STUN 서버에서 할당한 중개 주소입니다.
relay
Relayed Candidates.
  • 패킷 릴레이를 위해 할당하는 TURN 서버 주소.
  • 릴레이 후보의 IP 주소는 TURN 서버가 두 피어 간에 미디어를 전달하는 데 사용하는 주소입니다.

Trickle ICE

Draft

Trickle ICE - Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol - draft-ivov-mmusic-trickle-ice

  • Local Download: Slides-87-mmusic-11.pdf

시그널링 후: NAT와 방화벽들에 대응하기 위한 ICE의 사용

시그널링 후: NAT와 방화벽들에 대응하기 위한 ICE의 사용

메타데이터 시그널링을 위해 WebRTC 앱들은 중계서버를 사용하지만 실제 미디어와 데이터 스트리밍들은 피어(Peer)와 피어(Peer)에 일단 세션의 연결되고 RTCPeerConnection가 클라이언트에 직접 연결하기 위한 시도가 이루어집니다.

보다 쉬운 세상에서 모든 WebRTC의 종점은 다른 피어(Peer)들과의 교화을 위해 직접 통신이 가능한 유일한 주소를 가집니다.

Webrtc-ice-infrastructure-p2p.png

실제로는 대부분의 디바이스들은 NAT와 안티바이러스 소프트웨어가 확실한 포트들과 프로토콜들을 막고 수많은 프록시와 방화벽이 협력하는 하나 이상의 레이어 뒤에 동작하고 있습니다. 사실 방화벽과 NAT는 홈 wifi 라우터와 같은 동일한 디바이스로 구축되어 있습니다.

Webrtc-ice-infrastructure-nat.png

WebRTC 어플리케이션들은 실제 세상의 네트워크 복잡성을 극복하기 위해 ICE 프레임워크를 사용할 수 있씁니다. 이를 위해 어플리케이션은 아래와 같이 반드시 ICE 서버 URL들을 RTCPeerConnection으로 전달하여야 합니다.

ICE는 피어(Peer)들과 연결하기 위한 최적의 경로를 찾으려 합니다. 동시에 가능한 모든 것을 시도하며 동작하는 가장 효율적인 선택을 골라냅니다. ICE는 첫번째로 다음과 같이 디바이스 운영체제로와 네트워크 카드로부터 획득한 호스트 주소를 사용하여 연결을 생성하려 합니다. 만약 실패한다면 (디바이스가 NAT 뒤에 있을 것입니다.) ICE는 STUN 서버를 이용하여 외부 주소를 획득하고 그것이 실패한다면 TURN 중계 서버를 통해 트래픽을 라우팅합니다.

다시 말해서

  • STUN 서버는 외부 네트워크 주소를 얻는데 사용됩니다.
  • TURN 서버들은 직접(P2P) 연결이 실패할 경우 트래픽을 중계하는데 사용됩니다.

모든 TURN 서버는 다음과 같이 STUN을 지원합니다. TURN 서버는 내장된 기능을 릴레이하는 STUN 서버입니다. 또한 ICE는 다음과 같이 복잡한 NAT 설정에 대응할 수 있습니다. 실제로 NAT 'Hole Punching'은 포트 주소 같은 공용 IP 이상의 것들을 요구합니다.

STUN, TURN 서버들을 위한 URL들은 RTCPeerConnection 생성자의 첫번째 인자로 전달되는 iceServers 설정 객체에 존재하는 WebRTC 앱에 의해 (선택적으로) 정의됩니다. appr.tc에서 저 값은 다음과 같이 보입니다. 

{
  'iceServers': [
    {
      'urls': 'stun:stun.l.google.com:19302'
    },
    {
      'urls': 'turn:192.158.29.39:3478?transport=udp',
      'credential': 'JZEOEt2V3Qb0y27GRntt2u2PAYA=',
      'username': '28224511:1379330808'
    },
    {
      'urls': 'turn:192.158.29.39:3478?transport=tcp',
      'credential': 'JZEOEt2V3Qb0y27GRntt2u2PAYA=',
      'username': '28224511:1379330808'
    }
  ]
}

일단 RTCPeerConnection이 정보를 가지게 되면 ICE의 마법은 다음과 같이 자동으로 일어납니다. RTCPeerConnection는 필요에 따라 STUN과 TURN 서버들과 동작하는 피어(Peer)들 사이에서 최적의 경로을 산출하는 ICE 프레임워크를 사용합니다.

STUN

NAT들은 사설 로컬 네트워크에서 디바이스에 IP 주소를 제공하지만 이 주소는 외부에서 사용될 수 없습니다. 공용 주소가 없이는 WebRTC 피어(Peer)들은 통신할 수 있는 방법이 없습니다. 이 문제를 해결하기 위해서 WebRTC는 STUN을 사용합니다.

STUN 서버들은 공용 인터넷에서 동작하며 다음과 같은 단순한 한가지 작업을 수행합니다. (NAT 뒤에서 동작한느 어플리케이션으로부터) 전달된 요청의 IP:port 주소를 확인하고 그 주소를 응답으로 되돌려 보냅니다. 다시 말해서, 어플리케이션은 공용의 관점에서 그것의 IP:port를 발견하는 STUN 서버를 사용합니다. 이 절차는 WebRTC 피어(Peer)가 그 자신에 대해 공용에서 액세스 가능한 주소를 획득할 수 있도록 한 뒤 직접 연결을 설정하기 위한 시그널링 메커니즘을 통해 또다른 피어(Peer)로 전송합니다. (실제로는 각각의 NAT들은 개별적으로 동작하며 중첩된 NAT 레이어들이 있을 수 있으나 원칙은 여전히 동일합니다.)

STUN 서버들은 많은 것을 하거나 많은 것을 기억하지 말아야하므로 관련된 저사양 STUN 서버들은 아주 많은 양의 응답을 관리할 수 있습니다.

대부분의 WebRTC 호출은 STUN을 이용한 연결을 성공적으로 만들어냅니다. 방화벽과 복잡한 NAT 설정들 뒤에 존재하는 피어(Peer)들 사이의 호출은 더 작을 수 있겠지만 webrtcstats.com에 따른 (호출에 대한 연결 생성 성공률은) 86%입니다.

Webrtc-ice-infrastructure-stun.png

TURN

RTCPeerConnection는 UDP 상에서 피어(Peer)들 간의 직접 통신 설정을 시도합니다. 만약 이를 실패하면, RTCPeerConnection는 TCP에 의존합니다. 이것도 실패하면 종단점(Endpoint)들 사이의 데이터 릴레이를 수행하는 TURN 서버들이 대안으로 사용될 수 있습니다.

반복하지만 TURN은 시그널링 데이터가 아니라 피어(Peer)들 사이의 오디오/비디오/데이터 스트리밍 릴레이를 위해 사용됩니다!

TURN 서버들은 공용 주소들을 가지고 있으므로 설령 피어(Peer)들이 방화벽이나 프록시들 뒤에 존재하더라도 피어(Peer)들이 접속할 수 있습니다. TURN 서버들은 — 스트림을 릴레이하기 위한 — 개념적으로 단순한 태스크를 수행합니다. 그러나 STUN 서버들과는 다르게 본질적으로 많은 대역폭을 소모합니다. 뒤집어 말하면 TURN 서버들은 육중해질 수 있습니다.

Webrtc-ice-infrastructure-turn.png

이 다이어그램은 다음과 같이 동작하는 TURN을 보여줍니다. 순수 STUN이 성공하지 못했으므로 각 피어(Peer)는 TURN 서버의 사용에 의존합니다.

Signalling

시그널링은 WebRTC 자체에서 지원하는 기능은 아니라서, 미리 준비해야 하는 과정이라고 한다. 시그널링은 WebRTC 자체의 스펙도 아니기 때문에, 한 가지로 딱 정해진 방법이 없다. 정해진 방법이 없는 이유는 알 수 없는 두 장치가 언제 어떤 방식으로 연결될 수 있는지의 모든 경우를 예측하는 것이 불가능하기 때문다. 그래서 개발자는 자신에게 맞는 최적의 방법을 선택적으로 적용해야 한다.

이 때문에 일반적으로 두 개의 장치를 연결할 수 있는 시그널링 서버를 직접 구축하거나, 시그널링 서버를 제공해주는 외부 솔루션을 적용할 수 있다. 만약 시그널링 서버를 직접 구축한다면 웹 소켓(Web Socket)이나 서버 전송 이벤트(Server-sent Event) 방법을 적용할 수 있다.

여러 시그널링 방법에 대해 여기 깃을 참고하자 - https://github.com/muaz-khan/WebRTC-Experiment/blob/master/Signaling.md

시그널링 서버를 제공해주는 솔루션을 쓰는 것도 방법이 될 수 있다고 한다. 아마존의 Kinesis Video Stream 이 대표적인 예이고, 구글의 AppRTC에서는 Google App Engine으로 구현된 시그널링 서버를 확인할 수 있다.

WebRTC_CodeLab_-_signaling.png

Documentation

  • RFC 5245 - Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols - 폐기됨
    • Obsoleted by:
      • RFC 8445 - Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal
      • REC 8839 - Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)

Troubleshooting

stun:localhost is not connect

Session Traversal Utilities for NAT#stun:localhost is not connect 항목 참조.

See also

Favorite site

References

  1. Finalizer_of_NAT_Traversal_ICE.pdf ↩