TURN 서버를 통하여 Realy 통신하는 원리에 대해서 설명해 보겠습니다.
Peer A의 영상을 Peer B에게 전송한다는 가정이고, TURN 서버를 통한 relay 통신을 실험하기 위해서 host, stun 후보군은 제외하였습니다.
턴서버의 주소는 172.28.0.10 입니다. 실제 서비스 환경에서는 public ip 로 되어 있지만 여기서는 로컬에 턴서버를 구축한 관계로 사설 아이피 대역으로 설정되어 있습니다.
ICE Candidate Type Relay 후보 추출
WebRTC 핸드쉐이킹이 시작되면 Peer A에서 relay candidate를 추출하게 됩니다.
candidate:4028790502 1 udp 33562623 172.28.0.10 49160 typ relay raddr 0.0.0.0 rport 0 generation 0 ufrag e6kC network-cost 999
candidate:4028790502 1 udp 33562623 172.28.0.10 49185 typ relay raddr 0.0.0.0 rport 0 generation 0 ufrag e6kC network-cost 999
Peer B에서도 동일하게 relay candidate를 추출합니다.
candidate:2819796685 1 udp 33562623 172.28.0.10 49175 typ relay raddr 0.0.0.0 rport 0 generation 0 ufrag XjHw network-cost 999
candidate:2819796685 1 udp 33562623 172.28.0.10 49169 typ relay raddr 0.0.0.0 rport 0 generation 0 ufrag XjHw network-cost 999
candidate type의 relay가 2개씩 뽑히는 이유는 2개의 relay candidate type을 제공함으로써 다양한 네트워크 경로를 통해 연결을 시도할 수 있기 때문입니다. realy 외에도 다른 후보군 추출 시에도 동일하게 적용됩니다.
ICE Candidate 정보 해석
여기서 잠깐 relay 후보군의 구성 요소들에 대해서 자세히 알아보고 가겠습니다.
candidate:4028790502 1 udp 33562623 172.28.0.10 49160 typ relay raddr 0.0.0.0 rport 0 generation 0 ufrag e6kC network-cost 999
- foundation
- 4028790502
- ICE candidate의 고유 식별자
- 다른 candidate들과 구별하기 위한 값
- component ID
- 1
- ICE candidate의 구성 요소 ID
- 일반적으로 RTP 데이터(1)와 RTCP 제어(2)를 구별하는 데 사용
- transport
- udp
- 데이터 전송에 사용되는 프로토콜
- 여기서는 UDP를 사용
- priority
- 33562623
- ICE candidate의 우선 순위
- 높은 우선 순위는 더 선호되는 경로를 나타냄
- IP 주소
- 172.28.0.10
- ICE candidate의 호스트 주소
- 여기서는 TURN 서버의 아이피 172.28.0.10을 나타냄
- 포트 번호
- 49160
- ICE candidate의 호스트 포트 번호
- candidate type
- relay
- ICE candidate의 종류
- 여기서는 relay로, TURN 서버를 통해 중계되는 candidate을 의미
- related address (raddr)
- 0.0.0.0
- 클라이언트의 NAT 아이피
- 테스트 환경이 아닌 라이브 환경이라면 공인 아이피가 기록
- related port (rport)
- 0
- 클라이언트의 NAT 포트
- 테스트 환경이 아닌 라이브 환경이라면 0보다 큰 포트 번호가 기록
- generation
- 0
- ICE candidate의 세대를 나타내는 값
- ufrag
- e6kC
- ICE candidate에 대한 사용자 fragment
- ICE 프로토콜의 일부로서, ICE candidate의 구별자 역할
- network-cost
- 999
- 네트워크 비용을 나타내는 값
- 낮은 비용은 더 우선적인 경로를 나타냄
Relay 후보군 시그널링 서버를 통해 교환
각 Peer에서 생성한 relay candidate 메세지를 시그널링 서버를 통해 주고 받습니다.
이후 WebRTC 연결이 성공하게 됩니다.
TURN 서버에 접속하여 세션 검색을 해보겠습니다.
relay 후보군을 통해 WebRTC 연결이 되었다면 TURN 서버 세션 검색 시 다음과 같이 2개의 세션 정보가 출력됩니다.
그리고, usage 필드를 보시면 데이터 송수신 정보를 확인 할 수 있습니다.
rp : received packets 수신된 패킷 수 rb : received bytes 수신된 바이트 수 sp : send packets 송신된 패킷 수 sb : send bytes 송신된 바이트 수 |
172.28.0.10:49160 는 어떤 peer의 후보군이였을까요? peer A 입니다.
172.28.0.10:49169 는 어떤 peer의 후보군이였을까요? peer B 입니다.
위에서 peer A의 영상을 peer B에게 전송하는 테스트를 진행한다고 하였습니다.
그럼 데이터 흐름은 어떻게 될까요?
peer A --> 172.28.0.10:49160 --> 172.28.0.10:49169 --> peer B 와 같이 패킷이 relay 됩니다.
WebRTC 연결 성공 후 Peer A의 영상 패킷이 Peer B로 전달되는 순서
ICE Candidate pair: 172.28.0.10:49160 <=> 172.28.0.10:49169 와 같이 Peer A와 Peer B가 서로 연결되었습니다.
이제 Peer A에서 Peer B로 패킷 전송 시 다음과 같은 단계로 처리됩니다.
- 패킷 생성
- PeerA에서 영상을 전송하기 위해 패킷을 생성한다.
- 패킷 전송
- 생성된 패킷은 Peer A에서 자신이 할당받은 TURN 서버(172.28.0.10:49160)로 전송
- Peer A의 TURN 서버 처리
- Peer A에서 온 패킷을 TURN 서버(172.28.0.10)가 수신 받음
- TURN 서버는 패킷을 수신하고, 패킷의 목적지를 Peer B의 TURN 서버(172.28.0.10:49169)로 전달
- Peer B의 TURN 서버 처리
- 패킷을 수신 받음
- TURN 서버는 수신한 패킷의 목적지를 Peer B의 IP 주소와 포트로 변경하여 패킷을 전달
- Peer B에게 패킷 도착
- 최종적으로 Peer B에게 패킷이 도착
위의 과정을 그림으로 표현하면 아래와 같습니다.
Peer 각각이 서로 다른 TURN 서버와 연결되었을 때 패킷 전송 원리
peer A → peer B 에게 영상을 전송한다고 가정해 보겠습니다.
peer A는 turn1 번 장비에 대해서만 iceServers 목록 전달 (turn1번 172.28.0.10)
peer B는 turn2 번 장비에 대해서만 iceServers 목록 전달 (turn2번 172.28.0.11)
peer A relay candidate
candidate:1964472648 1 udp 33562623 172.28.0.10 49161 typ relay raddr 0.0.0.0 rport 0 generation 0 ufrag EdrE network-cost 999
peer B relay candidate
candidate:2491867983 1 udp 33562623 172.28.0.11 49288 typ relay raddr 0.0.0.0 rport 0 generation 0 ufrag EPsf network-cost 999
peer A는 peer B의 relay candidate를 전달 받음 172.28.0.11 49288
peerB는 peerA의 relay candidate를 전달 받음 172.28.0.10 49161
영상 전송 순서
- peer A → coturn1 172.28.0.10:49161 으로 패킷 전송
- coturn1번 서버는 세션 목록에서 172.28.0.10:49161에 해당하는 세션을 찾는다. 해당 세션에 등록되어 있는 peers 정보를 확인 (172.28.0.11:49288)
- 172.28.0.11:49288 로 패킷을 전달
- coturn2번이 영상 패킷을 수신
- peer B에게 전달
위의 과정을 그림으로 표현하면 다음과 같습니다.
172.28.0.10:49161 -> 172.28.0.11:49288 로 패킷을 전송하고 있다는 것을 무엇으로 입증 할 수 있을까요?
TURN 1 번의 세션 정보
| id=007000000000000006, user <test>: realm: localhost started 603 secs ago expiring in 538 secs client protocol UDP, relay protocol UDP client addr 172.28.0.1:34099, server addr 172.28.0.10:3478 relay addr 172.28.0.10:49161 fingerprints enforced: OFF mobile: OFF usage: rp=87742, rb=88889483, sp=10578, sb=545304 rate: r=148644, s=911, total=149555 (bytes per sec) peers: 172.28.0.11 172.28.0.11:49288 |
TURN 2 번의 세션 정보
| id=004000000000000001, user <test>: realm: localhost started 603 secs ago expiring in 537 secs client protocol UDP, relay protocol UDP client addr 172.28.0.1:36821, server addr 172.28.0.11:3479 relay addr 172.28.0.11:49288 fingerprints enforced: OFF mobile: OFF usage: rp=10578, rb=545222, sp=87742, sb=88891794 rate: r=913, s=148897, total=149810 (bytes per sec) peers: 172.28.0.10 172.28.0.10:49161 |
turn 1, turn 2번의 세션 목록 조회를 거의 동시에 했습니다.
total 데이터를 확인해 보면 약간의 오차가 있지만 거의 유사합니다.
즉, turn 1→ turn 2로 패킷을 전달하고 있다는 증거입니다.
지금까지 Turn 서버 Relay 통신 원리에 대해서 알아보았습니다.
'WebRTC' 카테고리의 다른 글
| WebRTC의 ICE Candidate 처리 순서 문제 (0) | 2024.12.26 |
|---|---|
| NAS에 TURN 서버 구축하기 (1) | 2024.12.20 |
| NAT 종류에 따른 홀펀칭 (3) | 2024.11.12 |
| NAT 종류 (0) | 2024.11.03 |
| WebRTC 테스트를 위한 Docker 환경 구성 (0) | 2024.09.22 |