WebRTC 기반의 P2P 영상 채팅입니다. WebRTC Webrtc 설치 기반 P2P 영상채팅

유럽의 인터넷 사용자는 두 부분으로 나뉩니다. Allenbach(독일)에 있는 여론 분석 연구소의 조사에 따르면 Skype, 채팅 및 인스턴트 메시징 시스템은 인터넷 사용자의 필수적인 부분이 되었습니다. 일상 생활 1,650만 명의 성인과 어린이 중 900만 명이 이러한 서비스를 가끔 사용하며, 2,800만 명은 이러한 서비스를 건드리지 않습니다.

Firefox가 이제 통합됨에 따라 변경될 수 있습니다. 실시간 통신 기술 (WebRTC), 고객 자신도 마찬가지입니다. 오디오 및 비디오 채팅을 시작하는 것은 이제 웹사이트를 여는 것보다 더 어렵지 않습니다. 반면 Facebook 및 Skype와 같은 서비스는 별도의 클라이언트를 사용하고 계정을 생성하는 솔루션에 의존합니다.

WebRTC는 사용 편의성뿐만 아니라 차별화됩니다. 이 방법을 사용하면 설치할 수도 있습니다 두 브라우저 간의 직접 연결. 이렇게 하면 오디오 및 비디오 데이터는 과부하가 있을 수 있거나 관리자가 개인 정보 보호 또는 데이터 보호에 특별히 민감하지 않은 서버를 통과하지 않습니다. 직접 연결 덕분에 WebRTC는 등록이나 등록이 필요하지 않습니다. 계정어떤 서비스에서든.

대화를 시작하려면 링크를 따라가기만 하면 됩니다. 통신은 비공개로 유지됩니다, 데이터 스트림이 암호화되어 있기 때문입니다. Google은 2011년 WebRTC 구현의 소스 코드를 공개하면서 브라우저를 통한 실시간 통신에 적극적으로 참여하기 시작했습니다.

그 직후 Chrome과 Firefox는 자체 WebRTC 엔진을 받았습니다. 현재 모바일 버전에는 이 기술과 애플리케이션에서 사용되는 Android 5.0이 설치된 WebView 3.6 엔진이 모두 탑재되어 있습니다.

실시간 통신을 위해서는 웹뷰어에 적절한 JavaScript 인터페이스가 구현되어야 합니다. GetUserMedia 사용 소프트웨어오디오 및 비디오 소스, 즉 웹캠과 마이크에서 캡처를 활성화합니다. RTCPeerConnection은 통신 자체는 물론 연결 설정도 담당합니다.

브라우저 통합과 병행하여 컨소시엄 워킹 그룹은 월드 와이드 웹(W3C)는 WebRTC 표준화 프로세스를 가속화했습니다. 2015년에는 완료되어야 합니다.

WebRTC는 거의 만족하지 않습니다.

WebRTC 서비스를 사용하는 데는 서버가 대화 상대만 연결하므로 많은 리소스가 필요하지 않습니다. 연결을 설정하는 것도 특별히 어렵지 않습니다. 먼저, 브라우저는 WebRTC 서버에 호출을 시작할 계획이라는 신호를 보냅니다. 서버로부터 HTTPS 링크를 수신합니다. 통신은 암호화됩니다. 사용자는 이 링크를 대화 상대에게 보냅니다. 그런 다음 브라우저는 사용자에게 웹캠과 마이크에 대한 액세스 권한을 요청합니다.

대담자와 직접 스트리밍 연결을 설정하기 위해 브라우저는 WebRTC 서비스로부터 IP 주소와 구성 데이터를 받습니다. 상대방의 웹뷰어도 마찬가지다.

스트리밍 연결이 원활하고 좋은 품질로 작동하기 위해 브라우저에서는 세 가지 엔진이 작동합니다. 그 중 두 개는 오디오 및 비디오 데이터를 최적화하고 압축하며, 세 번째는 전송을 담당합니다. 다음을 통해 데이터를 보냅니다. SRTP 프로토콜(Secure Real-time Transport Protocol), 암호화된 실시간 스트리밍을 허용합니다.

직접 연결을 설정할 수 없는 경우 WebRTC는 다른 경로를 찾습니다. 예를 들어, 이런 경우가 발생합니다. 네트워크 설정 STUN 서버가 IP 주소를 보고하는 것을 방지합니다. WebRTC 표준은 이 경우 대화가 발생하지만 TURN 서버(NAT 주변의 릴레이를 사용하여 탐색)가 중간에 활성화되도록 규정합니다. 따라서 netscan.co 웹사이트에서 WebRTC가 귀하의 컴퓨터에 구현되어 있는지와 네트워크에 대한 액세스 권한이 있는지 확인할 수 있습니다.

연결 방법

먼저 대화(1)를 등록해야 합니다. WebRTC 서비스는 대담자에게 전송되어야 하는 링크를 제공합니다. 브라우저는 STUN 서버를 이용하여 자신의 IP 주소를 알아내고(2), 이를 서비스에 전송하고, 파트너의 IP를 받아 직접 연결을 설정합니다(3). STUN이 실패하면 TURN 서버(4)를 사용하여 대화가 리디렉션됩니다.

브라우저에서 WebRTC 기술을 사용한 통신은 JavaScript 코드를 사용하여 시작됩니다. 그 후 세 가지 엔진이 통신을 담당합니다. 음성 및 비디오 엔진은 웹캠과 마이크에서 멀티미디어 데이터를 수집하고 전송 엔진은 정보를 결합하여 SRTP(Secure Real-time Protocol)를 사용하여 암호화된 형식으로 스트림을 보냅니다.

WebRTC와 작동하는 브라우저

Chrome과 Firefox에는 talky.io와 같은 서비스를 사용하는 WebRTC 엔진이 있습니다. Mozilla의 브라우저는 자체 클라이언트와 직접 작동할 수 있습니다.

Google과 Mozilla는 실시간 통신에 대한 아이디어를 계속해서 개발하고 있습니다. Chrome은 여러 참가자가 참여하는 WebRTC 회의를 주최할 수 있으며, Firefox의 새로운 Hello 클라이언트는 거대 통신업체인 Telefonica의 자회사와 협력하여 개발되었습니다. Apple은 현재로서는 방관하고 있으므로 아직 Safari에서 WebRTC를 기대해서는 안 됩니다. 그러나 많은 대체 응용 프로그램 iOS용 및 Safari용 플러그인.

Microsoft는 약간 다른 과정을 밟고 있습니다. 경쟁업체의 소유자로서 스카이프 서비스이 회사는 WebRTC에 그렇게 쉽게 항복하지 않을 것입니다. 대신 Microsoft는 ORTC(Object Real-Time Communications)라는 기술을 개발하고 있습니다. 인터넷 익스플로러.

서버와의 연결을 설정하기 위한 다양한 코덱 및 프로토콜과 같은 WebRTC와의 차이점은 미미하며 시간이 지남에 따라 이러한 차이점을 포함하는 WebRTC 표준에 추가될 가능성이 높습니다. 따라서 늘 그렇듯 Apple만이 뒤처지게 됩니다.

사진:제조 회사; goodluz/Fotolia.com

에 관한 대부분의 자료는 WebRTC코딩의 응용 수준에 초점을 맞추며 기술 이해에 기여하지 않습니다. 더 깊이 들어가서 연결이 어떻게 발생하는지, 세션 설명자와 후보가 무엇인지, 무엇을 위해 필요한지 알아 보겠습니다. 충격그리고 회전하다섬기는 사람.

WebRTC

소개

WebRTC는 비디오 데이터 전송을 위해 두 클라이언트를 연결할 수 있는 브라우저 중심 기술입니다. 주요 기능: 내부 브라우저 지원(예: 타사 구현 기술이 필요하지 않음) 어도비 플래시 ) 및 추가 서버를 사용하지 않고 클라이언트를 연결하는 기능 - 연결 피어 투 피어(더 나아가, p2p).

연결 설정 p2p- 컴퓨터가 항상 공개된 것은 아니기 때문에 다소 어려운 작업입니다. IP주소, 즉 인터넷 주소입니다. 수량이 적기 때문에 IPv4주소(및 보안 목적) 메커니즘이 개발되었습니다. NAT를 사용하면 예를 들어 가정용으로 개인 네트워크를 만들 수 있습니다. 이제 많은 홈 라우터가 지원합니다. NAT덕분에 모든 가정용 장치는 인터넷에 액세스할 수 있습니다. 하지만 인터넷 제공업체는 일반적으로 인터넷을 제공합니다. IP주소. 공공의 IP주소는 인터넷에서 고유하지만 개인 주소는 그렇지 않습니다. 따라서 연결 p2p- 어려운.

이를 더 잘 이해하려면 세 가지 상황을 고려하십시오. 두 노드가 모두 동일한 네트워크에 있습니다. (사진 1), 두 노드가 서로 다른 네트워크에 있습니다(하나는 비공개, 다른 하나는 공개). (그림 2)두 노드는 모두 동일한 개인 네트워크에 있습니다. IP구애 (그림 3).

그림 1: 동일한 네트워크에 있는 두 노드

그림 2: 서로 다른 네트워크의 노드(하나는 프라이빗, 하나는 퍼블릭)

그림 3: 서로 다른 사설 네트워크에 있지만 숫자상으로는 주소가 동일한 노드

위 그림에서 두 문자 표기법의 첫 번째 문자는 노드 유형을 나타냅니다(p = 또래, r = 라우터). 첫 번째 그림에서는 상황이 유리합니다. 네트워크의 노드는 네트워크로 완전히 식별됩니다. IP주소가 있으므로 서로 직접 연결할 수 있습니다. 두 번째 그림에는 비슷한 노드 번호를 가진 두 개의 서로 다른 네트워크가 있습니다. 여기에는 두 개의 라우터(라우터)가 나타나는 곳이 있습니다. 네트워크 인터페이스– 네트워크 내부 및 네트워크 외부. 그렇기 때문에 그들은 두 개를 가지고 있습니다. IP구애. 일반 노드에는 네트워크 내에서만 통신할 수 있는 인터페이스가 하나만 있습니다. 네트워크 외부의 누군가에게 데이터를 전송하는 경우 다음을 사용하여 NAT라우터(라우터) 내부에 있으므로 아래의 다른 사람에게 표시됩니다. IP라우터 주소는 그들의 것입니다 외부 IP주소. 따라서 노드에서는 p1있다 내부 IP = 192.168.0.200 그리고 외부 IP = 10.50.200.5 , 마지막 주소는 네트워크의 다른 모든 노드 외부에도 있습니다. 노드의 비슷한 상황 p2. 따라서 내부(자체)만 사용하면 연결이 불가능합니다. IP구애. 외부 주소, 즉 라우터 주소를 사용할 수 있지만, 동일한 사설망의 모든 노드는 동일한 외부 주소를 가지기 때문에 이는 상당히 어렵습니다. 이 문제는 메커니즘을 사용하여 해결됩니다. NAT

내부 주소를 통해 노드를 연결하기로 결정하면 어떻게 되나요? 데이터는 네트워크를 떠나지 않습니다. 효과를 높이기 위해 마지막 그림에 표시된 상황을 상상할 수 있습니다. 두 노드 모두 동일한 내부 주소를 갖습니다. 이를 사용하여 통신하면 각 노드는 자체적으로 통신합니다.

WebRTC프로토콜을 사용하여 이러한 문제에 성공적으로 대처합니다. 얼음그러나 추가 서버를 사용해야 합니다( 충격, 회전하다). 이에 대한 자세한 내용은 아래에서 확인하세요.

WebRTC의 두 단계

프로토콜을 통해 두 노드를 연결하려면 WebRTC(또는 단순히 RTC, 두 사람이 통신하는 경우 아이폰'a) 연결을 설정하려면 몇 가지 예비 단계를 수행해야 합니다. 이것이 연결 설정의 첫 번째 단계입니다. 두 번째 단계는 비디오 데이터 전송입니다.

기술이 있지만 즉시 말할 가치가 있습니다. WebRTC그의 작품에는 많은 것을 사용한다 다양한 방법으로통신( TCP그리고 UDP) 그리고 그들 사이의 유연한 전환이 가능하며, 이 기술은 연결 데이터를 전송하기 위한 프로토콜이 없습니다.. 두 개의 노드를 연결하기 때문에 놀라운 일은 아닙니다. p2p그렇게 쉽지는 않습니다. 그러므로 어느 정도는 필요하다. 추가의전혀 관련이 없는 데이터 전송 방법 WebRTC. 소켓 전송, 프로토콜일 수 있습니다. HTTP, 프로토콜일 수도 있습니다. SMTP또는 러시아 포스트. 이 전송 메커니즘 초기의데이터가 호출됩니다 신호. 많은 정보를 전달할 필요가 없습니다. 모든 데이터는 텍스트 형태로 전송되며 두 가지 유형으로 구분됩니다. SDP그리고 아이스 후보. 첫 번째 유형은 논리적 연결을 설정하는 데 사용되고 두 번째 유형은 물리적 연결을 설정하는 데 사용됩니다. 이 모든 내용은 나중에 자세히 설명하겠지만 지금은 다음 사항을 기억하는 것이 중요합니다. WebRTC다른 노드로 전송해야 할 몇 가지 정보를 제공합니다. 필요한 모든 정보를 전송하자마자 노드가 연결될 수 있으며 더 이상 도움이 필요하지 않습니다. 따라서 우리가 구현해야 하는 신호 메커니즘은 다음과 같습니다. 갈라져, 사용하게 될 것이다 연결된 경우에만, 단, 영상 데이터 전송 시에는 사용되지 않습니다.

이제 첫 번째 단계인 연결 설정 단계를 살펴보겠습니다. 여러 점으로 구성되어 있습니다. 먼저 연결을 시작하는 노드에 대해 이 단계를 살펴본 다음 대기 중인 노드에 대해 살펴보겠습니다.

• 개시자(발신자 - 방문객):
  1. 비디오 데이터 전송 시작 ​​제안(createOffer)
  2. 당신의 것을 얻기 SDP SDP)
  3. 당신의 것을 얻기 아이스 후보 아이스 후보)
• 통화 대기( 수신자):
  1. 로컬(사용자) 미디어 스트림을 수신하고 전송을 위해 설정(getUserMediaStream)
  2. 영상 데이터 전송 시작 ​​제안을 받고 답변 작성(createAnswer)
  3. 당신의 것을 얻기 SDP개체를 전송하고 신호 메커니즘을 통해 이를 전송합니다( SDP)
  4. 당신의 것을 얻기 아이스 후보신호 메커니즘을 통한 객체 및 전송 ( 아이스 후보)
  5. 원격(외부) 미디어 스트림을 수신하여 화면에 표시(onAddStream)

유일한 차이점은 두 번째 점에 있습니다.

단계가 복잡해 보이지만 실제로는 자신의 미디어 스트림 전송(항목 1), 연결 매개변수 설정(항목 2-4), 다른 사람의 미디어 스트림 수신(항목 5)이라는 세 가지 단계가 있습니다. 가장 어려운 단계는 두 번째 단계입니다. 두 부분으로 구성되어 있기 때문입니다. 물리적그리고 논리적사이. 첫 번째는 나타냅니다. 길, 한 네트워크 노드에서 다른 네트워크 노드로 이동하려면 패킷이 이동해야 합니다. 두 번째는 나타냅니다 비디오/오디오 매개변수– 사용할 품질, 사용할 코덱.

정신단계 제안 생성또는 생성답변전송 단계에 연결되어야 함 SDP그리고 아이스 후보사물.

기본 엔터티

미디어 스트림(MediaStream)

주요 개체는 미디어 스트림, 즉 비디오 및 오디오 데이터, 사진 및 사운드의 스트림입니다. 미디어 스트림에는 로컬과 원격의 두 가지 유형이 있습니다. 로컬은 입력 장치(카메라, 마이크)로부터 데이터를 수신하고, 원격은 네트워크를 통해 데이터를 수신합니다. 따라서 각 노드에는 로컬 스레드와 원격 스레드가 모두 있습니다. 안에 WebRTC스레드에 대한 인터페이스가 있습니다 미디어스트림하위 인터페이스도 있습니다 로컬미디어스트림특히 로컬 스레드에 적합합니다. 안에 자바스크립트첫 번째 항목만 만날 수 있으며, 다음을 사용하면 libjingle, 그러면 두 번째 것을 만날 수 있습니다.

안에 WebRTC스레드 내에 다소 혼란스러운 계층 구조가 있습니다. 각 스트림은 여러 미디어 트랙으로 구성될 수 있습니다( 미디어트랙), 이는 여러 미디어 채널로 구성될 수 있습니다( 미디어채널). 그리고 자체적으로 여러 미디어 스트림이 있을 수도 있습니다.

모든 것을 순서대로 살펴 보겠습니다. 이를 위해 몇 가지 예를 염두에 두겠습니다. 우리가 우리 자신의 비디오뿐만 아니라 우리가 무언가를 쓸 종이가 놓여 있는 테이블의 비디오도 전송하고 싶다고 가정해 봅시다. 두 개의 비디오(us + table)와 하나의 오디오(us)가 필요합니다. 이 데이터는 아마도 서로 약하게 종속되어 있기 때문에 우리와 테이블을 서로 다른 스레드로 나누어야 한다는 것은 분명합니다. 그러므로 우리는 두 가지를 갖게 될 것입니다 미디어스트림'a – 하나는 우리용이고 하나는 테이블용입니다. 첫 번째 데이터에는 비디오와 오디오 데이터가 모두 포함되고 두 번째 데이터에는 비디오만 포함됩니다(그림 4).

그림 4: 두 가지 다른 미디어 스트림. 하나는 우리용, 하나는 우리 테이블용

미디어 스트림에는 최소한 데이터를 포함하는 기능이 포함되어야 한다는 점은 즉시 명백해집니다. 다른 유형- 비디오 및 오디오. 이는 기술에서 고려되므로 각 유형의 데이터는 미디어 트랙을 통해 구현됩니다. 미디어트랙. 미디어 트랙에는 특별한 속성이 있습니다. 친절한, 이는 우리 앞에 있는 비디오 또는 오디오를 결정합니다(그림 5).

그림 5: 미디어 스트림은 미디어 트랙으로 구성됩니다.

프로그램에서 모든 일이 어떻게 진행되나요? 두 개의 미디어 스트림을 생성하겠습니다. 그런 다음 두 개의 비디오 트랙과 하나의 오디오 트랙을 만듭니다. 카메라와 마이크에 접근해 봅시다. 각 트랙에 어떤 장치를 사용할지 알려드리겠습니다. 첫 번째 미디어 스트림에 비디오 및 오디오 트랙을 추가하고 두 번째 미디어 스트림에는 다른 카메라의 비디오 트랙을 추가해 보겠습니다.

하지만 연결의 반대쪽 끝에서 미디어 스트림을 어떻게 구별합니까? 이를 위해 각 미디어 스트림에는 다음 속성이 있습니다. 상표– 스트림 레이블, 이름(그림 6). 미디어 트랙은 동일한 속성을 갖습니다. 언뜻 보기에는 비디오가 다른 방식으로 사운드와 구별될 수 있는 것처럼 보입니다.

그림 6: 미디어 스트림과 트랙은 레이블로 식별됩니다.

그렇다면 태그를 통해 미디어 트랙을 식별할 수 있다면 왜 우리의 예에서는 하나가 아닌 두 개의 미디어 스트림을 사용해야 할까요? 결국 하나의 미디어 스트림을 전송할 수 있지만 그 안에 다른 트랙을 사용할 수 있습니다. 우리는 미디어 스트림의 중요한 속성에 도달했습니다. 동기화미디어 트랙. 서로 다른 미디어 스트림은 서로 동기화되지 않지만 각 미디어 스트림 내에서는 모든 트랙이 동기화됩니다. 동시에 재생됩니다.

따라서 우리의 말, 얼굴 감정, 종이 조각이 동시에 재생되기를 원한다면 하나의 미디어 스트림을 사용하는 것이 좋습니다. 이것이 그다지 중요하지 않다면 다른 스트림을 사용하는 것이 더 수익성이 높습니다. 그림이 더 부드러워집니다.

전송 중에 일부 트랙을 꺼야 하는 경우 속성을 사용할 수 있습니다. 활성화됨미디어 트랙.

마지막으로 스테레오 사운드에 대해 생각해 볼 가치가 있습니다. 아시다시피 스테레오 사운드는 두 가지 다른 소리입니다. 그리고 별도로 전송해야 합니다. 이를 위해 채널이 사용됩니다. 미디어채널. 미디어 오디오 트랙에는 많은 채널이 있을 수 있습니다(예: 5+1 오디오가 필요한 경우 6개). 물론 미디어 트랙 내부에도 채널이 있습니다. 동기화됨. 비디오의 경우 일반적으로 하나의 채널만 사용되지만 광고 오버레이 등을 위해 여러 채널을 사용할 수도 있습니다.

요약: 우리는 미디어 스트림을 사용하여 비디오 및 오디오 데이터를 전송합니다. 각 미디어 스트림 내에서 데이터가 동기화됩니다. 동기화가 필요하지 않으면 여러 미디어 스트림을 사용할 수 있습니다. 각 미디어 스트림에는 비디오용과 오디오용이라는 두 가지 유형의 미디어 트랙이 있습니다. 일반적으로 트랙은 2개 이하이지만, (대담자와 테이블의) 여러 비디오를 전송해야 하는 경우 트랙이 더 많을 수 있습니다. 각 트랙은 일반적으로 스테레오 사운드에만 사용되는 여러 채널로 구성될 수 있습니다.

가장 간단한 화상 채팅 상황에서는 하나의 로컬 미디어 스트림이 있습니다. 이 스트림은 두 개의 트랙(비디오 트랙과 오디오 트랙)으로 구성되며 각 트랙은 하나의 메인 채널로 구성됩니다. 비디오 트랙은 카메라를 담당하고, 오디오 트랙은 마이크를 담당하며, 미디어 스트림은 두 가지 모두에 대한 컨테이너입니다.

세션 설명자(SDP)

컴퓨터마다 항상 다른 카메라, 마이크, 비디오 카드 및 기타 장비가 있습니다. 그들에게는 많은 옵션이 있습니다. 이 모든 것은 두 네트워크 노드 간의 데이터 미디어 전송을 위해 조정되어야 합니다. WebRTC자동으로 수행하고 생성합니다. 특별한 물건– 세션 설명자 SDP. 이 객체를 다른 노드에 전달하면 미디어 데이터가 전송될 수 있습니다. 아직 다른 노드와 연결이 없습니다.

이를 위해 모든 신호 메커니즘이 사용됩니다. SDP소켓을 통해 전송하거나 사람(전화로 다른 노드에 알리기) 또는 Russian Post를 통해 전송할 수 있습니다. 매우 간단합니다. 기성품을 제공합니다. SDP그리고 그것을 보내야 합니다. 그리고 상대방이 수령하면 부서로 전송합니다. WebRTC. 세션 설명자는 텍스트로 저장되며 애플리케이션에서 변경할 수 있지만 일반적으로 그럴 필요는 없습니다. 예를 들어 데스크톱 ← 휴대폰 연결 시 원하는 오디오 코덱을 강제로 선택해야 하는 경우가 있습니다.

일반적으로 연결을 설정할 때 일종의 주소를 지정해야 합니다. 예를 들어 URL. 신호 메커니즘을 통해 사용자 자신이 데이터를 대상으로 보내기 때문에 여기서는 이것이 필요하지 않습니다. 나타내기 위해 WebRTC우리가 설치하고 싶은 것 p2p연결하려면 createOffer 함수를 호출해야 합니다. 이 함수를 호출하고 특수 함수를 지정한 후 콜백'가 생성될 것이다 SDP개체와 동일한 개체로 전송됨 콜백. 귀하에게 필요한 것은 이 개체를 네트워크를 통해 다른 노드(대담자)로 전송하는 것뿐입니다. 그 후 데이터는 신호 메커니즘을 통해 다른 쪽 끝에 도착합니다. SDP객체. 이 세션 설명자는 이 노드에 외부이므로 유용한 정보를 전달합니다. 이 객체를 수신하는 것은 연결을 시작하라는 신호입니다. 따라서 이에 동의하고 createAnswer 함수를 호출해야 합니다. createOffer와 완전히 유사합니다. 당신의 것으로 돌아가기 콜백로컬 세션 설명자를 전달하며 신호 메커니즘을 통해 다시 전달되어야 합니다.

다른 사람의 메시지를 받은 후에만 createAnswer 함수를 호출할 수 있다는 점은 주목할 가치가 있습니다. SDP물체. 왜? 왜냐하면 지역적으로 SDP createAnswer가 호출될 때 생성될 객체는 원격지에 의존해야 합니다. SDP객체. 이 경우에만 비디오 설정을 대화 상대의 설정과 조정할 수 있습니다. 또한 로컬 미디어 스트림을 수신하기 전에 createAnswer 및 createOffer를 호출하면 안 됩니다. 쓸 내용이 없습니다. SDP객체 .

이후 WebRTC편집이 가능하다 SDP개체가 있는 경우 로컬 핸들을 받은 후 설치해야 합니다. 전달하기에는 조금 이상해 보일 수도 있지만 WebRTC그녀가 우리에게 준 것, 그게 프로토콜이에요. 원격 핸들을 받으면 핸들도 설치해야 합니다. 따라서 하나의 노드에 두 개의 설명자, 즉 자신과 다른 사람의 설명자(즉, 로컬 및 원격)를 설치해야 합니다.

금후 악수노드는 서로의 소망을 알고 있습니다. 예를 들어 노드가 1 코덱을 지원합니다 ㅏ그리고 비, 그리고 노드 2 코덱을 지원합니다 비그리고 씨, 그러면 각 노드는 자신과 다른 노드의 설명자를 알고 있으므로 두 노드 모두 코덱을 선택합니다. 비(그림 7). 이제 연결 로직이 설정되어 미디어 스트림을 전송할 수 있지만 또 다른 문제가 있습니다. 노드는 여전히 신호 메커니즘에 의해서만 연결됩니다.

그림 7: 코덱 협상

아이스 후보

기술 WebRTC그의 새로운 방법론으로 우리를 혼란스럽게 만들려고 합니다. 연결을 설정할 때 연결하려는 노드의 주소가 지정되지 않습니다. 먼저 설치됨 논리적연결이 아니라 물리적, 그 반대는 항상 이루어졌지만. 그러나 우리가 제3자 신호 메커니즘을 사용하고 있다는 사실을 잊지 않는다면 이상하게 보이지 않을 것입니다.

따라서 연결은 이미 설정되었지만(논리적 연결) 네트워크 노드가 데이터를 전송할 수 있는 경로는 아직 없습니다. 그렇게 간단하지는 않지만 간단하게 시작해 보겠습니다. 노드가 동일한 개인 네트워크에 있도록 합니다. 우리가 이미 알고 있듯이 내부 연결에 따라 쉽게 서로 연결할 수 있습니다. IP주소(또는 사용되지 않은 경우 다른 주소) TCP/IP).

얼마 후 콜백'그리고 WebRTC우리에게 말해 아이스 후보사물. 또한 텍스트 형식으로도 제공되며 세션 설명자와 마찬가지로 신호 메커니즘을 통해 전송하기만 하면 됩니다. 세션 설명자에 카메라 및 마이크 수준의 설정에 대한 정보가 포함된 경우 후보에는 네트워크에서의 위치에 대한 정보가 포함됩니다. 이를 다른 노드에 전달하면 물리적으로 우리에게 연결할 수 있고 이미 세션 설명자가 있으므로 논리적으로 연결할 수 있고 데이터가 "흐르게" 됩니다. 그가 자신의 후보 객체, 즉 그 자신이 네트워크에서 어디에 있는지에 대한 정보를 우리에게 보내는 것을 기억한다면 우리는 그와 연결할 수 있을 것입니다. 여기서 고전적인 클라이언트-서버 상호 작용과의 차이점을 한 가지 더 살펴보겠습니다. HTTP 서버와의 통신은 요청-응답 방식에 따라 이루어지며 클라이언트는 서버로 데이터를 보내고 서버는 이를 처리한 후 다음을 통해 보냅니다. 요청 패킷에 지정된 주소. 안에 WebRTC알 필요가있다 두 개의 주소그리고 양쪽을 연결해주세요.

세션 설명자와의 차이점은 원격 후보만 설치하면 된다는 것입니다. 여기에서 편집하는 것은 금지되어 있으며 어떠한 이익도 가져올 수 없습니다. 일부 구현에서는 WebRTC후보는 세션 설명자가 설정된 후에만 설치해야 합니다.

세션 설명자는 하나뿐인데 후보는 많을 수 있는 이유는 무엇입니까? 네트워크상의 위치는 내부적으로만 결정될 수 있는 것이 아니기 때문에 IP주소뿐만 아니라 라우터의 외부 주소도 필요하며 반드시 하나만 있는 것은 아닙니다. 회전하다서버. 단락의 나머지 부분에서는 후보자에 대한 자세한 논의와 다양한 사설 네트워크의 노드를 연결하는 방법에 대해 설명합니다.

따라서 두 개의 노드가 동일한 네트워크에 있습니다(그림 8). 어떻게 식별하나요? 사용하여 IP구애. 다른 방법은 없습니다. 사실, 여전히 다른 전송 수단을 사용할 수 있습니다( TCP그리고 UDP) 및 다른 포트. 후보 객체에 포함된 정보입니다 - IP, 포트, 수송그리고 또 다른 것. 예를 들어 UDP운송 및 531 포트.

그림 8: 두 노드가 동일한 네트워크에 있음

그러면 우리가 노드에 있다면 p1, 저것 WebRTC그러한 후보 객체를 우리에게 전달할 것입니다. . 이는 정확한 형식이 아니며 단지 다이어그램일 뿐입니다. 우리가 매듭을 짓고 있다면 p2, 그러면 후보자는 – . 신호 메커니즘을 통해 p1후보를 받게 됩니다 p2(즉, 노드 위치 p2, 즉 그의 IP그리고 포트). 그 다음에 p1와 연결할 수 있다 p2곧장. 더 정확하고, p1해당 주소로 데이터를 보내드립니다 10.50.150.3:531 그들이 도달할 것이라는 희망으로 p2. 주소가 노드에 속하는지 여부는 중요하지 않습니다. p2아니면 어떤 중개인. 유일한 중요한 점은 데이터가 이 주소를 통해 전송되고 도달할 수 있다는 것입니다. p2.

노드가 동일한 네트워크에 있는 한 모든 것이 간단하고 쉽습니다. 각 노드에는 후보 개체가 하나만 있습니다(항상 자신의 위치, 즉 네트워크에서의 위치를 ​​의미함). 하지만 노드가 활성화되면 더 많은 후보자가 있을 것입니다. 다른네트워크.

좀 더 복잡한 사례로 넘어 갑시다. 한 노드는 라우터 뒤에(보다 정확하게는 NAT 뒤에) 위치하며, 두 번째 노드는 이 라우터와 동일한 네트워크(예: 인터넷)에 위치합니다(그림 9).

그림 9: 한 노드는 NAT 뒤에 있고 다른 노드는 NAT 뒤에 있습니다.

이 사례에는 문제에 대한 특별한 해결책이 있으며 이제 이를 고려해 보겠습니다. 홈 라우터일반적으로 테이블이 포함되어 있습니다. NAT. 이는 라우터의 개인 네트워크 내부 노드가 웹 사이트 등에 액세스할 수 있도록 설계된 특수 메커니즘입니다.

웹 서버가 인터넷에 직접 연결되어 있다고 가정해보자. IP* 주소. 이것을 노드로 놔두세요 p2. 매듭 p1(웹 클라이언트)는 해당 주소로 요청을 보냅니다. 10.50.200.10 . 먼저 데이터가 라우터로 이동합니다. r1, 또는 오히려 그의 내부상호 작용 192.168.0.1 . 그 후 라우터는 소스 주소(주소 p1) 특수 테이블에 입력합니다. NAT, 소스 주소를 귀하의 주소로 변경합니다( p1 → r1). 더 나아가 나만의 방식으로 외부인터페이스, 라우터는 웹 서버에 직접 데이터를 보냅니다. p2. 웹 서버는 데이터를 처리하고 응답을 생성하여 다시 보냅니다. 라우터로 전송 r1, 반환 주소에 있는 사람이 바로 그 사람이기 때문입니다(라우터가 주소를 자체 주소로 대체했습니다). 라우터는 데이터를 수신하고 테이블을 봅니다. NAT그리고 데이터를 노드로 전달합니다. p1. 여기서 라우터는 중개자 역할을 합니다.

내부 네트워크의 여러 노드가 동시에 외부 네트워크에 접속한다면 어떻게 될까요? 라우터는 응답을 누구에게 다시 보낼지 어떻게 이해합니까? 이 문제는 다음을 사용하여 해결됩니다. 포트. 라우터가 호스트 주소를 자신의 주소로 교체하면 포트도 교체됩니다. 두 노드가 인터넷에 액세스하면 라우터는 해당 소스 포트를 다음으로 대체합니다. 다른. 그런 다음 웹 서버의 패킷이 라우터로 돌아오면 라우터는 패킷이 할당된 포트를 통해 이해하게 됩니다. 아래 예.

기술로 돌아가자 WebRTC, 또는 오히려 사용하는 부분에 얼음프로토콜(따라서 얼음후보자). 매듭 p2하나의 후보가 있습니다(네트워크에서의 위치 – 10.50.200.10 ) 및 노드 p1 NAT가 있는 라우터 뒤에 있는 에는 로컬( 192.168.0.200 ) 및 라우터 후보( 10.50.200.5 ). 첫 번째는 유용하지 않지만 그럼에도 불구하고 생성됩니다. WebRTC원격 노드에 대해 아직 아무것도 모릅니다. 동일한 네트워크에 있을 수도 있고 그렇지 않을 수도 있습니다. 두 번째 후보가 도움이 될 것이며 이미 알고 있듯이 항구는 중요한 역할을 할 것입니다. NAT).

테이블 항목 NAT데이터가 내부 네트워크를 떠날 때만 생성됩니다. 따라서 노드 p1데이터를 먼저 전송해야 하고 그 후에 노드 데이터를 전송해야 합니다. p2노드에 도달할 수 있을 것이다 p1.

연습 중 두 노드 모두뒤쳐질 것이다 NAT. 테이블에 레코드를 생성하려면 NAT각 라우터의 노드는 원격 노드에 무언가를 보내야 하지만 이번에는 첫 번째 노드가 두 번째 노드에 도달할 수 없으며 그 반대도 마찬가지입니다. 이는 노드가 자신의 외부를 알지 못하기 때문입니다. IP내부 주소로 데이터를 보내는 것은 의미가 없습니다.

그러나 외부 주소를 알면 연결이 쉽게 설정됩니다. 첫 번째 노드가 두 번째 노드의 라우터로 데이터를 보내면 라우터는 이를 무시합니다. NAT지금은 비어 있습니다. 그러나 테이블의 첫 번째 노드의 라우터에서는 NAT녹음이 필요해요. 이제 두 번째 노드가 첫 번째 노드의 라우터로 데이터를 전송하면 라우터는 해당 데이터를 첫 번째 노드로 성공적으로 전송합니다. 이제 테이블 NAT두 번째 라우터에는 데이터가 필요합니다.

문제는 외부인을 인식하기 위해 IP주소, 다음 위치에 노드가 필요합니다. 공유 네트워크. 이 문제를 해결하기 위해 인터넷에 직접 연결된 추가 서버가 사용됩니다. 그들의 도움으로 테이블에 소중한 항목도 생성됩니다. NAT.

STUN 및 TURN 서버

초기화 시 WebRTC사용 가능함을 표시해야 합니다. 충격그리고 회전하다우리가 추가로 호출할 서버 얼음서버. 서버가 지정되지 않은 경우 동일한 네트워크의 노드만(서버 없이 연결됨) NAT). 즉시 주목할 가치가 있습니다. 3g- 네트워크를 사용해야 합니다. 회전하다서버.

충격 섬기는 사람반환 주소, 즉 보낸 사람 노드의 주소를 반환하는 인터넷의 서버일 뿐입니다. 라우터 뒤에 위치한 노드가 액세스합니다. 충격통과할 서버 NAT. 패키지가 도착했습니다 충격서버에는 소스 주소, 즉 라우터 주소, 즉 노드의 외부 주소가 포함됩니다. 이 주소 충격서버에서 다시 보냅니다. 따라서 노드는 외부로부터 수신을 받습니다. IP네트워크에서 액세스할 수 있는 주소와 포트입니다. 더 나아가, WebRTC이 주소를 사용하면 추가 후보(외부 라우터 주소 및 포트)가 생성됩니다. 이제 테이블에 NAT라우터에는 필요한 포트의 라우터로 전송된 패킷이 노드를 통과하도록 허용하는 항목이 있습니다.

예를 들어 이 과정을 살펴보겠습니다.

예시(STUN 서버 운영)

충격우리는 서버를 다음과 같이 표시하겠습니다. s1. 라우터는 이전과 마찬가지로 r1및 노드 – 통해 p1. 또한 표를 따라야합니다. NAT– 다음과 같이 표기하자 r1_nat. 또한 이 테이블에는 일반적으로 서브넷의 여러 노드에서 가져온 많은 레코드가 포함되어 있으므로 제공되지 않습니다.

그래서 처음에는 빈 테이블이 있습니다. r1_nat.

표 2: 패킷 헤더

매듭 p1이 패킷을 라우터로 보냅니다. r1(어쨌든 서로 다른 서브넷에서 사용할 수 있습니다. 다양한 기술). 라우터는 소스 주소를 변경해야 합니다 원본 IP, 패킷에 지정된 주소는 분명히 외부 서브넷에 적합하지 않기 때문에 또한 그러한 범위의 주소는 예약되어 있으며 인터넷의 단일 주소에는 그러한 주소가 없습니다. 라우터는 패킷을 대체하고 다음을 생성합니다. 새로운 항목당신의 테이블에 r1_nat. 이렇게 하려면 포트 번호를 알아내야 합니다. 서브넷 내의 여러 노드가 외부 네트워크에 액세스할 수 있으므로 테이블에서 NAT보관해야 한다 추가 정보, 라우터는 이러한 여러 노드 중 서버에서 반환 패킷을 보낼 대상을 결정할 수 있습니다. 라우터가 포트를 생성하도록 하세요 888 .

변경된 패키지 헤더:

표 4: NAT 테이블이 새 항목으로 업데이트되었습니다.

여기 IP서브넷의 주소와 포트는 원본 패킷과 정확히 동일합니다. 실제로 포스트백을 할 때에는 이를 완전히 복원할 수 있는 방법이 있어야 합니다. IP외부 네트워크의 주소는 라우터의 주소이며, 포트는 라우터가 고안한 포트로 변경되었습니다.

노드가 연결되는 실제 포트 p1연결을 수락합니다. 물론 이것은 35777 하지만 서버는 다음으로 데이터를 보냅니다. 허구의포트 888 , 라우터에 의해 실제 라우터로 변경됩니다. 35777 .

따라서 라우터는 패킷 헤더의 소스 주소와 포트를 대체하고 테이블에 항목을 추가했습니다. NAT. 이제 패킷은 네트워크를 통해 서버, 즉 노드로 전송됩니다. s1. 입구에서, s1이 패키지가 있습니다:

원본 IP	소스 포트	대상 IP	대상 포트
10.50.200.5	888	12.62.100.200	6000

표 5: STUN 서버 수신 패킷

총 충격서버는 해당 주소로부터 패킷을 받았다는 것을 알고 있습니다. 10.50.200.5:888 . 이제 서버는 이 주소를 다시 보냅니다. 여기에서 멈춰서 방금 살펴본 내용을 다시 살펴보는 것이 좋습니다. 위의 표는 머리글패키지, 전혀 그것에서 콘텐츠. 내용은 그다지 중요하지 않기 때문에 우리는 내용에 대해 이야기하지 않았습니다. 프로토콜에 어떻게 든 설명되어 있습니다. 충격. 이제 제목 외에 내용도 살펴보겠습니다. 그것은 간단하며 라우터 주소를 포함합니다 - 10.50.200.5:888 , 비록 우리가 그것을 가져왔지만 머리글패키지. 이는 자주 수행되지 않습니다. 프로토콜은 일반적으로 노드 주소에 대한 정보에 관심이 없으며 패킷이 의도한 대상으로 전달되는 것만 중요합니다. 여기서는 두 노드 사이에 경로를 설정하는 프로토콜을 살펴보겠습니다.

이제 반대 방향으로 가는 두 번째 패킷이 생겼습니다.

표 7: STUN 서버는 이 콘텐츠가 포함된 패킷을 보냅니다.

다음으로, 패킷은 라우터의 외부 인터페이스에 도달할 때까지 네트워크를 통해 이동합니다. r1. 라우터는 패킷이 자신을 위한 것이 아니라는 것을 이해합니다. 그는 이것을 어떻게 이해합니까? 이는 포트에 의해서만 결정될 수 있습니다. 포트 888 그는 그것을 개인적인 목적으로 사용하지 않고 메커니즘을 위해 사용합니다. NAT. 따라서 라우터는 이 테이블을 봅니다. 칼럼을 보니 외부 포트일치하는 문자열을 찾습니다. 대상 포트들어오는 패키지에서, 즉 888 .

내부 IP	내부 포트	외부 IP	외부 포트
192.168.0.200	35777	10.50.200.5	888

표 8: NAT 테이블

운이 좋게도 그런 선이 존재합니다. 운이 좋지 않다면 패킷은 그냥 버려질 것입니다. 이제 서브넷의 어느 노드가 이 패킷을 보내야 하는지 이해해야 합니다. 서두를 필요가 없습니다. 이 메커니즘에서 포트의 중요성을 다시 한번 기억해 봅시다. 동시에 서브넷의 두 노드는 외부 네트워크에 요청을 보낼 수 있습니다. 그런 다음 첫 번째 노드에 대해 라우터가 포트를 찾았다면 888 , 그런 다음 두 번째로 그는 포트를 생각해 낼 것입니다 889 . 이런 일이 발생했다고 가정 해 봅시다. 즉, 테이블 r1_nat다음과 같습니다:

표 10: 라우터는 수신자 주소를 대체합니다.

원본 IP	소스 포트	대상 IP	대상 포트
12.62.100.200	6000	192.168.0.200	35777

표 11: 라우터가 수신자 주소를 변경했습니다.

패킷이 노드에 성공적으로 도착했습니다. p1그리고 패킷의 내용을 보고 노드는 자신의 외부 정보에 대해 알게 됩니다. IP주소, 즉 외부 네트워크의 라우터 주소입니다. 그는 또한 라우터가 통과하는 포트를 알고 있습니다. NAT.

무엇 향후 계획? 이 모든 것이 다 무슨 소용이 있습니까? 혜택은 테이블의 항목입니다. r1_nat. 이제 누군가가 라우터로 보내면 r1포트가 있는 패키지 888 , 그러면 라우터는 이 패킷을 노드로 전달합니다. p1. 따라서 숨겨진 노드로 가는 작고 좁은 통로가 만들어졌습니다. p1.

위의 예에서 작동 방식에 대한 아이디어를 얻을 수 있습니다. NAT그리고 본질 충격섬기는 사람. 일반적으로 메커니즘은 얼음그리고 기절/회전서버는 한계를 극복하는 것을 정확하게 목표로 삼고 있습니다. NAT.

노드와 서버 사이에는 하나의 라우터가 아니라 여러 개가 있을 수 있습니다. 이 경우 노드는 서버와 동일한 네트워크에 가장 먼저 접속한 라우터의 주소를 받게 됩니다. 즉, 연결된 라우터의 주소를 얻습니다. 충격섬기는 사람. 을 위한 p2p각 라우터가 테이블에 필요한 행을 추가한다는 사실을 잊지 않는다면 통신은 정확히 우리에게 필요한 것입니다. NAT. 그러므로 돌아오는 길도 마찬가지로 순조로울 것입니다.

회전하다서버가 좋아졌네요 충격섬기는 사람. 여기서부터 다음과 같은 사실을 즉시 배워야 합니다. 회전하다서버가 작동할 수 있는 방법과 방법 충격섬기는 사람. 그러나 장점도 있습니다. 만약에 p2p통신이 불가능합니다(예: 3g네트워크), 서버는 리피터 모드( 계전기), 즉 중개자 역할을 합니다. 물론 아무것도 아닌 것에 대해 p2p그러면 의문의 여지가 없지만 메커니즘의 틀 밖에서 얼음노드는 직접 통신하고 있다고 생각합니다.

어떤 경우에 필요한가요? 회전하다섬기는 사람? 왜 부족해요 충격서버? 사실은 여러 가지 종류가 있다는 것입니다 NAT. 동등하게 대체합니다. IP주소와 포트가 있지만 일부에는 "위조"에 대한 추가 보호 기능이 내장되어 있습니다. 예를 들어, 대칭테이블 NAT 2개의 매개변수가 더 저장되었습니다 - IP그리고 원격 노드의 포트입니다. 외부 네트워크의 패킷이 통과합니다. NAT소스 주소와 포트가 표에 기록된 것과 일치하는 경우에만 내부 네트워크에 연결됩니다. 그러므로 초점은 충격서버 실패 - 테이블 NAT주소와 포트를 저장합니다. 충격서버에서 라우터가 패킷을 수신할 때 WebRTC대담자는 그것이 "위조"되었기 때문에 그것을 버립니다. 그 사람은 출신이 아니었어 충격섬기는 사람.

따라서 회전하다두 대담자가 모두 있을 때 서버가 필요합니다. 대칭 NAT(각자 자신에게).

간단한 요약

다음은 엔터티에 대한 몇 가지 설명입니다. WebRTC항상 명심해야 할 점. 위에 자세히 설명되어 있습니다. 진술 중 하나라도 완전히 명확하지 않은 경우 관련 단락을 다시 읽으십시오.

• 미디어 스트림
  • 비디오 및 오디오 데이터는 미디어 스트림으로 패키징됩니다.
  • 미디어 스트림은 구성하는 미디어 트랙을 동기화합니다.
  • 서로 다른 미디어 스트림이 서로 동기화되지 않습니다.
  • 미디어 스트림은 로컬 및 원격일 수 있으며, 로컬 스트림은 일반적으로 카메라와 마이크에 연결되고, 원격 스트림은 암호화된 형식으로 네트워크에서 데이터를 수신합니다.
  • 미디어 트랙에는 비디오용과 오디오용의 두 가지 유형이 있습니다.
  • 미디어 트랙에는 켜기/끄기 기능이 있습니다.
  • 미디어 트랙은 미디어 채널로 구성됩니다.
  • 미디어 트랙은 구성하는 미디어 채널을 동기화합니다.
  • 미디어 스트림과 미디어 트랙에는 구별할 수 있는 레이블이 있습니다.
• 세션 핸들
  • 세션 설명자는 두 개의 네트워크 노드를 논리적으로 연결하는 데 사용됩니다.
  • 세션 설명자는 다음에 대한 정보를 저장합니다. 사용 가능한 방법비디오 및 오디오 데이터 인코딩
  • WebRTC외부 신호 메커니즘을 사용합니다 - 세션 설명자를 전달하는 작업( SDP) 신청서에 해당
  • 논리적 연결 메커니즘은 문장( 권하다) 그리고 대답 ( 답변)
  • 제안서의 경우 로컬 미디어 스트림을 사용하지 않으면 세션 설명자 생성이 불가능합니다( 권하다) 응답이 있는 경우 원격 세션 핸들을 사용하지 않으면 불가능합니다( 답변)
  • 결과 설명자는 구현에 제공되어야 합니다. WebRTC, 그리고 이 설명자가 동일한 구현에서 원격으로 얻어졌는지 아니면 로컬로 얻어졌는지 여부는 중요하지 않습니다. WebRTC
  • 세션 설명자를 약간 편집할 수 있습니다.
• 후보자
  • 후보자 ( 아이스 후보)는 네트워크에 있는 노드의 주소입니다.
  • 노드 주소는 자신의 주소일 수도 있고, 라우터 또는 라우터의 주소일 수도 있습니다. 회전하다서버
  • 항상 후보자가 많다.
  • 후보자는 다음과 같이 구성됩니다. IP주소, 항구 및 운송 유형( TCP또는 UDP)
  • 후보자는 네트워크의 두 노드 사이에 물리적 연결을 설정하는 데 사용됩니다.
  • 또한 후보자는 신호 메커니즘을 통해 전송되어야 합니다.
  • 후보자도 구현으로 전환되어야 합니다. WebRTC, 그러나 원격으로만 가능
  • 일부 구현에서는 WebRTC후보자는 세션 설명자가 설정된 후에만 전송될 수 있습니다.
• 기절/회전/얼음/NAT
  • NAT– 외부 네트워크에 대한 액세스를 제공하는 메커니즘
  • 홈 라우터는 특수 테이블을 지원합니다. NAT
  • 라우터는 패킷의 주소를 대체합니다. 즉, 패킷이 외부 네트워크로 이동하는 경우 소스 주소를 자체 주소로 바꾸고, 패킷이 외부 네트워크에서 제공된 경우 수신자 주소를 내부 네트워크의 호스트 주소로 바꿉니다.
  • 외부 네트워크에 대한 다중 채널 액세스를 제공하려면 NAT포트를 사용합니다
  • 얼음– 우회 메커니즘 NAT
  • 충격그리고 회전하다서버 - 우회를 위한 도우미 서버 NAT
  • 충격서버를 사용하면 테이블에 필요한 레코드를 생성할 수 있습니다. NAT, 또한 노드의 외부 주소를 반환합니다.
  • 회전하다서버 일반화 충격메커니즘을 사용하여 항상 작동하게 만듭니다.
  • 최악의 경우 회전하다서버는 중개자로 사용됩니다( 계전기), 그건 p2p클라이언트-서버-클라이언트 통신으로 전환됩니다.

WebRTC(Web Real Time Communications)는 플러그인이나 기타 확장 프로그램을 설치하지 않고도 스트리밍 오디오 데이터, 비디오 데이터 및 콘텐츠를 브라우저에서 실시간으로 전송하는 것을 설명하는 표준입니다. 표준을 사용하면 브라우저를 화상 회의 터미널로 전환할 수 있으며 웹 페이지를 열면 통신을 시작할 수 있습니다.

WebRTC란 무엇입니까?

이 기사에서는 WebRTC 기술에 대해 알아야 할 모든 것을 살펴보겠습니다. 일반 사용자. 프로젝트의 장점과 단점을 살펴보고, 몇 가지 비밀을 밝히고, 어떻게 작동하는지, WebRTC가 어디에, 어떤 용도로 사용되는지 알려드리겠습니다.

WebRTC에 대해 알아야 할 사항은 무엇입니까?

영상통신 표준 및 기술의 진화

Sergey Yutsaitis, Cisco, 비디오+컨퍼런스 2016

WebRTC 작동 방식

고객 입장에서

• 사용자가 HTML5 태그가 포함된 페이지를 엽니다.
• 브라우저는 사용자의 웹캠과 마이크에 대한 액세스를 요청합니다.
• 사용자 페이지의 JavaScript 코드는 연결 매개변수(WebRTC 서버 또는 기타 WebRTC 클라이언트의 IP 주소 및 포트)를 제어하여 NAT 및 방화벽을 우회합니다.
• 대담자 또는 서버에서 혼합된 회의 스트림에 대한 정보를 수신하면 브라우저는 사용된 오디오 및 비디오 코덱 협상을 시작합니다.
• 인코딩 프로세스가 시작되고 WebRTC 클라이언트 간(이 경우 브라우저와 서버 간) 스트리밍 데이터 전송이 시작됩니다.

WebRTC 서버 측에서

두 참가자 간의 데이터 교환에는 비디오 서버가 필요하지 않지만, 하나의 회의에 여러 참가자를 결합해야 하는 경우 서버가 필요합니다.

비디오 서버는 다양한 소스로부터 미디어 트래픽을 수신하고 변환하여 WebRTC를 터미널로 사용하는 사용자에게 보냅니다.

또한 WebRTC 서버는 WebRTC 피어로부터 미디어 트래픽을 수신하고 이를 위해 애플리케이션을 사용하는 회의 참가자에게 전송합니다. 데스크톱 컴퓨터또는 모바일 장치, 만약에 어떠한.

표준의 장점

• 소프트웨어 설치가 필요하지 않습니다.
• 다음과 같은 덕분에 매우 높은 품질의 커뮤니케이션이 가능합니다.
  • 최신 비디오(VP8, H.264) 및 오디오 코덱(Opus) 사용.
  • 연결 조건에 따라 스트림 품질을 자동으로 조정합니다.
  • 에코 및 소음 감소 시스템이 내장되어 있습니다.
  • 참가자 마이크(AGC)의 감도 수준을 자동으로 조정합니다.
• 높은 수준의 보안: 모든 연결은 TLS 및 SRTP 프로토콜을 사용하여 보호되고 암호화됩니다.
• 예를 들어 데스크탑과 같은 콘텐츠를 캡처하기 위한 메커니즘이 내장되어 있습니다.
• HTML5 및 JavaScript를 기반으로 모든 관리 인터페이스를 구현할 수 있습니다.
• WebSocket을 사용하여 모든 백엔드 시스템과 인터페이스를 통합하는 기능.
• 공개된 프로젝트 소스 코드— 귀하의 제품이나 서비스에 구현될 수 있습니다.
• 진정한 크로스 플랫폼: 동일한 WebRTC 애플리케이션은 어느 환경에서나 동일하게 작동합니다. 운영 체제, 데스크톱 또는 모바일(브라우저가 WebRTC를 지원하는 경우) 이를 통해 소프트웨어 개발에 소요되는 리소스를 크게 절약할 수 있습니다.

표준의 단점

• 그룹 오디오 및 비디오 회의를 구성하려면 참가자의 비디오와 사운드를 혼합하는 비디오 회의 서버가 필요합니다. 브라우저는 여러 수신 스트림을 서로 동기화하는 방법을 모릅니다.
• 모든 WebRTC 솔루션은 서로 호환되지 않습니다. 왜냐하면... 표준은 비디오 및 오디오 전송 방법만 설명하고 가입자 주소 지정, 가용성 추적, 메시지 및 파일 교환, 일정 예약 및 기타 사항을 공급업체에 맡기는 방법을 구현합니다.
• 즉, 한 개발자의 WebRTC 애플리케이션에서 다른 개발자의 WebRTC 애플리케이션으로 호출할 수 없습니다.
• 혼합 그룹 회의에는 대규모 컴퓨팅 리소스가 필요하므로 이러한 유형의 비디오 통신에는 유료 구독을 구매하거나 인프라에 투자해야 하며, 각 회의에는 최신 프로세서의 물리적 코어 1개가 필요합니다.

WebRTC 비밀: 공급업체가 획기적인 웹 기술로 혜택을 받는 방법

Tzachi Levent-Levi, Bloggeek.me, 비디오+컨퍼런스 2015

화상회의 시장을 위한 WebRTC

화상회의 단말기 수 증가

WebRTC 기술은 화상회의 시장 발전에 큰 영향을 미쳤습니다. 2013년 WebRTC를 지원하는 최초의 브라우저가 출시된 후 전 세계의 잠재적인 화상 회의 터미널 수는 즉시 10억 대까지 증가했습니다. 실제로 각 브라우저는 통신 품질 측면에서 하드웨어에 비해 열등하지 않은 화상 회의 터미널이 되었습니다.

특수 솔루션에 사용

WebRTC 지원과 함께 다양한 JavaScript 라이브러리 및 클라우드 서비스 API를 사용하면 모든 웹 프로젝트에 비디오 통신 지원을 쉽게 추가할 수 있습니다. 이전에는 실시간으로 데이터를 전송하기 위해 개발자가 프로토콜 작동 원리를 연구하고 다른 회사의 개발을 사용해야 했으며, 이로 인해 추가 라이선스가 필요한 경우가 많아 비용이 증가했습니다. WebRTC는 이미 '사이트에서 전화', '온라인 채팅 지원' 등의 서비스에서 활발히 사용되고 있습니다.

Linux용 Skype의 이전 사용자

2014년에 Microsoft는 Linux용 Skype 프로젝트에 대한 지원 종료를 발표하여 IT 전문가들 사이에 큰 분노를 불러일으켰습니다. WebRTC 기술은 운영 체제에 묶여 있지 않고 브라우저 수준에서 구현됩니다. 리눅스 사용자 Skype를 완전히 대체할 WebRTC 기반의 제품과 서비스를 볼 수 있을 것입니다.

플래시와의 경쟁

WebRTC와 HTML5는 이미 최악의 시기를 겪고 있던 Flash 기술에 치명적인 타격을 입혔습니다. 2017년부터 주요 브라우저는 공식적으로 Flash 지원을 중단했으며 해당 기술은 시장에서 완전히 사라졌습니다. 그러나 웹 회의 시장을 창조하고 기술적 능력브라우저에서의 실시간 커뮤니케이션을 위해.

WebRTC 비디오 프레젠테이션

Dmitry Odintsov, TrueConf, 화상+컨퍼런스 2017년 10월

WebRTC의 코덱

오디오 코덱

WebRTC는 Opus 및 G.711 코덱을 사용하여 오디오 트래픽을 압축합니다.

G.711- 기존 전화 통신 시스템에서 가장 자주 사용되는 높은 비트 전송률(64kbps)을 갖춘 가장 오래된 음성 코덱입니다. 가장 큰 장점은 경량 압축 알고리즘을 사용하므로 계산 부하가 최소화된다는 것입니다. 코덱은 음성 신호 압축 수준이 낮으며 사용자 간 통신 중에 추가적인 오디오 지연을 발생시키지 않습니다.

G.711은 다양한 장치에서 지원됩니다. 이 코덱을 사용하는 시스템은 다른 오디오 코덱(G.723, G.726, G.728 등)을 기반으로 하는 시스템보다 사용하기가 더 쉽습니다. 품질 측면에서 G.711은 MOS 테스트에서 4.2점을 받았습니다(4~5점 사이가 가장 높으며 이는 양질, ISDN의 음성 트래픽 전송 품질과 유사하며 훨씬 더 높습니다).

작인코딩 대기 시간(2.5ms ~ 60ms)이 낮고 가변 비트 전송률과 높은 압축 수준을 지원하는 코덱으로, 가변적인 네트워크에서 스트리밍 오디오 신호를 전송하는 데 이상적입니다. 처리량. Opus는 SILK(음성 압축, 음성 왜곡 제거) 코덱과 CELT(오디오 데이터 코딩) 코덱의 최고의 특성을 결합한 하이브리드 솔루션입니다. 코덱은 무료로 사용할 수 있으므로 이를 사용하는 개발자는 저작권 보유자에게 로열티를 지불할 필요가 없습니다. 다른 오디오 코덱과 비교할 때 Opus는 의심할 여지없이 여러 측면에서 승리합니다. 이는 MP3, Vorbis, AAC LC와 같은 매우 널리 사용되는 낮은 비트 전송률 코덱을 능가합니다. Opus는 AMR-WB 및 Speex보다 원본에 더 가까운 사운드 "그림"을 복원합니다. 이 코덱은 미래이므로 WebRTC 기술 작성자는 이를 지원되는 오디오 표준의 필수 범위에 포함시켰습니다.

비디오 코덱

개발자들은 WebRTC용 비디오 코덱을 선택하는 데 몇 년이 걸렸고 결국 H.264와 VP8을 사용하기로 결정했습니다. 거의 모든 최신 브라우저는 두 코덱을 모두 지원합니다. 화상 회의 서버는 WebRTC와 작동하기 위해 하나만 지원하면 됩니다.

VP8- 오픈 라이센스가 있는 무료 비디오 코덱으로, 높은 비디오 스트림 디코딩 속도와 향상된 프레임 손실 저항이 특징입니다. 코덱은 보편적이고 하드웨어 플랫폼에 구현하기 쉽기 때문에 화상 회의 시스템 개발자는 제품에서 코덱을 자주 사용합니다.

유료 비디오 코덱 H.264그의 형보다 훨씬 일찍 유명해졌습니다. 저장할 때 비디오 스트림의 압축률이 높은 코덱입니다. 고품질동영상. 하드웨어 화상 회의 시스템에서 이 코덱이 널리 사용된다는 점은 WebRTC 표준에서 이 코덱을 사용하는 것을 의미합니다.

Google과 Mozilla는 VP8 코덱을 적극적으로 홍보하고 있으며 Microsoft, Apple, Cisco는 기존 화상 회의 시스템과의 호환성을 보장하기 위해 H.264를 적극적으로 홍보하고 있습니다. 그리고 여기에서 클라우드 WebRTC 솔루션 개발자에게는 매우 큰 문제가 발생합니다. 회의의 모든 참가자가 동일한 브라우저를 사용하는 경우 회의를 하나의 코덱으로 한 번 혼합하는 것으로 충분하고 브라우저가 다르고 Safari/Edge가 그 중에서 회의는 두 개의 서로 다른 코덱으로 인코딩되어야 하며, 이는 두 배의 코덱을 사용하게 됩니다. 시스템 요구 사항미디어 서버에 전송되며 결과적으로 WebRTC 서비스 구독 비용이 발생합니다.

WebRTC API

WebRTC 기술은 세 가지 주요 API를 기반으로 합니다.

• (카메라나 사용자의 데스크톱에서 오디오 및 비디오 신호를 수신하는 웹 브라우저를 담당합니다.)
• RTCPeerConnection(카메라, 마이크 및 데스크탑에서 수신된 미디어 데이터를 "교환"하기 위해 브라우저 간 연결을 담당합니다. 또한 이 API의 "책임"에는 신호 처리(외부 소음 제거, 마이크 볼륨 조정) 및 제어가 포함됩니다. 사용된 오디오 및 비디오 코덱).
• RTC데이터 채널(확립된 연결을 통해 양방향 데이터 전송을 제공합니다).

사용자의 마이크와 카메라에 접근하기 전에 브라우저는 이에 대한 권한을 요청합니다. 안에 구글 크롬"설정" 섹션에서 미리 액세스를 구성할 수 있으며, Opera 및 Firefox에서는 액세스 권한을 얻을 때 드롭다운 목록에서 장치가 직접 선택됩니다. 권한 요청은 HTTP 프로토콜을 사용할 때 항상 나타나며, HTTPS를 사용할 때는 한 번만 나타납니다.

RTCPeerConnection. WebRTC 회의에 참여하는 각 브라우저는 다음에 대한 액세스 권한이 있어야 합니다. 이 개체. RTCPeerConnection을 사용하면 한 브라우저에서 다른 브라우저로 미디어 데이터가 NAT 및 방화벽. 미디어 스트림을 성공적으로 전송하려면 참가자는 웹 소켓과 같은 전송을 사용하여 다음 데이터를 교환해야 합니다.

• 시작 참가자는 두 번째 참가자에게 Offer-SDP(전송할 미디어 스트림의 특성이 포함된 데이터 구조)를 보냅니다.
• 두 번째 참가자는 "응답"(Answer-SDP)을 생성하여 개시자에게 보냅니다.
• 그런 다음 참가자가 감지되면(참가자가 NAT 또는 방화벽 뒤에 있는 경우) 참가자 간에 ICE 후보 교환이 구성됩니다.

이 교환이 성공적으로 완료되면 참가자 간에 미디어 스트림(오디오 및 비디오)의 직접 전송이 구성됩니다.

RTC데이터 채널. 데이터 채널 프로토콜에 대한 지원은 비교적 최근에 브라우저에 나타났으므로 이 API는 브라우저에서 WebRTC를 사용하는 경우에만 고려할 수 있습니다. 모질라 파이어 폭스 22+ 및 Google 크롬 26+. 도움을 받아 참가자는 교환할 수 있습니다. 문자 메시지브라우저에서.

WebRTC를 통한 연결

지원되는 데스크탑 브라우저

• Google Chrome(17+) 및 Chromium 엔진 기반의 모든 브라우저
• 모질라 파이어폭스(18세 이상);
• 오페라(12세 이상);
• 사파리(11+);

Android에 지원되는 모바일 브라우저

• 구글 크롬(28+);
• 모질라 파이어폭스(24+);
• 오페라 모바일(12+);
• 사파리(11+).

WebRTC, 마이크로소프트, 인터넷 익스플로러

오랫동안 Microsoft는 Internet Explorer와 새로운 Edge 브라우저의 WebRTC 지원에 대해 침묵을 지켰습니다. Redmond의 사람들은 자신들이 통제할 수 없는 기술을 사용자의 손에 맡기는 것을 별로 좋아하지 않습니다. 그것이 그들의 정책입니다. 그러나 점차적으로 문제는 막다른 지점에서 멀어졌습니다. 왜냐하면... 더 이상 WebRTC를 무시할 수 없게 되었고, WebRTC 표준의 파생물인 ORTC 프로젝트가 발표되었습니다.

개발자에 따르면 ORTC는 JavaScript 및 HTML5를 기반으로 한 향상된 API 세트를 갖춘 WebRTC 표준의 확장입니다. 이는 일반 언어로 번역되면 모든 것이 동일하며 Google이 아닌 Microsoft만이 표준을 제어한다는 의미입니다. 그리고 그것의 발전. 전화 통신 및 하드웨어 화상 회의 시스템에 사용되는 G.7ХХ 시리즈의 일부 오디오 코덱과 H.264에 대한 지원으로 코덱 세트가 확장되었습니다. RDP(콘텐츠 전송용) 및 메시징에 대한 지원이 기본 제공될 수 있습니다. 그런데 Internet Explorer 사용자는 운이 좋지 않습니다. ORTC 지원은 Edge에서만 사용할 수 있습니다. 그리고 물론 이 프로토콜 및 코덱 세트는 비즈니스용 Skype와 쉽게 인터페이스하여 WebRTC를 위한 훨씬 더 많은 비즈니스 애플리케이션을 열어줍니다.

이 글의 목적은 P2P 비디오 채팅(P2P 비디오 채팅)의 데모 샘플을 사용하여 그 구조와 작동 원리를 익히는 것입니다. 이를 위해 다중 사용자 P2P 화상 채팅 데모 webrtc.io-demo를 사용합니다. https://github.com/webRTC/webrtc.io-demo/tree/master/site 링크에서 다운로드할 수 있습니다.

GitHub는 웹 프로젝트의 공동 개발을 위한 사이트 또는 웹 서비스라는 점에 유의해야 합니다. 여기에 개발자는 자신의 개발 코드를 게시하고 이에 대해 토론하며 서로 소통할 수 있습니다. 또한 일부 대형 IT 회사에서는 이 사이트에 공식 저장소를 게시합니다. 오픈 소스 프로젝트의 경우 이 서비스는 무료입니다. GitHub는 개방형 무료 소스 코드 라이브러리를 위한 저장소입니다.

따라서 GitHub에서 다운로드한 P2P 영상 채팅 데모 샘플을 C 드라이브에 배치하겠습니다. 개인용 컴퓨터우리 애플리케이션 "webrtc_demo"를 위해 생성된 디렉토리에 있습니다.

쌀. 1

구조(그림 1)에서 다음과 같이 P2P 화상 채팅은 JavaScript 프로그래밍 언어로 구현된 클라이언트 script.js와 서버 server.js 스크립트로 구성됩니다. 스크립트(라이브러리) webrtc.io.js(CLIENT) - P2P 체계("client-client", webrtc.io.js(CLIENT) 및 webrtc)를 사용하여 브라우저 간의 실시간 통신 구성을 제공합니다. io.js(SERVER)는 WebSocket 프로토콜을 사용하여 클라이언트-서버 아키텍처를 사용하여 브라우저와 웹 서버 간의 이중 통신을 제공합니다.

webrtc.io.js(SERVER) 스크립트는 webrtc.io 라이브러리에 포함되어 있으며 node_modules\webrtc.io\lib 디렉터리에 있습니다. 화상 채팅 인터페이스 index.html은 HTML5 및 CSS3에서 구현됩니다. webrtc_demo 애플리케이션 파일의 내용은 "Notepad++"와 같은 HTML 편집기 중 하나를 사용하여 볼 수 있습니다.

영상채팅의 작동원리를 확인해보겠습니다. 파일 시스템 PC. PC에서 서버(server.js)를 실행하려면 node.js 런타임 환경을 설치해야 합니다. Node.js를 사용하면 브라우저 외부에서 JavaScript 코드를 실행할 수 있습니다. http://nodejs.org/(2013년 7월 15일 기준 v0.10.13 버전) 링크에서 node.js를 다운로드할 수 있습니다. node.org 웹사이트 메인 페이지에서 다운로드 버튼을 클릭하고 http://nodejs.org/download/로 이동하세요. Windows 사용자의 경우 먼저 win.installer(.msi)를 다운로드한 후 PC에서 win.installer(.msi)를 실행하고 Program Files 디렉터리에 nodejs와 "npm 패키지 관리자"를 설치합니다.

쌀. 2

따라서 node.js는 JavaScript 코드를 개발하고 실행하기 위한 환경과 관리자 또는 npm 패키지 관리자를 사용하여 설치할 수 있는 내부 모듈 세트로 구성됩니다.

모듈을 설치하려면 다음을 수행해야 합니다. 명령줄애플리케이션 디렉터리(예: "webrtc_demo")에서 다음 명령을 실행합니다. npm 설치 module_name. 모듈을 설치하는 동안 npm 관리자는 설치가 수행된 디렉터리에 node_modules 폴더를 생성합니다. 작동 중에 nodejs는 node_modules 디렉터리의 모듈을 자동으로 연결합니다.

따라서 node.js를 설치한 후 명령줄을 열고 npm 패키지 관리자를 사용하여 webrtc_demo 디렉터리의 node_modules 폴더에 있는 express 모듈을 업데이트하세요.

C:\webrtc_demo>npm 설치 익스프레스

Express 모듈은 node.js용 웹 프레임워크 또는 애플리케이션 개발을 위한 웹 플랫폼입니다. Express에 전역적으로 액세스하려면 다음과 같이 설치할 수 있습니다. npm 설치 -g 익스프레스.

그런 다음 webrtc.io 모듈을 업데이트합니다.

C:\webrtc_demo>npm은 webrtc.io를 설치합니다.

그런 다음 명령줄에서 server.js를 시작합니다.

C:\webrtc_demo>노드 서버.js

쌀. 삼

이제 서버가 성공적으로 실행되고 있습니다(그림 3). 이제 웹 브라우저를 사용하여 IP 주소로 서버에 접속하고 index.html 웹 페이지를 로드할 수 있습니다. 여기서 웹 브라우저는 클라이언트 스크립트 코드(script.js 및 webrtc.io.js 스크립트 코드)를 추출합니다. 그들을 실행하십시오. P2P 비디오 채팅을 작동하려면(두 브라우저 사이에 연결을 설정하기 위해) webrtc를 지원하는 두 브라우저에서 node.js에서 실행되는 시그널 서버에 접속해야 합니다.

결과적으로 통신 애플리케이션(영상 채팅)의 클라이언트 부분 인터페이스가 카메라 및 마이크에 대한 액세스 권한 요청과 함께 열립니다(그림 4).

쌀. 4

"허용" 버튼을 클릭하면 멀티미디어 통신을 위해 카메라와 마이크가 연결됩니다. 또한 영상채팅 인터페이스를 통해 텍스트 데이터로 소통할 수 있다(그림 5).

쌀. 5

주목해야합니다. 서버는 신호 서버이며 주로 사용자 브라우저 간의 연결을 설정하도록 설계되었습니다. Node.js는 WebRTC 신호를 제공하는 server.js 서버 스크립트를 작동하는 데 사용됩니다.