⇒ API 내부에서 많은 일이 발생하기 때문에 기술을 최대한 활용하려면 WebRTC의 개념과 작동원리를 이해하는 것이 중요합니다.
WebRTC 연결을 설정하려면 다음 두 단계를 수행해야 합니다.
- Find the loaction of a peer
- Notify a peer to setup WebRTC connection
Step 1: Peer 찾기
- 본문
❓ 좋은 설명이 있어서 이해한 내용을 적어보았습니다.
- Peer 찾는 것을 전화 통화와 비교해봅시다.
- 우리가 전화로 누군가와 이야기해야 할 때 상대방의 전화 번호를 입력하고 전화를 걸어 그 사람과 연결합니다.
- 반대로 누군가가 우리에게 전화를 걸고 싶을 때도 마찬가지입니다.
- 이동통신의 경우 번호를 이용자 식별정보로 사용합니다. 이 식별정보는 통신 시스템에서 사용자를 찾는 데 사용됩니다.
- 웹 애플리케이션은 Peer를 찾는 데 사용할 수 있는 고유한 IP 주소가 할당됩니다.
- 그러나 이 과정은 말처럼 쉽지 않습니다. 이러한 시스템의 대부분은 NAT 장치 뒤에 있기 때문입니다.
- 사용 가능한 public IP 주소에 대한 보안 및 IPv4 제한을 위해 NAT 장치가 필요합니다.
- NAT 장치는 로컬 네트워크 내의 시스템에 private IP 주소를 할당합니다.
- 이 private IP 주소는 로컬 네트워크 내에서만 유효하다고 볼 수 있으며, 네트워크 외부의 시스템은 네트워크 내 장치의 public IP를 인식하지 못하기 때문에 외부와의 통신을 허용하는 데 사용할 수 없습니다.
- NAT 장치의 개입 때문에 Peer는 NAT에서 할당한 private IP 주소로 가려져 자신의 public IP 주소를 알지 못합니다.
- 따라서, 연결을 수락하기 위해 다른 Peer와 public IP 주소를 공유할 수 없습니다.
- 풀어서 얘기하면, 누군가가 우리에게 전화를 걸고 싶다면 상대방에게 우리의 전화번호를 알려줘야 합니다.
- 그러나, NAT가 있는 상태에서는 외부에 방의 전화번호가 숨겨져 있는 호텔에 머무르는 것과 같으며, 호텔로 걸려오는 전화는 리셉션에서 처리되고 요청 시 방으로 다시 연결됩니다.
- 이러한 간접적인 연결 형태는 P2P 연결 기술에서 의도된 것이 아닙니다.
- 위 문제를 해결하기 위해, 우리는 ICE(Interactive Connectivity Establishment)라고 불리는 프로토콜을 사용합니다.
- ICE의 역할은 두 Peer를 연결하는 최상의 경로를 찾는 것입니다.
- ICE는 직접 연결(NAT가 없는 경우)과 간접 연결을 수행할 수 있습니다. ICE는 우리에게 ‘ICE 후보’를 제공합니다.
- ‘ICE 후보’는 우리 고유의 public IP 주소, 포트 번호 및 기타 연결 관련 정보를 포함하는 객체일 뿐입니다.
- NAT가 있는 경우 ICE는 STUN(Session Traversal Utilities for NAT) 또는 TURN(Traversal Using Relays around NAT)라고 하는 엔티티에 의존합니다.
-
STUN 서버는 기본적으로 Peer가 자신의 public IP주소를 찾을 수 있도록 합니다.
-
자신의 공인 IP 주소를 알아야 하는 Peer는 STUN 서버에 요청을 보냅니다.
-
STUN 서버는 해당 Peer의 public IP주소로 응답합니다.
-
이제 이 public IP주소를 다른 Peer와 공유하여 다른 Peer가 해당 Peer를 찾을 수 있도록 할 수 있습니다.
-
하지만, Peer가 복잡한 NAT 및 방화벽 뒤에 있는 경우 STUN 서버도 요청한 해당 Peer의 public IP주소를 발견할 수도 제공할 수도 없습니다.
-
이러한 경우 ICE는 TURN에 의존하여 연결을 설정합니다.
-
TURN은 이름에서 알 수 있듯이 중계 서버로 두 Peer 간에 직접 연결이 불가능한 경우 데이터, 오디오, 비디오를 전송하는 중개자 역할을 합니다.
-
STUN 서버는 public IP를 찾는 과정에만 관여합니다.
-
WebRTC 연결이 설정되면 모든 추가 통신은 WebRTC를 통해 발생합니다.
-
하지만, TURN의 경우 WebRTC 연결을 설정한 후에도 내내 TURN 서버가 필요합니다.
-
TURN 서버는 의도하지 않은 것이지만 STUN의 한계로 인해 의존해야 합니다. STUN 서버는 약 86%의 경우에만 성공합니다.
“ICE is complex because we live in a complex world.”
Step 2: WebRTC 연결을 설정하도록 Peer에게 알리기
-
본문
❓ 좋은 설명이 있어서 이해한 내용을 적어보았습니다.
- 이제 ‘ICE 후보’를 얻었으므로 다음 단계는 이 후보를 연결하려는 Peer에게 보내는 것입니다.
- ‘ICE 후보’와 함께 세션 정보, 시간 설명, 미디어 설명과 같은 Session Description이 전송됩니다.
- ‘ICE 후보’ 및 Session Description은 객체 내부에 번들로 제공되며 SDP(Session Description Protocol)를 사용하여 전달됩니다.
- 경우에 따라 ‘ICE 후보’가 Session Description과 동일한 객체에 번들로 포함되지 않고 별도로 전송되며, 이를 Trickle ICE라고 합니다.
- 다른 Peer에게 정보를 ‘전송’해야 한다고 썼습니다. 그러나 발신자의 IP 주소만 알고 수신 Peer의 IP 주소를 모를 때 ‘ICE 후보’와 Session Description은 어떻게 전송됩니까?
- 그리고 아직 WebRTC 연결이 이뤄지지 않았기 때문에 이러한 정보는 어떤 매체를 통해 전달되나요?
❓ 두 질문의 답은 Signaling Mechanism이라는 개념 안에 있습니다.
WebRTC 연결이 설정되기 전에 Peer 간에 위의 정보를 전송하고 WebRTC 연결을 위해 서로 찾고 연결하는 방법을 알려주는 매개체가 필요합니다.(위 사진을 보면 흐름을 알 수 있습니다.)
⇒ Signaling Mechanism은 이름에서 알 수 있듯이 연결하려는 두 Peer 간에 연결 신호(ICE 후보, Session Description 등)을 교환합니다.**
- WebRTC는 이러한 Signaling Mechanism을 구현하기 위한 표준을 정의하지 않으며, 개발자가 선택한 메커니즘을 생성하도록 합니다.
- 정보를 교환하는 Signaling Mechanism은 정보를 각 Peer에 간단히 복사하여 붙여넣거나 WebSocket, Socket.io, Server Side Events 등과 같은 통신 채널을 사용하여 달성할 수 있습니다.
- 다시 말해, Signaling Mechanism은 Peer가 서로를 식별하고 WebRTC를 사용하여 추가 통신을 시작할 수 있도록 Peer 간에 연결 관련 정보를 교환하는 모드일 뿐입니다.
요약
❓
1. Peer A는 ICE 프로토콜을 사용하여 ‘ICE 후보’를 생성합니다. 대부분의 경우STUN 또는 TURN 서버를 필요로 합니다.
2. Peer A는 ‘ICE 후보’와 Session Description을 단일 객체로 번들화 한다. 이 객체는 Peer A 내에 Local Description(Peer 자신의 연결 정보)으로 저장되고 Signaling Mechanism을 통해 Peer B로 전송됩니다. 이 부분을 ‘Offer’라고 합니다.
3. Peer B는 Offer를 수신하고 추후 사용을 위해 Remote Description(상대방 Peer의 연결 정보)으로 저장합니다. Peer B는 자체 ‘ICE 후보’와 Session Description을 생성하고 Local Description으로 저장하고 Signaling Mechanism을 통해 Peer A로 보냅니다.
이 부분을 ‘Answer’라고 합니다.
4. Peer A는 Peer B로부터 Answer를 받아 Remote Description으로 저장합니다.
⇒ 이를 통해 두 Peer는 서로의 연결 정보를 갖고 WebRTC를 통해 성공적으로 통신을 시작할 수 있습니다.
