[Full-Stack Network] 9. WebRTC

🍏 WebRTC

• google meet / zoom
• 모바일 real time communication에 많이 쓰인다

✅ Client-Server vs Peer-to-Peer

• P2P
  Client들이 서버없이 상대방과 통신을 하는 것. Client들이 서로와 연결. 중앙집중화 된 서버가 없다.
  • 중앙 서버가 없다 = 직접 하나하나 소켓을 뚫고 관리하고.. 엄청난 일들을 해야 한다.

• Client-Server
  • 중앙집중화된 서버
    Peer들 간에 통신을 할 때 서로를 인식하거나 메세지를 전달하는 것을 서버에게 위임

✅ Block Chain - P2P

• P2P 방식을 기반으로 생성된 체인 형태의 연결고리 기반 분산 데이터 저장 환경에 데이터들을 저장
• 거래를 만들고 거래정보를 모든 NODE에 뿌림
  모두가 우리의 거래에 대한 정보를 가짐.
• 순수한 p2p입장에서 블록체인을 구현해서 올릴 곳은 가전제품,스마트폰,노트북 뿐

✅ WebRTC

• 구글이 GIPS 회사를 인수 후 Rebranding
• Open Source로 공개하고, 표준화

✅ WebRTC - 목적

• Web을 기반으로 한 real time communication
• 웹브라우저만 있으면 따로 설치 없이 화상 회의가 가능하도록 한다.
• 웹브라우저에 webRTC 기술이 내장되어있기 때문에 코드 조금만 쳐도 화상회의 기능을 사용할 수 있다.

p.13

• 연결 설정을 하는 과정

✅ ICE

= Interactive Connectivity Establishment

STUN / TURN Server

• 브라우저가 peer를 통한 연결이 가능하도록 해주는 framework
• Peer A에서 Peer B까지 단순 연결의 한계 / 서버가 없을 때의 한계
  • 연결을 시도하는 방화벽을 통과해야 한다.
    Privite IP Add가 방화벽을 뚫고 Public으로 가는 것이 쉽지 않다.
  • NAT/PAT를 통과했을 때 어떤 Public IP로 바뀔지 알 수 없다.
  • 라우터가 P2P를 다 막아버리는 경우도 많다.

✅ STUN Server

= Session Traversal Utilities for NAT

• Client의 Public IP 주소를 알려주는 서버
• NAT를 통과해 서로의 대화를 나눌 수 있도록 한다.

• A와 B의 바깥에 있다.
• 인터넷을 통해 통신하는 두개의 단말은 Private IP로 할 수 없으니 본인과 상대방의 Public IP Add를 반드시 알아야 통신할 수 있다.

• Client는 Privite IP는 아는데 Public IP는 몰라서 질문(who am I?) -> STUN이 Public IP를 알려준다.
• Client가 NAT 뒤에 있는 경우에도 통신이 가능하도록 한다.

✅ FYI : NAT (Network Address Translation)

• NAT/PAT는 표준화된 기술이 아니기 때문에 회사에 따라 천차만별
• symmetric NAT에서는 STUN 서버가 무력화된다 (TURN 등장)
• symmetric NAT : Public ID를 가져오려면 NAT 앞뒤의 Client들이 서로 Data를 주고받고 있어야 한다.
• P2P의 문제 : 표준화된 기술을 쓰지 않고 라우터나 네트워크 장치의 도움을 전혀 받지 않기 때문에 결국은 네트워크이나 라우터에 의해서 문제가 생길 가능성이 높다.

✅ TURN 서버

= relay 서버
믿을 수 있는 사이트에 대해서만 NAT 허용

• Message를 전달할 때 직접 peer가 peer에게 전달하지 않고 TURN 서버가 대신 전달해준다. Symmetric NAT 제한 등을 우회한다.
• NAT를 통과해야하는데 직접 통과할 수 없기 때문에
  이 릴레이를 경유함으로써 Peer B까지 가는 경로를 뚫는 거니 사실상의 트래픽을 받아서 릴레이하는 대리자를 서버로 두는 겁니다.
  

✅ FYI : SDP

= Session Description Protocol

• 앞서 한 것들은 연결 설정
• SDP를 통해 메세지에 대한 설명을 덧붙여 주는 것
  • SIP를 가지고 연결을 하고, 연결을 표현하기 위해서 SIP로 주고받는 메세지 안에 SDP 형태의 메세지를 담는다.
• 미디어 전달도 가능 / 미디어에 대한 다양한 정보들을 담아 보냄. (오디오 포맷, 비디오 포맷, 데이터 형태, 프레임,압축방식 등등)
  

✅ WebRTC 동작 구성 예시

• 순수한 P2P / Private Zone 내 Peer간 통신
  

• NAT 라우터에 연결된 Peer 간 통신
  • NAT를 넘어서 A와 B가 연결설정을 해야 한다.
    

• WebRTC Peer & Server Full Configuration
  
  • STUN/TURN Server
  • Signaling Server
    • 내가 대화하고 싶은 상대방을 찾아서 전달

✅ WebRTC = P2P ?

• 서버가 많은데 왜 P2P?
  • 연결 설정은 서버로 했지만 트래픽을 주고받는 것은 Peer들이 직접 한다. 보통 TURN 서버 없이 직접 주고받는다.

• Peer간 Data를 직접 송수신하는 것이 기본 구조 (P2P)
  • Signaling Server에게 SDF 전달
  • Signaling Server를 통해 서로 필요한 정보들을 주고받은 후 연결을 한다.
  • 연결 후에 실질적인 데이터는 직접 주고 받는다.
  • SDF : 주고 받을 미디어 대한 정보들
    ex) 오디오 포맷, 비디오 포맷, 데이터 형태, 프레임,압축방식
    
• P2P로 할 경우
  • 서버를 경유하지 않으려면 처리할 일이 많으므로 CPU를 많이 사용
  • 트래픽을 보낸 사람과 받는 사람만 가지고 있다 -> 범죄 악용 가능성 O ex)텔레그램
  • 회사 입장에서도 용량이 큰 미디어가 서버를 경유하는 것을 원하지 않는다.

소규모는 p2p로 / 규모가 클 수록 대신 방송을..

✅ WebRTC 주요 구성요소

• ICE / TURN / STUN Server 들은 보통 UDP 위에 올라간다.
  = WebRTC로 데이터를 주고 받는 과정에서는 UDP가 개입된다.
  

• UDP의 걱정거리 : 에러 검출 및 복구
  • UDP 위에 SCTP(TCP 진화버전)를 올려서 데이터 교환 -> 에러 검출 및 복구를 지원하여 신뢰성을 높인다
• SRTP : real-time / 오디오와 비디오를 실어나른다
  

✅ WebRTC 주요 표준기술 요약

✅ WebRTC 장점

• Near Real-time
  • UDP를 사용해서 지연 감소
  • real time communication을 위해 만들어짐
• Inherently Low Latency
  • 지연 감소
• Platform and Device Independence
  • 웹 브라우저에 위에서 돌아가도록 만든 기술
  • 따라서 OS나 디바이스 관계 없이 웹 브라우저만 있으면 된다.
• 오픈소스화 & 표준화
• Adapts to Network Conditions
  • 서버로부터 가져오는 파일들이 네트워크의 성능에 따라 달라질 수 있다.
  • simulcasting : 보내는 쪽에서 다양한 해상도로 보내고, 받는 쪽에서 처리할 수 있는 data rate를 판단해서 받아라. Bandwidth는 좀 낭비되어도 최고의 품질로 받을 수 있다는 장점. 처음에 480 보여주고 속도에 따라 화질을 올리는 방식 -> 지연을 줄일 수 있다.

✅ WebRTC 단점

• Scalability = p2p의 단점
  • P2P면 대화하는 애들이 많아질 수록 직접 데이터를 보내야 할 대상이 많아진다. 따라서 화상회의에 들어와 있을 수 있는 유저의 수는 제한(50)개될 수밖에 없다. 서버를 사용하면 훨씬 많은 사용자 수용 가능.
  • 미디어가 대용량화 되면서 서버가 필요해졌다.
• Broadcast Quality
  • 미디어 퀄리티(화질) 저하