WebRTC - 개념과 통신방식, 프로토콜

WebRTC

Real time Communication on Web Browsers / Mobile App을 가능하게 하는 Framework. 즉 text 형태로도, video 형태로도 가능하다는 뜻.

P2P만을 말하는 건 아니다. 단순한 P2P보다 훨씬 복잡함. 크게 네 가지 step을 거쳐 동작한다.

• Signalling
• Connecting
• Securing
• Communicationing. 보통 WebRTC를 사용한 통신의 대부분이 P2P인 것뿐이다.

왜 등장했는가?

 

 

WebRTC 이전에는 Server가 MiddleMan 역할을 했다.

즉, 사용자 간 통신의 모든 부하를 서버가 떠맡는 구조였다. Scalable에 한계가 있는 구조 / 유지하기 비싸다.

 

 

그럼 아예 이렇게 통신하게 하면 어떨까? 중간에 서버가 있는 것도 아니니 더 private하고, 서버 유지비용도 없다.

 

 

 

두 명의 사용자에겐 각각의 라우터가 있다. 통신을 한다는 건, 라우터가 상대방의 위치까지 찾아갈 수 있다는 것. 이 경우 라우터에는 Unique Address인 IP주소가 있다. IP주소가 있다면, BOB과 John은 서로 통신할 수 있다.

 

 

 

1. Signaling

 

누가 누군가를 Call할 때, 그걸 중재하는 서버가 Signaling Server. 예컨대 bob이 john과 통신하고 싶을 때 john에게 알려주는 역할을 한다. 통신할 때 '어떤 종류의 통신을 원하는지 - video / chat 등등' 의 정보도 같이 전송한다.

서로 통신에 OK사인을 보내면, Signaling Server를 통해서 자신의 IP주소를 교환한다.

 

 

 

 

2. Stun

보통 public ip인 공유기에는 여러 private IP주소가 내부적으로 라우팅되어 있다. 공유기에 연결된 노트북과 핸드폰은 서로 다른 private IP를 사용하고 있다. 여기서, 노트북과 핸드폰처럼 private IP를 할당받은 디바이스는 자신의 public IP주소를 모른다.

 

따라서 예컨대 공유기로 연결한 노트북을 가지고 다른 사람과 통신하려면, 노트북에서 자체적으로 자신의 public IP주소를 알고 있어야 한다. 이걸 가능하게 하는 게 Stun Server.

 

즉 노트북은 Stun Server를 통해 자신의 public IP주소를 알아내게 된다.

 

 

 

 

 

3. Turn

이제 연결이 완성되면, 통신을 위해 이전의 traditional Server가 하던 일들은 전부 client가 담당하게 된다.

• relay all information from the other one.

혹시라도 connection 연결이 제대로 되지 않았을 때를 대비해서 traditional Server 역할을 하는 게 turn server다.

일종의 백업 서버인 셈이다.

 

WebSocket

Establishing Bidirectional Communication with another Entity.

• Implementing Signaling Server에 사용되기도 하는 기술.

 

일반적인 통신절차는 위와 같다. request / response가 존재하는 구조. 이 방식은 실시간 통신을 구현하는 데에는 너무 느린 방식이다.

 

 

아예 이렇게 하나의 Connection을 상대방과 만들어놓는 것. WebRTC의 경우 Server 대신 다른 client가 들어가 있을 수 있다.

• 최대 특징은 Bi-directional. 상호간에 request / response가 이루어지는 구조이며, 하나의 Link만 존재한다.

이 링크에 사용하는 통신 프로토콜이 WebSocket.

 

---

WebRTC 구성하는 프로토콜

소개되는 프로토콜은 대략 20년의 역사를 가진, 이미 분명한 용도를 가지고 존재하는 프로토콜들. 각각을 잘 이해해야 WebRTC의 흐름을 이해하고 따라갈 수 있다.

 

WebRTC는 크게 네 단계를 거쳐 이루어지며, 각각의 단계마다 사용하는 프로토콜이 다르다.

1. Signaling
   • SDP (Session Description Protocol.)
2. Connection
   • ICE (Interactive Connectivity Establishment)
3. Security
   • DTLS (Datagram Transport Layer Security)
   • SRTP (Secure Real-time Transport Protocol)
4. Communicating :
   • RTP (Real-time transport Protocol)
   • SCTP (Stream Control Transmission Protocol)
   • RTCP (Real-time Transort Control Protocol)

---

SDP

이름 그대로, Session의 Description을 담당하는 프로토콜.

• 생성할 세션의 타입 정보를 전송한다.

 

처음에 Bob이 John에게 통신 요청을 하는 걸 offer, John이 응답하는 걸 Answer라고 한다.

• offer애는 통신 종류가 video / audio인지, 인코딩에는 어떤 방식을 사용할 것인지, ip주소값 등의 정보가 들어 있다.
• 이 정보를 서로 교환해야만 통신이 가능하다.

일반적으로 Web에서는 Json을 사용해 통신하지만, SDP는 key=value 형태로 데이터를 전송하며,

아래의 7가지 key값만 사용할 수 있다.

 

 

보통 패키지 레벨에서 위 Key에 대응되는 값을 다 채워넣지만, customize가 필요할 수 있으니 알아둬서 나쁘진 않다.

---

ICE

peer connection을 담당하는 framework. 일반적으로 Peer Connection이 필요한 경우는 크게 세 가지다.

1. 동일한 라우터를 공유하는 경우: 그냥 connect 가능하다.

 

2. 서로 다른 라우터를 가지고 있는 경우.
   • 이 경우, 자신의 public IP주소를 알아내기 위해 stun server를 사용한다.
   • 자신의 public IP주소를 토대로 상대방과 통신한다.

 

Bob이 자신의 public IP주소를 stun server를 통해서 알아내고

 

 

마찬가지로 John도 알아낸 뒤

 

 

public IP주소를 토대로 통신한다.

 

 

3. 어떤 이유에서건 P2P 통신이 불가능한 경우.

연결을 중재해줄 서버가 필요하며, 이 서버의 이름을 TURN server라 부른다.

이렇게 세 가지의 통신을 지원하는 Framework가 ICE라고 보면 된다.

 

---

RTP / RTCP

 

Bob이 audio call을 요청하는 상황이다. Bob의 audio stream값이 상대방에게 전송된다.

• 이 전송되는 데이터의 format이 RTP라고 보면 됨.

voice call이 진행중인 상황에서 상대방이 말하고 있으면, 나는 침묵하게 된다.

그러면, 굳이 이 침묵이 담긴 데이터 패킷을 상대방에게 전송할 필요는 없다. 대역폭 낭비니까.

 

• RTCP가 이런 역할을 한다. 일종의 statistic tool for RTP. active call인지 체크해서 대역폭을 낭비하지 않도록 조절하는 것. RTP의 통계값을 의미한다고 보면 된다.

 

video의 경우도 비슷한다. 즉 stream을 전송하려면 RTP로 실제 패킷을 담고, RTCP로 통계값을 사용한다. RTCP로는 bandwidth packet loss 등의 정보를 담고 있으며, 불필요한 대역폭 낭비를 줄이는 역할도 한다.

---

SCTP

Stream Control Transmission Protocol로, RTP / RTCP와 같은 Communication Protocol 분류에 들어간다.

• RTP와 RTCP는 미디어, 오디오, screen sharing할 때만 적용이 가능한 통신 프로토콜이다.
  세 가지 경우가 아니라면 사용이 불가능함.

 

• 그래서 SCTP도 사용한다. File sharing / text message / game 관련 등
  비디오나 오디오를 제외한 나머지 데이터를 통신에 활용할 때 쓴다.

 

 

 

 

데이터를 small chunk로 분리한 뒤, 채널을 통해 전송하는 식.

• 채널 중 하나가 congested -> 다른 채널을 통해 상대방에게 데이터를 송신한다.
• = Manages Network Congestion.

---

DTLS, SRTP

둘 다 Security Protocol. Peer to Peer로 전송되는 데이터는 개인의 웹캠이나 목소리, 기타 등등 private한 정보일 가능성이 크다.

해커가 중간에서 데이터에 접근하지 못하게 할 방법이 필요함.

 

 

기본적인 로직

• Signaling 과정에서 하나의 certificate를 생성하고, 서로 교환한다.
• 그러면, 서로 교환한 certificate로 데이터를 복호화 (decrypt) 해서 데이터를 확인할 수 있게 된다.
• 설령 중간에 해커가 데이터를 가로챈다 해도, 복호화는 불가능하도록 만드는 것.

SRTP : RTP 데이터를 암호화 (Encrypt) 하는 프로토콜 : RTP에서 사용하는 데이터인 미디어, 오디오, sharing screen에 사용된다.

DTLS : RTP 제외한 나머지 데이터의 통신 과정에서 사용한다.