WebRTC (1)

1) webRTC란 무엇인가?

 

• WebRTC (Web Real-Time Communication) → '웹 기반 실시간 통신 기술'
• 구글이 WebRTC의 기반이 되는 기술을 인수 (ex. On2, GIPS) 해서 오픈소스로 공개함.
• 웹 애플리케이션 (브라우저) 간 '중간 서버 없이' 오디오/비디오 등의 '데이터를 교환'할 수 있는 기술.
• 기본적으로 P2P로 동작하며 'UDP 기반의 RTP 프로토콜'을 사용함.
• 주요 브라우저에서 JavaScript API로 제공된다.

---

 

2) WebRTC를 이해하기 위한 사전 지식

 

2-1) NAT

• NAT (Network Address Translation)는 'private IP를 public IP로 대응하기 위한 기술'
•  여러 장치의 host가 하나의 public IP 주소를 사용하여 인터넷에 접속하기 위한 경우
  • IPv4의 경우 0.0.0.0 ~ 255.255.255.255 까지 총 2^32 개의 주소만 만들 수 있음 (4bytes)
  • NAT을 이용하여 IPv4를 쓰더라도 훨씬 많은 기기들이 인터넷을 사용할 수 있게 됨.
• NAT를 통해 외부에서 보여지는 public IP와 내부에서 사용하는 private IP가 따로 관리되기 때문에 private network에 대해 어느 정도 보안 역할을 수행함.
• 두 개의 Peer가 NAT 뒤에 있다면 서로의 public IP를 알고 있지 않다면 private IP로는 P2P 통신이 불가능함.
  • WebRTC에서는 이것을 해결하기 위해 'STUN, TURN' 서버를 이용함

 

 

2-2) NAT의 종류

• Full Cone NAT
  • 가장 간단한 NAT 방식으로 private ip와 public ip가 매칭되면 외부 network 가 public ip로 접근 시 NAT 뒤 host와 통신이 가능함.
  • 통신을 하던 목적지가 아님에도 'NAT로 매핑된 정보'만 안다면 누구든지 Host에게 패킷을 전달할 수 있음.

 → ex) Service B는 Host와 통신을 주고받지 않았으나 Service A와 Host가 통신하면서 Routing table에 해당 맵핑 정보가 생겼으므로 이를 바탕으로 통신이 가능해짐
 

• Restricted Cone NAT
  • Full Cone NAT와 비슷하지만 기존에 통신하던 IP가 아니라면 Host에게 패킷이 도달하지 않음

→ ex) 위와 비슷하게 Routing table에 맵핑 정보가 생겼으나 4.4.4.4의 경우 포트번호는 같아도 8.8.8.8과 IP 주소가 다르므로 Host에게로 패킷 전달 X

 

• Port Restricted Cone NAT
  
  • Restricted Cone NAT에서 Port 번호 제한까지 생긴 경우이다.
  • 새로운 Serivce가 Host에게 패킷을 보내려 할 때 기존에 통신을 하던 Service의 맵핑 정보 (Server IP, Port number 둘다) 확인 → 비교하여 둘 중 하나라도 다를 경우 Host에게로 패킷 전달 X 

 

→ ex) 기존에 통신하던 8.8.8.8 : 8888과 IP address or Port number가 다른 곳으로부터 요청이 들어오면 Host에게로 패킷 전달 X

• Symmetric NAT
  • 위 3개의 Cone 방식의 NAT와는 차이가 있음
  • Cone 방식의 NAT의 경우 Router와 맵핑이 이루어져 table에 해당 정보가 기록된 후 계속해서 해당 정보만 사용함 
  • Symmetric NAT의 경우 IP Address/Port 기반으로 각기 다른 맵핑 정보를 기록함.
    • Host가 통신하는 대상에 따라 각기 다른 맵핑 정보를 가져감.
    • peer들이 오직 이전에 연결한 적 있는 연결들만 허용한다는 것

→ ex) 8.8.8.8:8888의 경우 10.17.230.81:100000에 맵핑됟고 4.4.4.4:7777의 경우 10.17.230.81:20000에 맵핑됨

 

 

2-3) ICE

 

• ICE (Interactive Connectivity Establishment)는 브라우저가 'peer를 통한 연결이 가능하도록 하게 해주는 프레임워크'
• 방화벽, NAT 문제 등으로 P2P 연결이 불가능한 상황이 존재함.
  • 연결을 위해 방화벽을 넘어야함
  • 단말에 public IP가 할당되어 있지 않다면 주소값을 할당해야함.
  • 'Symmetric NAT' 와 같은 경우 P2P 연결이 불가능함.
• STUN, TURN 서버를 이용하여 P2P를 가능하도록 함.

 

2-4) STUN

 

• STUN (Session Traversal Utilities for NAT) 는 '해당 Peer의 public IP를 알려주는 역할을 하는 서버'이다 
  • ex) 네이버에 "ip주소" 를 검색하면 본인의 public ip주소를 확인할 수 있다.
• 각 Peer는 인터넷을 통해 Peer의 public IP와 NAT 뒤에 있는 Peer가 접근 가능한지에 대한 답변을 위한 요청을 STUN서버에 보냄.
• 위에서 언급한 것과 같이 Symmetric NAT 등 NAT 정책이 엄격한 경우 STUN을 이용하여도 P2P 연결이 불가능함.
  • (서비스마다 Port 번호가 달라지는 등의 이유)

 

→ 각 Peer가 STUN server에게 본인의 public IP와 NAT 뒤에 있는 본인에게 접근 가능한지 여부를 요청 보냄

 

 

2-5) TURN

• TURN (Traversal Using Relays around NAT) 는 STUN으로 P2P 연결이 힘들 경우 '패킷을 릴레이 하기 위해 사용'된다.
• P2P에 비해 서버를 한번 거치기 때문에 RTT가 늘어나며 리소스 낭비가 있으므로 P2P 통신이 아예 안되는 상황에서 최후의 수단으로 사용함.

 

참고

• mozilla webRTC API: https://developer.mozilla.org/ko/docs/Web/API/WebRTC_API
• 'millo' blog: https://millo-l.github.io/WebRTC-%EC%9D%B4%EB%A1%A0-%EC%A0%95%EB%A6%AC%ED%95%98%EA%B8%B0/
• 'gh402' tech blog: https://gh402.tistory.com/45
• kakao enterprise tech blog: https://tech.kakaoenterprise.com/121