Web RTC 관련 지식 메모

konut ko·2023년 2월 6일
1
post-custom-banner

2023년 2월 6일 월요일


http vs 웹소켓 vs Web RTC

참고
socket.io는 웹소켓 구현체로 Node.js의 라이브러리 이다.

[ web RTC 사전 지식 ]

  • http 통신과 웹소켓 통신 차이
http 통신이 벽과 치는 탁구라면, 웹소켓 통신은 양방향 소통의 전화통화로 비유 할 수 있다. http 통신은 브라우저에서 서버로 주기적으로 요청을 보내야만 서버에서 실시간으로 브라우저의 상황을 알 수 있다.
  • 웹소켓 : 웹소켓 서버에 브라우저가 각각 연결된다. 그리고 통신이 항상 열려 있어서 실시간 양방향 소통이 가능하다. 브라우저1에서 — 서버 — 브라우저2로 연결되어 서버를 꼭 거치기 때문에 연결된 브라우저가 많을 경우 서버의 메모리 부담이 가중된다는 단점이 있다. (서버가 내려가면 누구도 대화할 수 없다는 문제도 있다.) “메시지를 받으면, 다른사람에게 이걸 포워딩 해야하니까!”
  • web RTC(web real time communication) : 실시간 양방향 소통을 할수있다는 점에서 웹소켓과 같지만 web RTC는 통신을 하는 브라우저끼리 이어져서 요청을 주고받는 P2P 통신 (peer to peer)이라는 점에서 차이점이있다. web RTC는 P2P 통신으로 텍스트(채팅), 영상, 오디오 등을 모두 실시간으로 주고받을 수 있고, 이 모든 것을 중개자인 서버를 거치지 않고 브라우저끼리 전달하기 때문에 빠르다는 장점이 있다. 하지만 단점도 있는데 web RTC의 확장성에는 제한이 있다는 것이다. 만약 비디오 채팅방에 1000명이 접속해있다면 ‘접속자1’은 999명의 영상을 다운받아야하고 자신의 영상도 999명에게 전송해주어야 한다.

용어 : 패킷, 포워딩

  • 패킷, packet (동의어 : 다발) : 데이터 전송에서 사용되는 데이터의 묶음. 패킷 전송은 두 지점 사이에 데이터를 연속적으로 전송하지 않고, 전송할 데이터를 적당한 크기로 나누어 패킷의 형태로 구성한 다음 패킷들을 하나씩 보내는 방법을 쓴다. 각각의 패킷은 일정한 크기의 데이터뿐만 아니라 데이터 수신처, 주소 또는 제어 부호 등의 제어 정보까지 담고 있다. 보통 한 패킷은 1,024비트 데이터를 담을 수 있다.

  • 패킷 포워딩, packet forwarding
    : 다양한 네트워크들을 연결하는 스위칭이나 라우팅 장비에서 수행되는 동작으로, 들어온 패킷의 헤더 정보를 이용하여 최종 목적지 네트워크을 향해 패킷을 내보내 주는 일련의 단계. 초기 인터넷에서는 패킷의 2계층과 3계층의 헤더 정보만으로 이루어졌으나 최근에는 4계층 헤더까지 참조하는 패킷 분류(packet classification)를 수행하고 있으며, 오디오나 비디오 스트리밍의 서비스 품질(QoS) 보장과 방화벽, 웹 스위칭 등 다양한 서비스를 제공하는 5계층 이상의 헤더 정보도 참조하여 수행하게 된다.

  • 포워딩, forwarding : (내보내준다, 보내준다, 전송 등의 느낌으로 쓰는 것 같다.)


용어 : TCP/ UDP

TCP : 전송 제어 프로토콜, 傳送制御-, Transmission Control Protocol
UDP : 사용자 데이터그램 프로토콜, 使用者-, User Datagram Protocol

인터넷의 표준 프로토콜 집합인 TCP/IP의 기반이 되는 프로토콜의 하나.

TCP/IP에서는 망 계층(OSI의 제3계층에 해당) 프로토콜인 IP와
전송 계층(OSI의 제4계층에 해당) 프로토콜인 전송 제어 프로토콜(TCP)
또는
사용자 데이터그램 프로토콜(UDP)
의 어느 하나를 조합하여 데이터를 주고받는다.

TCP에서는 세션(접속)을 설정한 후에 통신을 개시하지만, UDP에서는 세션을 설정하지 않고 데이터를 상대의 주소로 송출한다. UDP의 특징은 프로토콜 처리가 고속이라는 점이다. 그러나 TCP와 같이 오류 정정이나 재송신 기능은 없다. 신뢰성보다도 고속성이 요구되는 멀티미디어 응용 등에서 일부 사용된다.


Media Capture and Streams API (미디어 스트림)

  • 오디오와 비디오 데이터 스트리밍을 지원하는 WebRTC 관련 API 입니다. 이 API는 미디어 스트림과 스트림을 구성하는 트랙, 데이터 형식과 관련된 제한인자, 데이터를 비동기적으로 사용할 때의 성공과 오류 콜백, 그리고 이 과정에서 발생하는 이벤트에 대한 인터페이스 및 메서드를 제공합니다.

개념 및 사용법

  • 이 API는 오디오 혹은 비디오와 관련된 데이터를 나타내는 MediaStream (en-US) 객체 조작에 기반합니다.
  • MediaStream은 0개 이상의 MediaStreamTrack 객체로 구성되며, 각자 다양한 오디오와 비디오 트랙을 나타냅니다. 각각의 MediaStreamTrack은 하나 이상의 채널을 가질 수 있습니다. 채널은, 오디오로 예를 들면 스테레오 오디오 트랙에서의 "왼쪽"과 "오른쪽"처럼, 미디어 스트림의 제일 작은 단위를 나타냅니다.
  • MediaStream 객체는 하나의 입력과 하나의 출력을 가집니다. getUserMedia()로 생성한 MediaStream 객체는 "로컬" 미디어 스트림이라고 부르며, 사용자의 카메라와 마이크 중 하나를 입력 출처로 사용합니다. 반면 '<video'>, <'audio>'와 같은 미디어 요소, 네트워크에서 들어오는 스트림, WebRTC RTCPeerConnection API로 획득한 스트림, Web Audio API MediaStreamAudioSourceNode (en-US)로 생성한 스트림 등은 비 로컬 MediaStream이라고 합니다.
    출처 : https://developer.mozilla.org/ko/docs/Web/API/Media_Capture_and_Streams_API

## 용어 : SSL/TLS HTTP는 브라우저 및 웹 서버가 정보를 교환하고 소통하기 위해 사용하는 프로토콜이지. 해당 데이터 교환이 SSL / TLS로 암호화되면 HTTPS라고해. 'S'는 '보안'을 나타내.

ssl 이 먼저 생기고 그다음에 tls가 생겼는데 사실상 ssl의 버전 3이었음. 혼란을 가중시키자 ssl은 2015년 공식 사용종료. 즉 ssl/tls 둘 다 HTTP 데이터 통신 암호화
HTTPS는 HTTP의 보안 (Secured) 버전임
HTTPS는 HTTP 프로토콜일 뿐이지만, SSL / TLS를 사용한 데이터 암호화 기능이 있어. (HTTP with SSL/TLS)
SSL은 90년대 중반 넷스케이프에 의해서 생성된 오리지날의 하지만 폐기된 프로토콜이야.
TLS는 IETF에서 유지, 관리하는 웹의 보안 암호화를위한 새로운 프로토콜이야.

출처 : 만화로 보는 http 작동방식 : https://howhttps.works/ko/
(이거 좋음)


서버측에서 보내는 SDP ?

세션 기술 프로토콜, -記述-, Session Description Protocol, SDP

멀티미디어 세션 및 관련 스케줄 정보를 기술하기 위한 아스키 문장 기반의 프로토콜. 세션에 가담할 수 있도록 멀티미디어 세션의 매체 스트림에 관한 정보를 전달하는 것이며, 멀티미디어 세션은 지속 시간 동안 일단의 매체 스트림으로 정의되고, 세션이 진행되는 시간은 연속적일 필요는 없다. 인터넷상 멀티캐스트 기반의 세션은 기본적으로 세션의 존재와 시간을 알리는 수단세션의 가담 정보를 전달하는 수단의 2가지 목적이 있고, 유니캐스트 환경에서는 후자가 목적이다. 
SDP 정보 내용은 세션의 이름과 목적, 세션 진행 시간, 세션 구성 매체, 매체 수신 정보 등이 포함된다.


WebRTC 시그널링 서버

https://doublem.org/webrtc-story-02/
(위 링크에는 아래 내용들 + 서버구현 코드들이 있어서 매서드를 이해하기 좋다.)

기본 흐름 요약

1) SDP 교환 : Offer, Answer


위 그림에서 1번 ~ 4번은 offer-Answer에 관한 내용임.
(미디어는 5번으로 P2P로 주고받나 봄)
(지구본이 있는 주황색 노트북이 시그널링 서버인듯 함.)
WebRTC가 아닌 SDP를 생성하여 서로 주고 받으며 '시그널링'을 수행함.
SDP는 Session Description Protocol로 RFC 4566에 규정된 스트리밍 미디어의 초기화 인수를 기술하고 협상하기 위한 것임.
SDP 생성 및 교환 상세 과정은 위 링크 게시물 1번에 1~10번 참고

2) ICE 협상 (ICE Negotiation)

SDP를 서로 교환한 후, 각 Peer Alice와 Bob 은 서로의 주소 값을 알기 위해 ICE Candidate(ICE 후보)를 교환한다. 이때 사용되는 기술이 NAT Traversal 이다.

ICE(Interactive Connectivity Establishment)는 P2P 네트워킹에서 두 컴퓨터가 가능한 한 직접 서로 통신하는 방법을 찾기 위해 컴퓨터 네트워킹에 사용되는 기술

각 ICE 메세지들은 두 개의 컴퓨터를 서로 연결하기 위한 정보들에 덧붙여 프로토콜(TCP or UDP), IP 주소, 포트 넘버, 커넥션 타입 등을 제안한다.

요약

정리하면,
WebRTC에서 시그널링서버는 이런일을 한다고 생각하면 쉽다.

  • 각 Peer간 SDP 메시지 Offer, Answer 를 전달해주고, ICE 후보를 주고 받을 수 있도록 돕는 서버
  • Peer 관리를 해주는 포워딩 서버

profile
보초딩코라 틀린 내용 있을 수도 있습니다. 댓글 지적 환영
post-custom-banner

0개의 댓글