WebRTC : 개발자를 위한 기본 개요 정리

 

인터넷을 통한 오디오 및 비디오 통신은 새로운 것이 아닙니다. Skype는 2003년에 이를 가능하게 하는 최초의 도구 중 하나였으며 이러한 화상 채팅을 브라우저에서 직접 사용할 수 있게 되는 데 오랜 시간이 걸리지 않았습니다. WebRTC는 브라우저에서 쉽고 안전한 영상 통신을 가능하게 하는 비교적 새로운 기술입니다. 그렇다면 정확히 무엇이며 어떻게 작동하며 왜 비디오 커뮤니케이션에 혁명을 일으키고 있습니까?

WebRTC는 프로토콜, 표준 및 JavaScript API의 모음입니다. 비디오 통신을 위한 대부분의 솔루션은 독점 소프트웨어 또는 기껏해야 브라우저 플러그인에 의존하지만 WebRTC는 이러한 종류의 통신을 가능하게 합니다…

WebRTC는 새롭다고 말했지만 실제로는 거의 10년이 되었습니다. 2011년에 처음 출시되었지만 큰 웹 표준이 항상 그렇듯이 모든 주요 브라우저에서 구현되기까지 시간이 걸렸습니다. Safari는 2017년에야 지원을 시작했으며 Firefox와 Chrome이 더 오랫동안 지원했지만 구현의 차이로 인해 브라우저에서 일부 기능을 사용할 수 없었습니다. 그러나 이제는 브라우저 전체에서, 최소한 기본 브라우저와 모바일에서도 안정적으로 작동합니다.

오디오 및 비디오 엔진

이러한 프로젝트의 첫 번째 과제는 비디오 및 오디오 스트림을 처리하는 것이었습니다. 2010년 글로벌 IP 솔루션이라는 회사가 구글에 인수될 당시 작업 중이었습니다. 브라우저 간에 화상 회의가 가능하려면 브라우저가 먼저 사용자의 하드웨어에 액세스해야 합니다. 하드웨어에서 비디오 및 오디오 스트림을 수신하면 브라우저는 인코딩하고 개선하고(예: 노이즈 제거) 품질을 처리하고 비트 전송률과 대역폭을 변경하여 네트워크를 통해 전송해야 합니다.

스트림을 수신할 때 브라우저는 네트워크 상태가 나쁠 수 있고 패킷이 지연되거나 손실될 수 있는 경우에도 이를 디코딩하고 허용 가능한 품질로 사용자에게 렌더링해야 합니다. 프로토콜과 표준이 작동하도록 개발되었으며 이제 브라우저가 이 모든 작업을 처리합니다. WebRTC를 통해 도구를 구현할 때 개발자는 JavaScript API인 MediaStream을 사용할 수 있으며 이 API 에서 이미 개선되고 인코딩된 스트림을 얻을 수 있습니다.

브라우저 간 연결 설정

시그널링

다음 과제는 실제로 브라우저 간의 연결을 활성화하는 것이었습니다. 연결을 설정하려면 클라이언트 간에 세 가지 유형의 정보를 교환해야 합니다.

• 미디어 데이터: 공유하려는 미디어 유형(오디오 전용 또는 비디오), 제약 조건(예: 품질).
• 세션 제어 데이터: 통신을 열고 닫습니다.
• 네트워크 데이터: 사용자는 서로의 IP 주소와 포트를 가져와 P2P 연결을 설정할 수 있는지 확인해야 합니다.

이 교환을 시그널링 프로세스라고 합니다. 이러한 데이터는 P2P 연결을 열기 위해 교환되어야 하지만 교환 방법은 전적으로 개발자에게 달려 있습니다. 그녀는 이미 설정한 모든 통신 수단을 사용할 수 있지만 일반적인 솔루션은 웹 소켓을 사용하는 것입니다.

구체적으로 Bob과 Alice 간에 WebRTC 연결을 설정하려고 한다고 가정해 보겠습니다. Bob과 Alice는 둘 다 귀하의 웹사이트에 로그인되어 있고 버튼을 클릭하여 화상 채팅을 시작합니다. 둘 다 먼저 웹 소켓 서버에 대한 연결을 설정해야 합니다. 그런 다음 Bob은 MediaStream API에서 오디오 및 비디오 스트림을 요청하고 WebRTC 제안을 생성하여 신호 매체(이 예에서는 websocket 서버)를 통해 Alice에게 보냅니다. 이러한 제안은 미디어 데이터에 대한 정보를 포함하는 문자열입니다. Alice는 이 제안을 받고 오디오 및 비디오 스트림을 요청하고 답변을 생성하여 Bob에게 보냅니다.

Alice와 Bob은 이제 미디어 데이터를 교환했으며 화상 채팅을 시작하고 싶다고 서로 알렸습니다. 그러나 여기에 다음 과제가 있습니다. 우리는 웹 소켓 서버를 통한 연결이 아닌 직접적인 P2P 연결을 원합니다. 그러한 연결을 어떻게 설정합니까?

빙

인터넷은 네트워크를 통해 서로 통신하는 컴퓨터로 구성됩니다. 두 대의 컴퓨터를 함께 연결하는 것은 큰 문제처럼 들리지 않습니다. 문제는 일반적으로 클라이언트를 서버에 연결한다는 것입니다. 서버에는 잘 알려진 IP 주소가 있고 클라이언트(웹사이트를 요청하는 컴퓨터)는 요청을 보낼 위치를 정확히 알고 있습니다. 그러나 두 클라이언트를 연결할 때 먼저 서로의 IP 주소를 찾아야 하며 생각보다 복잡합니다.

역사적으로 IP 주소가 부족했기 때문에(IPv4에서는 약 40억 개의 주소만 사용할 수 있음) 사용자는 하나의 공용 주소로 그룹화되고 라우터를 통과하는 패킷의 주소를 변환합니다. 이 프로세스를 NAT(네트워크 주소 변환)라고 합니다. NAT에는 여러 유형이 있지만 그 중 일부는 공용 IP 주소와 UDP 흐름을 위한 포트(필요한 것)를 할당합니다. WebRTC는 ICE(대화형 연결 설정) 프레임워크를 사용하여 사용자의 공용 IP 주소를 검색하고 피어와 통신합니다.

ICE는 STUN(Session Traversal Utilities for NAT) 서버를 사용하여 그렇게 합니다. 이러한 서버는 아무 것도 하지 않으며 단순히 요청을 보냅니다. NAT 뒤에 있으면 요청이 통과하고 NAT는 자체 공용 주소와 포트를 설정합니다. STUN 서버는 해당 요청을 수신하고 이를 사용자에게 반환합니다. 이제 NAT 공용 주소와 포트가 있습니다. 최상의 시나리오에서는 충분합니다. 당신은 이 주소를 당신의 피어에게 전달하고, 그는 당신에게 자신의 주소를 보내고 당신은 피어 투 피어 연결을 설정합니다.

그러나 모든 NAT에서 P2P 연결을 설정할 수 있는 것은 아닙니다. 일부는 공용 IP 주소와 포트를 각 외부 소스에 할당합니다. 즉, TURN 서버의 메시지에 할당된 공용 주소와 포트는 연결하려는 피어에서 작동하지 않습니다. 이와 같은 경우 다른 솔루션이 필요합니다. 통신은 TURN 서버를 거쳐야 합니다. TURN은 Traversal Using Relays around NAT의 약자입니다. 이름에서 알 수 있듯이 연결은 릴레이 서버를 통해 이루어지며 기술적으로 더 이상 P2P 연결이 아닙니다.

좋은 소식은 스스로 돌볼 필요가 없다는 것입니다. ICE 에이전트는 이러한 탐색 및 의사 결정을 처리하고 직접 연결 가능성을 확인하고 수행할 수 없는 경우 TURN 서버를 통해 연결을 설정합니다. ICE 에이전트가 후보를 제시하면 신호 매체를 통해 이러한 후보를 보내기만 하면 됩니다. 최적의 후보가 선택되면 WebRTC 연결이 설정되고 사용자는 화상 통화를 시작할 수 있습니다.

 

이것이 WebRTC의 기본을 이해하기 위해 알아야 할 전부입니다. NAT, ICE, STUN 및 TURN에 대해 더 알고 싶다면 이 기사를 확인 하세요 . WebRTC를 사용하는 애플리케이션에서 이것이 어떻게 처리되는지 JavaScript 코드 예제와 함께 더 자세히 설명하고 보여줍니다.

WebRTC를 사용하여 자신만의 화상 채팅을 만들려면 다음 기사 시리즈를 따르세요.

• 1단계: 웹캠 및 마이크에서 데이터 스트림
• 2단계: WebSocket을 통한 연결 설정
• 3단계: WebRTC 연결 설정
• 4단계: 연락처 찾기
• 5단계: 화면 공유
• 6단계: 데이터 채널을 통해 파일 보내기

각 단계는 매우 상세합니다. 몇 줄의 코드로 WebRTC 연결(1, 2, 3단계)을 설정하는 방법을 보여주는 보다 간결한 자습서를 작성 중입니다. 기사가 곧 나올 것입니다. WebRTC를 통해 자신의 영상 채팅을 구현하는 방법을 빠르게 살펴보고 싶다면 기다릴 수 있습니다.