항해 99 5기 TIL_86

▶ Today I Learned

 

<실전 프로젝트>

 

[STUN서버와 TURN 서버]

 

WebRTC를 사용하다 보니 stun서버와 turn서버라는 개념이 등장했다.

우리의 경우 구글에서 제공되는 stun 서버의 주소를 임의로 사용하였는데 각각에 대해서 조사해보았다.

 

우선 두 서버가 사용되는 이유는 WebRTC에서 Peer간의 시그널링이 필요한 데 유저 간에 방화벽이나 NAT환경이 존재할 경우

직접적인 시그널링이 불가능하다. 따라서 중간에서 중개해줄 대상이 필요한데 이 때 사용되는 것이 STUN서버와 TURN 서버이다.

 

STUN: Session Traversal Uilities for NAT의 약자,

MDN 문서에 따르면 NAT을 할 때 데이터를 전송하는 보조 프로토콜이다. STUN은 IP 주소와 포트, 그리고 NAT에서 네트워킹되는

컴퓨터의 연결 상태를 반환해준다.

STUN 클라이언트(사설 망에 위치)는 자신이 사용할 공인 IP주소를 알 수 가 없어서 STUN 서버(인터넷 망에 위치)에 자신의 공인 IP 주소를 요청한다.

STUN서버는 사설 주소와 공인 주소를 비교하고 이를 바인딩한 다음 클라이언트에 응답을 해주게 된다.

(cf. 한 사이트에 따르면, 대부분의 경우 TURN 서버와 함께 설치된다.)

구글이 제공하는 것과 같은 무료 STUN 서버도 있지만 무료 버전은 상업적인 용도로 쓰는 것을 권장하지 않는다.

STUN는 비교적 가볍고 비용이 많이 들지 않지만 네트워크 구조와 NAT 기기 타입에 따라 제대로 작동하지 않는 경우가 있다.

이럴 때는 TURN 서버를 사용해주어야 한다.

(두 단말이 같은 NAT 환경에 있는 경우 and

사설망 환경이 Symmetric NAT으로 동작하는 경우 - 애플리케이션이 다르면 NAT 매핑 테이블이 달라짐)

 

MDN 공식문서에 나오는 STUN 방식

 

 

TURN: Traversal Using Relays around NAT의 약자,

MDN 문서에 따르면 이 역시 NAT을 할 때 데이터를 전송하는 보조 프로토콜이다. WebRTC에서 두 기기 간의 P2P connection을 위해 사용된다.

TURN 프로토콜은 STUN과 다르게 NAT 환경에서 단말이 릴레이 서버를 사용하여 통신하게 한다. STUN은 공인 주소와 사설 주소를 바인딩 하였으며 피어 간 직접 통신을 하는 반면 TURN은 피어 간 TURN 서버를 이용해 통신하는 것이다.

TURN 는 특히 ICE에서 직접 사용된다.TURN은 클라이언트와의 연결을 거의 항상 제공해주지만 STUN에 비해 리소스 낭비가 심하기에 상대적으로 latency(지연)이 발생할 수 있다. 그렇기에 다른 방식으로 연결되지 않을 때 최후의 수단으로 사용하는 것이 좋다.

MDN 공식문서에 나오는 TURN 방식

 

 

[ICE]

 

Interactive Connectivity Establishment의 약어, 두 단말이 서로 통신할 수 있는

최적의 경로를 찾을 수 있도록 도와주는 프레임워크

 

* ICE Candidate Gathering: STUN 방식으로 Server Reflexive Address (자기 단말의 공인 IP주소와 포트 넘버), TURN 방식으로 Server Reflexive Address(자기 단말의 공인 IP 주소와 포트 넘버)와 Relayed Address (TURN 서버의 IP 주소와 포트 넘버)를 찾아내며 자기 자신의 Local Address (자신의 사설 IP 주소와 포트 넘버)까지 총 3개의 통신이 가능한 주소를 식별하는 것,

ICE를 실행하는 단말들은 이렇게 모든 주소를 식별하여 최적의 경로를 찾아서 연결시켜준다.

 

 

[NAT]

 

 

Network Address Translation, 참조 홈페이지에 따르면 네트워크 주소를 변환해주는 방식 정도로 해석된다.

여러 대의 기기를 다루지만 모두 하나의 IP 주소를 사용하고 싶을 때 주로 사용하는 방식이며 대부분의 가정에서 사용되는 라우터도

이 방식을 사용하고 있다.

각각의 PC는 Local Private IP address를 가지고 있다.

여기서 우리가 어떤 정보를 전송할 때 그 정보를 받는 네트워크 서버가 우리의 요청을 처리하고 응답하기 위해서는

Public IP address가 필요하다. 따라서 정보 전송 시 라우터에 패킷 형태로 데이터를 담아 보내고 라우터에서는

로컬 IP를 Public IP로 바꿔준다.

 

* NAT의 종류

 

Static NAT: 로컬 IP가 특정한 Public IP로만 변환되는 방식, 해당 라우터나 NAT 기기가 특정 Public IP와 연결된 경우.

Dynamic NAT: 로컬 IP가 변환될 때 마다 매번 다른 Public IP를 사용하는 경우

PAT: Port Address Translation의 약자, Dynamic NAT의 한 종류이지만 몇 개의 로컬 IP를 특정 Public IP 하나에 묶는 방식,

네트워크 관리자의 감독하에 모든 직원들이 하나의 Public IP를 쓰게하고 싶을 때 사용

 

그런데 찾다보면 full cone NAT, symmetric NAT (Dynamic PAT) 등 NAT 종류라고 나오는 자료들이 더 있다.

NAT 종류가 무수히 많은 건가 찾던 도중 아래의 링크를 발견하였다.

https://www.practicalnetworking.net/series/nat/nat-terminology-disambiguation/

 

각각의 vendor들이 NAT 개념들의 용어가 달랐던 것이다.

즉, 위에 적어놓은 NAT 종류가 다른 곳에서는 다르게 불릴 수 있는 것이니 자세한 것은 표를 참조하자.

 

[NAT를 사용하는 이유?]

 

1) 엄청난 IP 수요를 감당하기 위해

IP주소는 인터넷에 연결된 기기를 식별하는 역할을 하는데 기존에 사용되던 IPv4는 32비트의 IP주소를 사용하며 이는 약 40억개의 주소를 사용가능하게 해주었다. 과거라면 충분했지만 인터넷이 발달하고 태블릿, TV, 스마트 폰 등 기기가 늘어나는 요즘엔 70억 인구가 사용하기엔 주소가 부족하게 되었다. 2012년 6월에 이러한 IP 수요를 수용하기 위해 IPv6가 출시되었고 이 버전은 128비트를 사용하기에 훨씬 더 많은 IP주소를 사용할 수 있게 되었다. 하지만 여전히 IP 수요 증가와 공급이라는 일련의 과정들이 마무리 되는데는 많은 시간이 소요될 것이며 그때까지는 NAT가 유용한 툴이 될 것이다.

 

2) 보안을 위해

NAT은 데이터 패킷을 Public에서 Private 주소로 전달해주는 역할을 하며 그 외 다른 어떤 것이 Private 기기에 접근하는 것을 막아준다.

모든 것을 막아줄 순 없지만 NAT 방화벽은 첫번째 보호수단으로써 많이 활용된다. 또한 NAT은 로컬 네트워크에서도 Public IP가 표시되도록 해주기에 데이터와 유저 기록을 모두 Private하게 유지시켜준다.

 

 

▶ 느낀 점

 

STUN과 TURN, 더불어 NAT과 ICE에 대해서 조사해보았지만 깊이 들어가면 갈수록 너무 깊이 들어가게 되는 듯 했다.

생각보다 알아야 할 것이 너무 많아 우선은 많은 한글, 영어 자료를 찾아본 다음 최대한 정리해보았다.

좀 더 깊이 들어가기 위해서는 차차 해당 기술들을 좀 더 사용해보고 관련 자료들을 더 접해보아야 할 것 같다.

그래도 이렇게 한 번 시간을 들여 조사해보니 왜 프로젝트에서 STUN이나 TURN 서버가 필요한 것인지 더 잘 알 수 있었다.

 

 

▶ 공부 시 참고 링크들

NAT

https://www.comptia.org/content/guides/what-is-network-address-translation

 

stun 서버

https://developer.mozilla.org/en-US/docs/Glossary/STUN

https://webrtcglossary.com/stun/#:~:text=STUN%20stands%20for%20Session%20Traversal,the%20other%20one%20is%20TURN).

 

turn 서버

https://developer.mozilla.org/en-US/docs/Glossary/TURN

 

ICE, STUN, TURN 서버 이해

https://brunch.co.kr/@linecard/156#comment

 

stun 서버 및 turn 서버

https://andonekwon.tistory.com/59

https://emong.tistory.com/140

https://webrtc.ventures/2020/12/webrtc-signaling-stun-vs-turn/

 

stun서버의 역할을 잘 설명한 이미지

https://millo-l.github.io/static/f3467aed345c1199ea1e3ddd5928b672/a2ead/webrtc-stun.png

 

cf) SDP란?

https://m.blog.naver.com/pentamkt/221935558971

 

STUN 및 TURN 이미지 출처

https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Protocols