브라우저에서 호출을 수행하는 기술은 Java, ActiveX, Adobe Flash 등 수년 동안 사용되어 왔습니다. 지난 몇 년 동안 플러그인과 왼손잡이용 가상 머신이 편리하게 빛나지 않는다는 것이 분명해졌습니다. 무엇이든 설치하시겠습니까?) 그리고 가장 중요한 것은 보안입니다. 무엇을 해야 할까요? 출구가 있습니다!
최근까지 IP 네트워크는 IP 전화 통신 또는 비디오에 여러 프로토콜을 사용했습니다. 가장 일반적인 프로토콜인 SIP, H.323 및 MGCP, Jabber/Jingle(Gtalk에서 사용됨), 반 개방형 Adobe RTMP* 및 물론 , Skype를 종료했습니다. Google이 시작한 WebRTC 프로젝트는 Skype를 포함한 모든 소프트폰을 불필요하게 만들어 IP 및 웹 전화 통신의 세계에 혁명을 일으키려고 노력하고 있습니다. WebRTC는 현재 거의 모든 기기에 설치되어 있는 브라우저 내에서 모든 통신 기능을 직접 구현할 뿐만 아니라, 브라우저 사용자 간 통신의 보다 일반적인 문제(다양한 데이터 교환, 화면 브로드캐스팅, 문서와의 협업, 훨씬 더).
웹 개발자의 관점에서 본 WebRTC웹 개발자의 관점에서 WebRTC는 두 가지 주요 부분으로 구성됩니다.
- 로컬 리소스(카메라, 마이크 또는 로컬 컴퓨터 화면)의 미디어 스트림 관리는 MediaStream 개체를 반환하는 navigator.getUserMedia 메서드에 의해 구현됩니다.
- 통신 방법 정의 및 직접 전송을 포함하여 미디어 스트림을 생성하는 장치 간의 P2P 통신 - RTCPeerConnection 객체(오디오 및 비디오 스트림 전송 및 수신용) 및 RTCDataChannel(브라우저에서 데이터 전송 및 수신용).
웹 소켓을 사용하여 WebRTC 기반 브라우저 간에 간단한 다중 사용자 영상 채팅을 구성하는 방법을 알아 보겠습니다. WebRTC 측면에서 가장 진보된 브라우저인 Chrome/Chromium에서 실험을 시작할 것입니다. 하지만 6월 24일에 출시된 Firefox 22가 이를 거의 따라잡았습니다. 표준은 아직 채택되지 않았으며 API는 버전마다 변경될 수 있습니다. 모든 예제는 Chromium 28에서 테스트되었습니다. 단순화를 위해 코드의 정확성과 브라우저 간 호환성을 모니터링하지 않습니다.
미디어스트림첫 번째이자 가장 간단한 WebRTC 구성 요소는 MediaStream입니다. 이를 통해 브라우저는 로컬 컴퓨터의 카메라 및 마이크에서 미디어 스트림에 액세스할 수 있습니다. Chrome에서는 이를 위해 navigator.webkitGetUserMedia() 함수를 호출해야 합니다(표준이 아직 확정되지 않았기 때문에 모든 함수에는 접두사가 있고 Firefox에서는 동일한 함수가 navigator.mozGetUserMedia()라고 함). 호출하면 사용자에게 카메라와 마이크에 대한 액세스를 허용하라는 메시지가 표시됩니다. 사용자가 동의한 후에만 통화를 계속할 수 있습니다. 필요한 미디어 스트림의 매개변수와 두 개의 콜백 함수가 이 함수에 매개변수로 전달됩니다. 첫 번째는 카메라/마이크에 대한 액세스가 성공적으로 획득되면 호출되고 두 번째는 오류가 발생하는 경우 호출됩니다. 먼저 버튼과 요소가 포함된 HTML 파일 rtctest1.html을 만들어 보겠습니다.
WebRTC - 첫 번째 소개 영상( 높이: 240px; 너비: 320px; 테두리: 1px 단색 회색; ) getUserMedia
CU-RTC-Web(html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web.html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web. htm). 이미 적은 IE의 점유율은 계속 감소하고 있지만 Skype 사용자 수는 Microsoft가 Google을 대체할 수 있다는 희망을 주고 있으며 이 표준이 Skype의 브라우저 버전에서 사용될 것이라고 추측할 수 있습니다. Google 표준은 주로 브라우저 간의 통신에 중점을 두고 있습니다. 동시에, 음성 트래픽의 대부분은 여전히 일반 전화 네트워크에 남아 있으며, IP 네트워크와 IP 네트워크 사이의 게이트웨이는 사용 편의성이나 빠른 배포뿐만 아니라 더 많은 플레이어가 사용할 수 있는 수익 창출 수단으로도 필요합니다. 그들을 개발하십시오. 또 다른 표준의 출현은 개발자가 두 가지 호환되지 않는 기술을 동시에 지원해야 하는 불쾌한 필요성을 야기할 뿐만 아니라 향후 사용자에게 가능한 기능과 사용 가능한 기술 솔루션에 대한 더 넓은 선택권을 제공할 수도 있습니다. 기다려 보세요.
로컬 스트림 활성화HTML 파일의 태그 내에서 미디어 스트림에 대한 전역 변수를 선언해 보겠습니다.
Var localStream = null;
getUserMedia 메소드의 첫 번째 매개변수는 요청된 미디어 스트림의 매개변수를 지정해야 합니다. 예를 들어 간단히 오디오 또는 비디오를 활성화하면 됩니다.
Var streamConstraints = ("audio": true, "video": true); // 오디오와 비디오 모두에 대한 액세스를 요청합니다.
또는 추가 매개변수를 지정합니다.
Var streamConstraints = ( "audio": true, "video": ( "필수": ( "maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5"), "선택 사항": ) );
getUserMedia 메소드에 대한 두 번째 매개변수는 콜백 함수에 전달되어야 하며, 콜백 함수는 성공할 경우 호출됩니다.
Function getUserMedia_success(stream) ( console.log("getUserMedia_success():", stream); localVideo1.src = URL.createObjectURL(stream); // 미디어 스트림을 HTML 요소 localStream = stream; // 연결하고 저장합니다. 추가 사용을 위해 전역 변수에)
세 번째 매개변수는 오류 발생 시 호출되는 오류 핸들러인 콜백 함수입니다.
함수 getUserMedia_error(error) ( console.log("getUserMedia_error():", error); )
getUserMedia 메소드에 대한 실제 호출은 첫 번째 버튼을 눌렀을 때 마이크 및 카메라에 대한 액세스를 요청하는 것입니다.
함수 getUserMedia_click() ( console.log("getUserMedia_click()"); navigator.webkitGetUserMedia(streamConstraints, getUserMedia_success, getUserMedia_error); )
로컬로 열린 파일에서는 미디어 스트림에 액세스할 수 없습니다. 이 작업을 시도하면 다음과 같은 오류가 발생합니다.
NavigatorUserMediaError(코드: 1, PERMISSION_DENIED: 1)"
결과 파일을 서버에 업로드하고, 브라우저에서 열고, 나타나는 요청에 응답하여 카메라와 마이크에 대한 액세스를 허용해 보겠습니다.
설정, 고급 설정 링크 표시, 개인정보 보호 섹션, 콘텐츠 버튼에서 Chrome이 액세스할 수 있는 기기를 선택할 수 있습니다. Firefox 및 Opera 브라우저에서는 액세스가 허용되면 드롭다운 목록에서 장치가 직접 선택됩니다.
HTTP 프로토콜을 사용하는 경우 페이지가 로드된 후 미디어 스트림에 액세스할 때마다 권한이 요청됩니다. HTTPS로 전환하면 미디어 스트림에 처음 액세스할 때만 요청을 한 번 표시할 수 있습니다.
북마크 아이콘의 진동하는 원과 주소 표시줄 오른쪽의 카메라 아이콘을 확인하세요.
RTCMediaConnectionRTCMediaConnection은 참가자 간 네트워크를 통해 미디어 스트림을 설정하고 전송하도록 설계된 개체입니다. 또한 이 개체는 미디어 세션 설명(SDP) 생성, NAT 또는 방화벽(로컬 및 STUN 사용) 통과를 위한 ICE 후보에 대한 정보 획득 및 TURN 서버와의 상호 작용을 담당합니다. 각 참가자는 연결당 하나의 RTCMediaConnection을 가져야 합니다. 미디어 스트림은 암호화된 SRTP 프로토콜을 사용하여 전송됩니다.
턴 서버ICE 후보에는 호스트, srflx 및 릴레이의 세 가지 유형이 있습니다. 호스트에는 로컬로 수신된 정보, srflx(노드가 외부 서버(STUN)에 어떻게 보이는지) 및 릴레이(TURN 서버를 통한 트래픽 프록시에 대한 정보)가 포함되어 있습니다. 노드가 NAT 뒤에 있는 경우 호스트 후보는 로컬 주소를 포함하므로 쓸모가 없습니다. srflx 후보는 특정 유형의 NAT에만 도움이 되며 릴레이는 중간 서버를 통해 트래픽을 전달하는 마지막 희망이 됩니다.
주소가 192.168.1.37이고 포트가 udp/34022인 호스트 유형의 ICE 후보의 예:
A=후보:337499441 2 udp 2113937151 192.168.1.37 34022 일반 호스트 세대 0
STUN/TURN 서버를 지정하기 위한 일반 형식:
Var 서버 = ( "iceServers": [ ( "url": "stun:stun.stunprotocol.org:3478" ), ( "url": "turn:user@host:port", "credential": "password" ) ]);
인터넷에는 공개 STUN 서버가 많이 있습니다. 예를 들어, 큰 목록이 있습니다. 불행하게도 그들은 너무 적은 문제를 해결합니다. STUN과 달리 공개 TURN 서버는 사실상 없습니다. 이는 TURN 서버가 미디어 스트림을 통과하여 네트워크 채널과 서버 자체를 모두 크게 로드할 수 있기 때문입니다. 따라서 TURN 서버에 연결하는 가장 쉬운 방법은 직접 설치하는 것입니다(물론 공용 IP가 필요합니다). 제 생각에는 모든 서버 중에서 가장 좋은 것은 rfc5766-turn-server입니다. Amazon EC2용으로 미리 만들어진 이미지도 있습니다.
TURN을 사용하면 모든 것이 원하는 만큼 좋지는 않지만 활발한 개발이 진행 중입니다. NAT(주소 변환) 및 방화벽을 통한 통과 품질 측면에서 WebRTC가 Skype와 동등하지는 않더라도 시간이 좀 지나면 좋겠습니다. , 적어도 눈에 띄게 가까워질 것입니다.
RTCMediaConnection은 연결을 설정하기 위해 제어 정보를 교환하기 위한 추가 메커니즘이 필요합니다. 비록 이 데이터를 생성하지만 전송하지는 않으며 다른 참가자에 대한 전송은 별도로 구현해야 합니다.
전송 방법의 선택은 적어도 수동으로 개발자에게 달려 있습니다. 필요한 데이터가 교환되는 즉시 RTCMediaConnection은 미디어 스트림을 자동으로 설치합니다(물론 가능하다면).
제안-응답 모델미디어 스트림을 설정하고 변경하기 위해 제안/응답 모델(RFC3264에 설명됨)과 SDP(Session Description Protocol)가 사용됩니다. SIP 프로토콜에서도 사용됩니다. 이 모델에는 두 가지 에이전트가 있습니다. Offerer - 새 세션을 생성하거나 기존 세션을 수정하기 위해 세션에 대한 SDP 설명을 생성하는 사람(Offer SDP)과 Answerer - 세션에 대한 SDP 설명을 수신하는 사람 다른 에이전트가 자신의 세션 설명(Answer SDP)으로 응답합니다. 동시에 사양에는 에이전트 간 SDP 전송을 담당하는 더 높은 수준의 프로토콜(예: SIP 또는 우리의 경우 웹 소켓을 통한 자체 프로토콜)이 필요합니다.
미디어 스트림을 성공적으로 설정할 수 있도록 두 RTCMediaConnections 간에 어떤 데이터를 전달해야 합니까?
- 연결을 시작하는 첫 번째 참가자는 전송을 시작하려는 미디어 스트림의 가능한 특성을 설명하는 SDP 데이터 구조(SIP에서 동일한 목적으로 동일한 프로토콜이 사용됨)를 전송하는 제안을 형성합니다. 이 데이터 블록은 두 번째 참가자에게 전송되어야 합니다. 두 번째 참가자는 SDP로 답변을 구성하여 첫 번째 참가자에게 보냅니다.
- 첫 번째 참가자와 두 번째 참가자 모두 두 번째 참가자가 미디어 스트림을 전송할 수 있는 도움을 받아 가능한 ICE 후보를 결정하는 절차를 수행합니다. 후보자가 식별되면 해당 후보자에 대한 정보를 다른 참가자에게 전달해야 합니다.
형성 제안 제안을 생성하려면 두 가지 기능이 필요합니다. 첫 번째 항목은 성공적으로 형성되면 호출됩니다. createOffer() 메소드의 두 번째 매개변수는 실행 중 오류가 발생할 경우 호출되는 콜백 함수입니다(로컬 스레드가 이미 사용 가능한 경우).
또한 두 개의 이벤트 핸들러가 필요합니다. 새로운 ICE 후보를 정의할 때는 onicecandidate, 반대편에서 미디어 스트림을 연결할 때는 onaddstream이 필요합니다. 파일로 돌아가 보겠습니다. 요소가 있는 줄 뒤에 HTML에 또 하나를 추가해 보겠습니다.
제안 생성
그리고 해당 요소가 있는 줄 다음에(미래를 위해):
또한 JavaScript 코드 시작 부분에서 RTCPeerConnection에 대한 전역 변수를 선언합니다.
Var pc1;
RTCPeerConnection 생성자를 호출할 때 STUN/TURN 서버를 지정해야 합니다. 이에 대한 자세한 내용은 사이드바를 참조하세요. 모든 참가자가 동일한 네트워크에 있는 한 필수는 아닙니다.
Var 서버 = null;
제안 SDP 준비를 위한 매개변수
Var OfferConstraints = ();
createOffer() 메소드의 첫 번째 매개변수는 Offer가 성공적으로 형성되었을 때 호출되는 콜백 함수입니다.
Function pc1_createOffer_success(desc) ( console.log("pc1_createOffer_success(): \ndesc.sdp:\n"+desc.sdp+"desc:", desc); pc1.setLocalDescription(desc); // Offer SDP에서 생성된 RTCPeerConnection 설정 // 상대방이 Answer SDP를 보내면 setRemoteDescription 메소드를 사용하여 설정해야 합니다. // 두 번째 측면이 구현될 때까지 아무 작업도 수행하지 않습니다. // pc2_receivedOffer(desc);
두 번째 매개변수는 오류 발생 시 호출되는 콜백 함수입니다.
함수 pc1_createOffer_error(error)( console.log("pc1_createOffer_success_error(): error:", error); )
그리고 ICE 후보가 결정되면 전달될 콜백 함수를 선언해 보겠습니다.
함수 pc1_onicecandidate(event)( if (event.candidate) ( console.log("pc1_onicecandidate():\n"+ event.candidate.candidate.replace("\r\n", ""), event.candidate); // 두 번째 측면이 구현될 때까지 아무것도 하지 않습니다. // pc2.addIceCandidate(new RTCIceCandidate(event.candidate) ) )
또한 먼 쪽에서 미디어 스트림을 추가하기 위한 콜백 함수도 있습니다(현재로서는 RTCPeerConnection이 하나만 있기 때문에 미래를 위해).
함수 pc1_onaddstream(event) ( console.log("pc_onaddstream()"); remoteVideo1.src = URL.createObjectURL(event.stream); )
“createOffer” 버튼을 클릭하면 RTCPeerConnection을 생성하고 onicecandidate 및 onaddstream 메소드를 설정하며 createOffer() 메소드를 호출하여 Offer SDP 형성을 요청합니다.
Function createOffer_click() ( console.log("createOffer_click()"); pc1 = new webkitRTCPeerConnection(servers); // RTCPeerConnection 생성 pc1.onicecandidate = pc1_onicecandidate; // ICE 후보 처리를 위한 콜백 함수 pc1.onaddstream = pc1_onaddstream; // 반대편에서 미디어 스트림이 나타날 때 호출되는 콜백 함수입니다. 아직 아무것도 없습니다. pc1.addStream(localStream); // 로컬 미디어 스트림을 전송합니다(이미 수신했다고 가정). pc1.createOffer(// 실제로는 제안 pc1_createOffer_success , pc1_createOffer_error, OfferConstraints 형성 요청)
파일을 rtctest2.html로 저장하고, 서버에 업로드하고, 브라우저에서 열고, 작업 중에 어떤 데이터가 생성되는지 콘솔에서 확인해 보겠습니다. 참가자가 한 명뿐이므로 두 번째 영상은 아직 나타나지 않습니다. SDP는 미디어 세션의 매개변수에 대한 설명이며 사용 가능한 코덱, 미디어 스트림 및 ICE 후보는 특정 참가자에 연결하기 위한 가능한 옵션이라는 점을 기억해 보십시오.
Answer SDP 구성 및 ICE 후보자 교류Offer SDP와 각 ICE 후보는 모두 상대방으로 전송되어야 하며, 이를 수신한 후 RTCPeerConnection은 Offer SDP에 대한 setRemoteDescription 메소드를 호출하고 반대편에서 수신된 각 ICE 후보에 대해 addIceCandidate를 호출합니다. Answer SDP 및 원격 ICE 후보의 경우에도 마찬가지로 반대 방향입니다. Answer SDP 자체는 제안과 유사하게 구성됩니다. 차이점은 createOffer 메소드가 호출되는 것이 아니라 createAnswer 메소드가 호출되고 그 전에 RTCPeerConnection 메소드 setRemoteDescription이 호출자로부터 수신된 Offer SDP로 전달된다는 것입니다.
HTML에 다른 비디오 요소를 추가해 보겠습니다.
그리고 첫 번째 선언 아래 두 번째 RTCPeerConnection에 대한 전역 변수는 다음과 같습니다.
Var pc2;
제안 및 답변 처리 SDPAnswer SDP의 구성은 Offer와 매우 유사합니다. Offer와 유사하게 Answer가 성공적으로 형성되면 호출되는 콜백 함수에서 로컬 설명을 제공하고 수신된 Answer SDP를 첫 번째 참가자에게 전달합니다.
기능 pc2_createAnswer_success(desc) ( pc2.setLocalDescription(desc); console.log("pc2_createAnswer_success()", desc.sdp); pc1.setRemoteDescription(desc); )
Answer를 생성할 때 오류가 발생한 경우 호출되는 콜백 함수는 Offer와 완전히 유사합니다.
함수 pc2_createAnswer_error(error) ( console.log("pc2_createAnswer_error():", error); )
Answer SDP를 형성하기 위한 매개변수:
Var AnswerConstraints = ( "필수": ( "OfferToReceiveAudio":true, "OfferToReceiveVideo":true ) );
두 번째 참가자가 제안을 받으면 RTCPeerConnection을 생성하고 제안과 동일한 방식으로 답변을 구성합니다.
Function pc2_receivedOffer(desc) ( console.log("pc2_receiveOffer()", desc); // 첫 번째 참가자와 동일한 방법으로 두 번째 참가자에 대한 RTCPeerConnection 개체를 생성합니다. pc2 = new webkitRTCPeerConnection(servers); pc2.onicecandidate = pc2_onicecandidate ; // ICE 후보가 나타나면 이벤트 핸들러를 설정합니다. pc2.onaddstream = pc_onaddstream; // 스트림이 나타나면 HTML에 연결합니다. pc2.addStream(localStream) // 로컬 미디어 스트림을 전송합니다(이 예에서는 두 번째). 참가자는 첫 번째와 동일합니다.) // 이제 두 번째 RTCPeerConnection이 준비되면 수신된 Offer SDP를 전달합니다. (로컬 스트림을 첫 번째 스트림에 전달했습니다.) pc2.setRemoteDescription(new RTCSessionDescription(desc)); // 응답 메시지에 대한 데이터를 생성하기 위해 두 번째 연결을 요청합니다. pc2.createAnswer(pc2_createAnswer_success, pc2_createAnswer_error, AnswerConstraints);
이 예에서는 Offer SDP를 첫 번째 참가자에서 두 번째 참가자로 전송하기 위해 pc1 함수에서 주석 처리를 제거하겠습니다. 제안 생성성공() 호출 라인:
Pc2_receivedOffer(desc);
ICE 후보 처리를 구현하려면 첫 번째 참가자 pc1_onicecandidate()의 ICE 후보 준비 이벤트 핸들러에서 두 번째 참가자로의 전송을 주석 해제해 보겠습니다.
Pc2.addIceCandidate(new RTCIceCandidate(event.candidate));
두 번째 참가자의 ICE 후보 준비 이벤트 핸들러는 첫 번째 참가자와 유사합니다.
함수 pc2_onicecandidate(event) ( if (event.candidate) ( console.log("pc2_onicecandidate():", event.candidate.candidate); pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )
첫 번째 참가자의 미디어 스트림을 추가하기 위한 콜백 함수:
함수 pc2_onaddstream(event) ( console.log("pc_onaddstream()"); remoteVideo2.src = URL.createObjectURL(event.stream); )
연결 종료HTML에 다른 버튼을 추가해 보겠습니다.
전화 끊기
그리고 연결을 종료하는 기능
함수 btnHangupClick() ( // HTML 요소에서 로컬 비디오 연결을 끊고 로컬 미디어 스트림을 중지하고 set = null localVideo1.src = ""; localStream.stop(); localStream = null; // 각 참가자에 대해 HTML에서 비디오를 비활성화합니다. 요소, 연결을 닫고 포인터를 설정합니다. = null remoteVideo1.src = "" pc1 = null;
rtctest3.html로 저장하고 서버에 업로드한 후 브라우저에서 열어보겠습니다. 이 예는 동일한 브라우저 탭 내의 두 RTCPeerConnections 간에 미디어 스트림의 양방향 전송을 구현합니다. 네트워크를 통해 참가자 간 Offer and Answer SDP, ICE 후보 및 기타 정보의 교환을 구성하려면 절차를 직접 호출하는 대신 일종의 전송(이 경우 웹 소켓)을 사용하여 참가자 간 교환을 구현해야 합니다.
화면방송getUserMedia 함수는 다음 매개변수를 지정하여 화면을 캡처하고 MediaStream으로 스트리밍할 수도 있습니다.
Var mediaStreamConstraints = ( audio: false, video: ( 필수: ( chromeMediaSource: "screen"), 선택 사항: ) );
화면에 성공적으로 액세스하려면 다음과 같은 몇 가지 조건을 충족해야 합니다.
- chrome://flags/,chrome://flags/의 getUserMedia()에서 스크린샷 플래그를 활성화합니다.
- 소스 파일은 HTTPS(SSL 원본)를 통해 다운로드되어야 합니다.
- 오디오 스트림을 요청하면 안 됩니다.
- 하나의 브라우저 탭에서 여러 요청을 실행하면 안 됩니다.
WebRTC는 아직 완성되지 않았지만 이를 기반으로 하는 여러 라이브러리가 이미 등장했습니다. JsSIP는 Asterisk 및 Camalio와 같은 SIP 스위치와 작동하는 브라우저 기반 소프트폰을 만들도록 설계되었습니다. PeerJS를 사용하면 데이터 교환을 위한 P2P 네트워크를 더 쉽게 만들 수 있으며 Holla는 브라우저에서 P2P 통신에 필요한 개발 양을 줄일 것입니다.
Node.js와 소켓.io네트워크를 통해 두 RTCPeerConnections 간의 SDP 및 ICE 후보 교환을 구성하기 위해 우리는 node.js와 node.js를 node.io 모듈과 함께 사용합니다.
최신 안정 버전의 Node.js(Debian/Ubuntu용) 설치에 대해 설명합니다.
$ sudo apt-get python-software-properties python g++ make $ sudo add-apt-repository ppa:chris-lea/node.js $ sudo apt-get update $ sudo apt-get install nodejs
다른 운영 체제에 대한 설치가 설명되어 있습니다.
점검 해보자:
$ echo "sys=require("util"); sys.puts("테스트 메시지");" > nodetest1.js $ nodejs nodetest1.js
npm(노드 패키지 관리자)을 사용하여 소켓.io 및 추가 Express 모듈을 설치합니다.
$ npm 설치 소켓.io 익스프레스
서버 측에 대한 nodetest2.js 파일을 생성하여 테스트해 보겠습니다.
$ nano nodetest2.js var app = require("express")() , server = require("http").createServer(app) , io = require("socket.io").listen(server); 서버.듣기(80); // 포트 80이 비어 있는 경우 app.get("/", function (req, res) ( // 루트 페이지에 액세스할 때 res.sendfile(__dirname + "/nodetest2.html"); // HTML 파일 전송 ) ) ; io.sockets.on("connection", function (socket) ( // 연결시 소켓.emit("server event", ( hello: "world" )); // 메시지 전송 소켓.on("client event" , function (data) ( // 클라이언트에서 메시지가 도착하면 이벤트 핸들러를 선언합니다. console.log(data); ));
그리고 클라이언트 측의 경우 nodetest2.html:
$ nano nodetest2.html var 소켓 = io.connect("/"); // Websocket 서버 URL(페이지가 로드된 서버의 루트 페이지) 소켓.on("서버 이벤트", function (data) ( console.log(data); 소켓.emit("클라이언트 이벤트", ( " 이름": "값" )); ));
서버를 시작해보자:
$ sudo nodejs nodetest2.js
브라우저에서 http://localhost:80(포트 80에서 로컬로 실행 중인 경우) 페이지를 엽니다. 모든 것이 성공하면 브라우저의 JavaScript 콘솔에서 연결 시 브라우저와 서버 간의 이벤트 교환을 볼 수 있습니다.
웹 소켓을 통한 RTCPeerConnection 간의 정보 교환 클라이언트 부분주요 예제(rtcdemo3.html)를 새 이름 rtcdemo4.html로 저장해 보겠습니다. 요소에 소켓.io 라이브러리를 포함시켜 보겠습니다.
그리고 JavaScript 스크립트의 시작 부분에서 - 웹소켓에 연결합니다:
Var 소켓 = io.connect("http://localhost");
웹 소켓을 통해 메시지를 보내 다른 참가자의 기능에 대한 직접 호출을 대체해 보겠습니다.
함수 createOffer_success(desc) ( ... // pc2_receivedOffer(desc); 소켓.emit("offer", desc); ... ) 함수 pc2_createAnswer_success(desc) ( ... // pc1.setRemoteDescription(desc); 소켓 .emit("answer", desc); ) function pc1_onicecandidate(event) ( ... // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); 소켓.emit("ice1", event.candidate); .. . ) 함수 pc2_onicecandidate(event) ( ... // pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); 소켓.emit("ice2", event.candidate); ... )
hangup() 함수에서는 두 번째 참가자의 함수를 직접 호출하는 대신 웹 소켓을 통해 메시지를 전송합니다.
함수 btnHangupClick() ( ... // remoteVideo2.src = ""; pc2.close(); pc2 = null; 소켓.emit("hangup", ()); )
그리고 메시지 수신 핸들러를 추가합니다.
Socket.on("offer", function (data) ( console.log("socket.on("offer"):", data); pc2_receivedOffer(data); )); 소켓.on("답변", 함수 (데이터) (е console.log("socket.on("답변"):", data); pc1.setRemoteDescription(new RTCSessionDescription(data)); )); 소켓.on("ice1", function (data) ( console.log("socket.on("ice1"):", data); pc2.addIceCandidate(new RTCIceCandidate(data)); )); 소켓.on("ice2", function (data) ( console.log("socket.on("ice2"):", data); pc1.addIceCandidate(new RTCIceCandidate(data)); )); 소켓.on("hangup", 함수 (데이터) ( console.log("socket.on("hangup"):", data); remoteVideo2.src = ""; pc2.close(); pc2 = null; ) );
서버 부분서버 측에서는 nodetest2 파일을 새 이름 rtctest4.js로 저장하고 io.sockets.on("connection", function (socket) ( ... ) 함수 내부에 클라이언트 메시지 수신 및 전송을 추가합니다.
Socket.on("offer", function (data) ( // "offer" 메시지를 받으면 // 이 예에서는 클라이언트 연결이 하나만 있으므로 // 동일한 소켓을 통해 메시지를 다시 보냅니다. .emit("offer" , data); // 발신자를 제외한 // 모든 연결을 통해 메시지를 전달해야 하는 경우: // soket.broadcast.emit("offer", data )); 소켓.on("답변", 함수 (데이터) ( 소켓.emit("답변", 데이터); )); socket.on("ice1", function (data) (socket.emit("ice1", data); )); socket.on("ice2", function (data) (socket.emit("ice2", data); )); 소켓.on("hangup", function (data) ( 소켓.emit("hangup", data); ));
또한 HTML 파일의 이름을 변경해 보겠습니다.
// res.sendfile(__dirname + "/nodetest2.html"); // HTML 파일 보내기 res.sendfile(__dirname + "/rtctest4.html");
서버 시작:
$ sudo nodejs nodetest2.js
두 클라이언트의 코드가 동일한 브라우저 탭 내에서 실행된다는 사실에도 불구하고 이 예에서 참가자 간의 모든 상호 작용은 완전히 네트워크를 통해 수행되며 참가자를 "분리"하는 데 특별한 어려움이 필요하지 않습니다. 그러나 우리가 한 일은 매우 간단했습니다. 이러한 기술은 사용하기 쉽기 때문에 좋습니다. 때로는 기만적일지라도. 특히 STUN/TURN 서버가 없으면 주소 변환 및 방화벽이 있는 경우 예제가 작동할 수 없다는 점을 잊지 마십시오.
결론결과 예제는 매우 일반적이지만 호출자와 수신자 간에 차이가 없도록 이벤트 핸들러를 약간 보편화하는 경우 두 개체 pc1 및 pc2 대신 RTCPeerConnection 배열을 만들고 요소의 동적 생성 및 제거를 구현합니다. , 그러면 완전히 사용 가능한 영상 채팅을 이용할 수 있습니다. WebRTC와 관련된 특별한 세부 사항은 없으며 여러 참가자를 위한 간단한 영상 채팅의 예(기사에 있는 모든 예의 텍스트도 포함)는 잡지와 함께 제공되는 디스크에 있습니다. 그러나 이미 인터넷에서 좋은 예를 많이 찾을 수 있습니다. 특히 기사를 준비하는 데 simpl.info getUserMedia, simpl.info RTCPeerConnection, WebRTC Reference App이 사용되었습니다.
곧 WebRTC 덕분에 음성 및 영상 통신에 대한 이해뿐만 아니라 인터넷 전체를 인식하는 방식에도 혁명이 일어날 것이라고 가정할 수 있습니다. WebRTC는 브라우저 간 호출 기술뿐만 아니라 실시간 통신 기술로도 자리잡고 있습니다. 우리가 논의한 비디오 통신은 가능한 사용 옵션 중 일부일뿐입니다. 스크린캐스팅과 협업의 예는 이미 있으며 RTCDataChannel을 사용하는 브라우저 기반 P2P 콘텐츠 전달 네트워크도 있습니다.
오늘날 WebRTC는 브라우저에서 오디오 및 비디오 스트리밍을 위한 "인기" 기술입니다. HTTP 스트리밍 및 플래시와 같은 보수적인 기술은 녹화된 콘텐츠(주문형 비디오) 배포에 더 적합하며 실시간 및 온라인 방송 측면에서 WebRTC보다 훨씬 열등합니다. 시청자가 무슨 일이 일어나고 있는지 '실시간'으로 볼 수 있으려면 최소한의 비디오 대기 시간이 필요합니다.
고품질 실시간 통신의 가능성은 UDP 프로토콜을 사용하여 비디오 스트림을 전송하는 WebRTC 아키텍처 자체에서 비롯됩니다. 이는 최소한의 지연으로 비디오를 전송하기 위한 표준 기반이며 실시간 통신 시스템에서 널리 사용됩니다.
통신 대기 시간은 비디오 소스, 최종 사용자와의 대화형 통신이 필요하고 솔루션이 필요한 온라인 방송 시스템, 웹 세미나 및 기타 애플리케이션에서 중요합니다.
WebRTC를 시도하는 또 다른 좋은 이유는 그것이 확실히 추세라는 것입니다. 현재 모든 Android Chrome 브라우저는 이 기술을 지원하므로 추가 소프트웨어나 구성을 설치하지 않고도 수백만 대의 기기에서 방송을 시청할 수 있습니다.
실제 WebRTC 기술을 테스트하고 이에 대한 간단한 온라인 방송을 시작하기 위해 우리는 Flashphoner WebRTC 미디어 및 방송 서버 서버 소프트웨어를 사용했습니다. 이 기능에는 일대다 모드로 WebRTC 스트림을 브로드캐스트하는 기능과 RTSP 프로토콜을 통한 IP 카메라 및 비디오 감시 시스템 지원이 명시되어 있습니다. 이번 리뷰에서는 웹-웹 방송과 그 특징에 중점을 둘 것입니다.
WebRTC 미디어 및 방송 서버 설치Windows 시스템용 서버 버전이 없었고 VMWare+Linux와 같은 가상 머신을 설치하고 싶지 않았기 때문에 집에 있는 Windows 컴퓨터에서 온라인 방송을 테스트할 수 없었습니다. 시간을 절약하기 위해 우리는 다음과 같이 클라우드 호스팅에서 인스턴스를 선택하기로 결정했습니다.
암스테르담 데이터센터에 사전 설치된 소프트웨어가 없는 Centos x86_64 버전 6.5였습니다. 따라서 우리가 사용할 수 있는 것은 서버와 이에 대한 SSH 액세스뿐입니다. Linux 콘솔 명령에 익숙한 사용자라면 WebRTC 서버를 설치하는 것이 간단하고 어려울 것입니다. 그래서 우리가 한 일은:
1. 아카이브를 다운로드합니다:
$wget https://site/download-wcs5-server.tar.gz
2. 포장 풀기:
$tar -xzf 다운로드-wcs5-server.tar.gz
3. 설치:
$cd FlashphonerWebCallServer
설치하는 동안 서버 IP 주소를 입력하세요: XXX.XXX.XXX.XXX
4. 라이센스를 활성화합니다:
$cd /usr/local/FlashphonerWebCallServer/bin
$./activation.sh
5. WCS 서버를 시작합니다:
$service webcall서버 시작
6. 로그를 확인합니다.
$tail - f /usr/local/FlashphonerWebCallServer/logs/flashphoner_manager.log
7. 두 가지 프로세스가 준비되어 있는지 확인합니다.
$ps 보조 | grep 플래쉬폰너
설치 프로세스가 완료되었습니다.
WebRTC 온라인 방송 테스트방송을 테스트하는 것은 간단한 문제로 판명되었습니다. 서버 외에도 12개의 Javascript, HTML 및 CSS 파일로 구성되고 설치 단계에서 /var/www/html 폴더에 배포된 웹 클라이언트가 있습니다. 수행해야 할 유일한 작업은 서버의 IP 주소를 flashphoner.xml 구성에 입력하여 웹 클라이언트가 HTML5 웹소켓을 통해 서버와 연결을 설정할 수 있도록 하는 것이었습니다. 테스트 과정을 설명해보자.
1. Chrome 브라우저에서 index.html 테스트 클라이언트 페이지를 엽니다.
2. 방송을 시작하려면 화면 중앙의 '시작' 버튼을 클릭해야 합니다.
이 작업을 수행하기 전에 웹캠이 연결되어 있고 사용할 준비가 되었는지 확인해야 합니다. 웹캠에 대한 특별한 요구 사항은 없습니다. 예를 들어 우리는 1280x800 해상도의 노트북에 내장된 표준 카메라를 사용했습니다.
Chrome 브라우저는 사용자가 자신의 비디오가 인터넷 서버로 전송되고 이를 허용한다는 것을 이해할 수 있도록 카메라와 마이크에 대한 액세스를 확실히 요청합니다.
3. 인터페이스는 카메라에서 WebRTC 서버로의 비디오 스트림의 성공적인 브로드캐스트를 나타냅니다. 오른쪽 상단 모서리에 있는 표시기는 스트림이 서버로 이동 중임을 나타냅니다. 하단 모서리에는 비디오 전송을 중지하는 "중지" 버튼이 있습니다.
아래 상자의 링크를 참고하세요. 여기에는 이 스트림에 대한 고유 식별자가 포함되어 있어 누구나 시청에 참여할 수 있습니다. 브라우저에서 이 링크를 열어보세요. 클립보드에 복사하려면 “복사” 버튼을 클릭하세요.
웹 세미나, 강의, 온라인 비디오 방송 또는 대화형 TV와 같은 실제 애플리케이션에서 개발자는 원하는 스트림에 연결할 수 있도록 특정 시청자 그룹에 이 식별자 배포를 구현해야 하지만 이는 이미 애플리케이션의 논리입니다. . WebRTC Media & Broadcasting Server는 영향을 미치지 않으며 비디오 배포만 합니다.
5. 연결이 완료되고 시청자는 화면에서 스트림을 봅니다. 이제 그는 오른쪽 하단에 있는 컨트롤을 사용하여 다른 사람에게 링크를 보내거나, 스트림 재생을 중지하거나, 전체 화면 모드를 활성화할 수 있습니다.
테스트하는 동안 대기 시간은 완벽해 보였습니다. 데이터 센터에 대한 핑은 약 100밀리초였으며 지연은 눈에 보이지 않았습니다. 여기에서 실제 지연은 버퍼링 시간에 대해 100 ± 수십 밀리초와 동일하다고 가정할 수 있습니다. Flash 비디오와 비교: 이러한 테스트에서 Flash는 WebRTC만큼 작동하지 않습니다. 그래서 유사한 네트워크에서 손을 움직이면 1~2초 후에야 화면의 움직임을 볼 수 있다.
품질과 관련하여 큐브는 때때로 움직임으로 구별될 수 있습니다. 이는 VP8 코덱의 특성과 주요 목적, 즉 허용 가능한 품질과 통신 지연 없이 실시간 비디오 통신을 제공하는 것과 일치합니다.
서버는 설치 및 구성이 매우 쉽습니다. 서버를 실행하는 데에는 SSH를 통해 콘솔에서 명령을 실행하고 텍스트 편집기를 사용할 수 있는 고급 사용자 수준의 Linux 지식 외에는 심각한 기술이 필요하지 않습니다. 그 결과, 우리는 브라우저 간 일대다 온라인 브로드캐스트를 구축할 수 있었습니다. 추가 시청자를 스트림에 연결해도 문제가 발생하지 않았습니다.
방송 품질은 웨비나 및 온라인 방송에 매우 적합한 것으로 나타났습니다. 몇 가지 의문을 제기한 유일한 것은 비디오 해상도였습니다. 카메라는 1280x800을 지원하지만 테스트 이미지의 해상도는 640x480과 매우 유사합니다. 분명히 이 문제는 개발자와 함께 명확히 해야 합니다.
웹캠에서 브로드캐스트 테스트에 대한 비디오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 install 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 install -g express 방식으로 설치할 수 있습니다.
그런 다음 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 서버 스크립트를 작동하는 데 사용됩니다.
전문. WebRTC 기반의 P2P 영상 채팅은 Skype 및 기타 통신 수단의 대안입니다. WebRTC 기반 P2P 영상채팅의 주요 요소는 브라우저와 연락처 서버입니다. P2P 영상 채팅은 서버가 정보 흐름 전송에 참여하지 않는 P2P 영상 채팅입니다. 추가 프로그램 없이 사용자의 브라우저(피어) 간에 직접 정보가 전송됩니다. 브라우저 외에도 p2p 화상 채팅은 사용자를 등록하고 사용자에 대한 데이터를 저장하며 사용자 간 전환을 보장하도록 설계된 연락처 서버를 사용합니다. 최신 WebRTC 및 HTML5 기술을 지원하는 브라우저는 IP 네트워크를 통한 음성 및 영상 통신뿐만 아니라 인스턴트 문자 메시지 및 파일 전송도 제공합니다.
따라서 웹 인터페이스의 채팅, 웹 채팅, 음성 및 영상 채팅, IMS, VoIP는 복합 패킷 교환 네트워크를 통해 온라인 통신을 제공하는 서비스입니다. 일반적으로 통신 서비스를 이용하려면 사용자 장치(PC, 스마트폰 등)에 클라이언트 애플리케이션을 설치하거나 브라우저에 플러그인 및 확장 프로그램을 설치해야 합니다. 서비스에는 자체 통신 네트워크가 있으며 대부분은 클라이언트-서버 아키텍처를 기반으로 구축됩니다.
통신 서비스는 음성, 영상, 데이터, 문자 채널이 통합되지 않은 IMS 이외의 애플리케이션입니다. 각 서비스의 네트워크에서는 . 이러한 애플리케이션은 여러 통신 네트워크에서 동시에 작동할 수 없습니다. 일반적으로 애플리케이션은 서로 통신할 수 없으므로 각 통신 네트워크마다 별도의 애플리케이션을 설치해야 합니다.
실시간 커뮤니케이션 서비스(채팅, 전화, 화상회의)를 통합하는 문제, 즉 음성, 비디오, 데이터 채널의 통합과 하나의 애플리케이션(브라우저)을 사용한 액세스는 WebRTC 프로토콜을 기반으로 하는 P2P 또는 P2P 비디오 채팅(P2P, 지점 간)으로 해결할 수 있습니다. 기본적으로 WebRTC를 지원하는 브라우저는 통신 서비스를 사용하는 모든 사용자 장치(PC, 스마트폰, iPad, IP 전화, 휴대폰 등)에 대한 단일 인터페이스가 됩니다.
실시간 통신을 제공하는 모든 기술의 브라우저 구현을 보장하는 것은 WebRTC입니다. P2P 영상채팅의 본질은 서버나 추가 프로그램의 참여 없이 멀티미디어와 텍스트 데이터가 사용자의 브라우저 간에 직접 전송(리모트 피어링)된다는 것입니다. 따라서 브라우저는 서버에 저장된 거의 모든 인터넷 정보 자원에 대한 접근을 제공할 뿐만 아니라 모든 실시간 통신 서비스 및 메일 서비스(음성 메일, 이메일, SMS 등)에 대한 접근 수단이 됩니다.
P2P 화상 채팅 서버(연락처 서버)는 사용자 등록, 사용자에 대한 데이터 저장, 사용자 브라우저 간의 연결 설정(전환)만을 위한 것입니다. 최초의 p2p 화상 채팅은 플래시 기술을 사용하여 구현되었습니다. 플래시 P2P 영상 채팅은 예를 들어 소셜 네트워크에서 사용됩니다. 플래시 P2P 화상 채팅은 고품질 멀티미디어 데이터 전송을 제공하지 않습니다. 또한 P2P 플래시 화상 채팅에서 마이크와 비디오 카메라의 음성 및 비디오 스트림을 출력하려면 웹 브라우저에 플래시 플러그인을 설치해야 합니다.
그러나 차세대 통신 서비스에는 WebRTC 프로토콜과 HTML5 사양을 지원하는 브라우저와 연락처 서버만 사용하여 인터넷을 통해 통신하는 웹 통신이 포함됩니다. 이러한 브라우저가 장착된 모든 사용자 장치(PC, iPad, 스마트폰 등)는 고품질 음성 및 영상 통화는 물론 인스턴트 문자 메시지 및 파일 전송을 제공할 수 있습니다.
따라서 웹 통신(p2p 채팅, 영상 채팅)의 새로운 기술은 WebRTC 프로토콜입니다. WebRTC는 HTML5, CSS3 및 JavaScript와 함께 다양한 웹 애플리케이션을 만들 수 있습니다. WebRT는 P2P 아키텍처를 사용하여 실시간으로 웹 통신(P2P 네트워크)을 구성하도록 설계되었습니다. WebRTC 기반의 P2P 채팅은 브라우저에 있는 외부 추가 기능이나 플러그인을 사용하지 않고 웹 브라우저만 사용하여 인터넷을 통해 사용자 간의 텍스트, 음성 및 영상 통신은 물론 파일 전송도 제공합니다.
P2P 채팅에서 서버는 두 브라우저 간의 P2P 연결을 설정하는 데에만 사용됩니다. WebRTC 프로토콜을 기반으로 p2p 채팅의 클라이언트 부분을 생성하려면 HTML5, CSS3 및 JavaScript가 사용됩니다. 클라이언트 애플리케이션은 WebRTC API를 통해 브라우저와 상호 작용합니다.
WebRTC는 세 가지 JavaScript API로 구현됩니다.
- RTCPeerConnection;
- MediaStream(getUserMedia);
- RTCDataChannel.
브라우저는 UDP 위에서 실행되는 SRTP 프로토콜을 사용하여 미디어 데이터를 전송합니다. NAT는 인터넷을 통해 p2p 연결을 사용하는 NAT 라우터 뒤의 브라우저(클라이언트)에 문제를 일으키기 때문에 STUN은 NAT 변환기를 우회하는 데 사용됩니다. STUN은 UDP 전송 프로토콜 위에서 실행되는 클라이언트-서버 프로토콜입니다. P2P 채팅에서는 일반적으로 공개 STUN 서버가 사용되며, 이 서버에서 수신된 정보는 NAT 뒤에 있는 두 브라우저 간의 UDP 연결에 사용됩니다.
WebRTC 애플리케이션 구현의 예(p2p 채팅, 음성 및 영상 웹 채팅):
1. WebRTC 기반의 P2P 영상채팅 Bistri(원클릭 영상채팅, p2p채팅)를 Bistri에서 오픈할 수 있습니다. Bistri는 추가 프로그램과 플러그인을 설치하지 않고도 브라우저에서 작동합니다. 작업의 본질은 다음과 같습니다. 지정된 링크를 사용하여 p2p 영상 채팅을 열고, 열리는 인터페이스에 등록한 후 파트너를 초대한 다음 피어 클라이언트 목록에서 온라인에 있는 파트너를 선택하고 "영상 통화"를 클릭합니다. "버튼.
결과적으로 MediaStream(getUserMedia)은 마이크 + 웹캠을 캡처하고 서버는 선택한 파트너와 신호 메시지를 교환합니다. 신호 메시지를 교환한 후 PeerConnection API는 음성 및 비디오 스트림을 전송하기 위한 채널을 생성합니다. 또한 Bistri는 인스턴트 문자 메시지와 파일을 전송합니다. 그림에서. 그림 1은 Bistri p2p 영상 채팅 인터페이스의 스크린샷을 보여줍니다.
쌀. 1. P2P 영상채팅 비스트리
2. Twelephone(p2p 영상 채팅, p2p 채팅, SIP Twelephone) - 이 클라이언트 애플리케이션은 HTML5 및 WebRTC를 기반으로 구축되어 음성 및 영상 통화는 물론 인스턴트 문자 메시지도 보낼 수 있습니다. Twelephone에는 테스트 p2p 채팅, 비디오 채팅 및 SIP Twelephone이 포함되어 있습니다. Twelephone은 SIP 프로토콜을 지원하므로 이제 Twitter 계정을 전화번호로 사용하여 SIP 전화에서 음성 및 영상 통화를 걸고 받을 수 있습니다. 또한 마이크를 통해 음성으로 문자 메시지를 입력할 수 있으며, 음성 인식 프로그램은 '메시지 보내기' 줄에 문자를 입력한다.
Twelephone은 버전 25부터 별도의 소프트웨어 없이 Google Chrome 브라우저를 기반으로 작동하는 웹 전화입니다. Twelephone은 Chris Matthieu가 개발했습니다. Twelephone 백엔드는 Node.js를 기반으로 구축되었습니다. 서버(연락처 서버)는 두 브라우저 또는 WebRTC 클라이언트 간에 p2p 연결을 설정하는 데에만 사용됩니다. Twelephone 애플리케이션에는 자체 인증 도구가 없지만 Twitter 계정에 연결하는 데 중점을 둡니다.
그림에서. 그림 2는 Twelephone p2p 영상 채팅 인터페이스의 스크린샷을 보여줍니다.
쌀. 2. P2P 텔레폰
3. 그룹 p2p 영상 채팅 Conversat.io는 최신 WebRTC 및 HTML5 기술을 기반으로 구축되었습니다. Conversat 비디오 채팅은 SimpleWebRTC 라이브러리를 기반으로 개발되었으며 한 방에서 최대 6명의 피어 클라이언트 간의 통신을 위해 고안되었습니다(통신을 위해 "대화 이름 지정" 줄에 피어 클라이언트의 휴게실 이름을 표시). P2P 영상채팅 Conversat은 컨택서버에 등록하지 않고도 사용자에게 커뮤니케이션 서비스를 제공합니다. 그림에서. 그림 3은 Conversat p2p 영상 채팅 인터페이스의 스크린샷을 보여줍니다.
쌀. 3. 그룹 P2P 화상 채팅 Conversat.io
WebRTC 기반 P2P 영상 채팅에 참여하려면 사용자는 WebRTC 프로토콜과 HTML5 사양을 지원하는 브라우저가 설치되어 있어야 합니다. 현재 버전 25 이상의 Google Chrome 브라우저와 Mozilla Firefox Nightly는 WebRTC 프로토콜과 HTML5 사양을 지원합니다. WebRTC 애플리케이션은 이미지 및 사운드 전송 품질 측면에서 Flash 애플리케이션보다 우수합니다.
WebRTC(웹 실시간 통신)는 웹 애플리케이션과 사이트가 오디오 및/또는 비디오 미디어 스트림을 캡처하고 선택적으로 전송할 수 있을 뿐만 아니라 중개자를 반드시 사용하지 않고도 브라우저 간에 임의의 데이터를 교환할 수 있도록 하는 기술입니다. WebRTC 기술에 포함된 일련의 표준을 사용하면 사용자가 플러그인이나 기타 타사 소프트웨어를 설치할 필요 없이 데이터를 교환하고 P2P 원격 회의를 수행할 수 있습니다.
WebRTC는 상호 연결된 여러 API(애플리케이션 프로그래밍 인터페이스)와 함께 작동하는 프로토콜로 구성됩니다. 여기에서 찾을 수 있는 문서는 WebRTC의 기본 사항, 데이터 및 미디어 스트리밍을 위한 연결을 설정하고 사용하는 방법 등을 이해하는 데 도움이 됩니다.
호환성WebRTC 구현은 아직 초기 단계이고 모든 브라우저에는 WebRTC 기능이 있으므로 코드 작업을 시작하기 전에 Google의 Adapter.js 폴리필 라이브러리를 사용하는 것이 좋습니다.
Adapter.js는 웨지와 폴리필을 사용하여 이를 지원하는 컨텍스트 간 WebRTC 구현의 차이점을 원활하게 연결합니다. Adapter.js는 또한 공급업체 접두사 및 기타 속성 이름 지정 차이를 처리하므로 가장 호환 가능한 결과로 WebRTC에서 개발하기가 더 쉬워집니다. 라이브러리는 NPM 패키지로도 제공됩니다.
Adapter.js 라이브러리를 더 자세히 살펴보려면 살펴보세요.
WebRTC 개념 및 사용법WebRTC는 다목적이며 와 함께 오디오 및 비디오 회의, 파일 공유, 화면 캡처, ID 관리 및 DTMF 톤 다이얼링 지원을 포함하여 기존 전화 시스템과의 상호 운용성을 지원하는 등 강력한 웹용 멀티미디어 기능을 제공합니다. 노드 간 연결은 특별한 드라이버나 플러그인을 사용하지 않고, 중간 서비스 없이도 생성될 수 있습니다.
두 노드 사이의 연결은 RTCPeerConnection 인터페이스 객체로 표현됩니다. 연결이 설정되고 열리면 RTCPeerConnection 개체를 사용하여 미디어 스트림(MediaStreams) 및/또는 데이터 채널(RTCDataChannels)을 연결에 추가할 수 있습니다.
미디어 스트림은 미디어 정보의 트랙(트랙) 수에 제한 없이 구성될 수 있습니다. 이러한 트랙은 MediaStreamTrack 인터페이스 개체로 표시되며 오디오, 비디오, 텍스트(예: 자막 또는 장 제목)를 포함하여 하나 이상의 미디어 데이터 유형을 포함할 수 있습니다. 대부분의 스트림은 최소한 하나의 오디오 트랙(오디오 트랙 1개) 또는 비디오 트랙으로만 구성되며 스트림(실시간 미디어)으로 보내고 받거나 파일에 저장할 수 있습니다.
또한 서비스 정보, 주식 시장 데이터, 게임 상태 패키지, 파일 전송 또는 개인 데이터 채널을 전송하는 데 사용할 수 있는 RTCDataChannel 인터페이스 개체를 사용하여 임의의 데이터를 교환하기 위해 두 노드 간의 연결을 사용할 수도 있습니다.
필요한 관련 가이드 및 튜토리얼에 대한 자세한 내용과 링크
WebRTC 인터페이스WebRTC는 서로 다른 작업을 수행하기 위해 함께 작동하는 인터페이스를 제공하기 때문에 이를 여러 범주로 나누었습니다. 빠른 탐색을 위해 사이드바 색인을 참조하세요.
연결 설정 및 관리이러한 인터페이스는 WebRTC 연결을 구성, 열기 및 관리하는 데 사용됩니다. 이는 양방향 멀티미디어 연결을 설정하기 위한 최상의 구성을 선택하기 위해 각 노드의 기능에 대한 정보를 교환하는 데 사용되는 단일 계층 미디어 연결, 데이터 채널 및 인터페이스를 나타냅니다.
RTCPeerConnection 로컬 컴퓨터와 원격 노드 간의 WebRTC 연결을 나타냅니다. 두 노드 간의 성공적인 데이터 전송을 처리하는 데 사용됩니다. RTCSessionDescription 세션 매개변수를 나타냅니다. 각 RTCSessionDescription에는 설명하는 협상 프로세스의 부분(제안/응답)을 나타내는 유형 설명과 세션에 대한 SDP 설명자가 포함되어 있습니다. RTCIceCandidate는 RTCPeerConnection 연결을 설정하기 위한 ICE(인터넷 연결 설정) 서버 후보를 나타냅니다. RTCIceTransport는 ICE(인터넷 연결 기능) 정보를 나타냅니다. RTCPeerConnectionIceEvent ICE 후보에서 발생하는 이벤트(일반적으로 RTCPeerConnection )를 나타냅니다. 이 이벤트 개체에는 icecandidate라는 한 가지 유형이 전달됩니다. RTCRtpSender 유형 RTCPeerConnection 개체에 대해 MediaStreamTrack 유형 개체를 통해 데이터 스트리밍 및 전송을 제어합니다. RTCRtpReceiver RTCPeerConnection 유형의 객체에 대해 MediaStreamTrack 유형의 객체를 통해 데이터 수신 및 디코딩을 제어합니다. RTCTrackEvent 새로 들어오는 MediaStreamTrack 객체가 생성되었고 RTCRtpReceiver 객체가 RTCPeerConnection 객체에 추가되었음을 나타냅니다. RTCCertificate RTCPeerConnection 객체를 사용하는 인증서를 나타냅니다. RTCDataChannel 두 연결 노드 사이의 양방향 데이터 채널을 나타냅니다. RTCDataChannelEvent RTCDataChannel 유형의 객체가 RTCPeerConnection datachannel 유형의 객체에 연결될 때 발생하는 이벤트를 나타냅니다. RTCDTMFSender RTCPeerConnection 유형의 객체에 대한 DTMF(Dual-Tone Multi-Frequency) 신호의 인코딩 및 전송을 제어합니다. RTCDTMFToneChangeEvent 수신 DTMF(Dual Tone Multi Frequency) 톤 변경 이벤트를 나타냅니다. 이 이벤트는 (달리 지정하지 않는 한) 버블링되지 않으며 (달리 지정하지 않는 한) 취소할 수 없습니다. RTCStatsReport 전달된 MediaStreamTrack 개체의 상태를 비동기적으로 보고합니다. RTCIdentityProviderRegistrar ID 공급자(idP)를 등록합니다. RTCIdentityProvider 신원 선언의 생성 또는 확인을 요청하는 브라우저의 기능을 활성화합니다. RTCIdentityAssertion 현재 연결의 원격 노드 식별자를 나타냅니다. 노드가 아직 설치 및 확인되지 않은 경우 인터페이스 참조는 null 을 반환합니다. 설치 후에도 변경되지 않습니다. RTCIdentityEvent ID 공급자(idP) 선언 이벤트 개체를 나타냅니다. RTCPeerConnection 유형의 객체 이벤트입니다. 이 IDResult 이벤트에는 한 가지 유형이 전달됩니다. RTCIdentityErrorEvent ID 공급자(idP)와 연결된 오류 이벤트 개체를 나타냅니다. RTCPeerConnection 유형의 객체 이벤트입니다. 이 이벤트에는 idpassertionerror 및 idpvalidationerror라는 두 가지 유형의 오류가 전달됩니다. 가이드 WebRTC 아키텍처 개요 개발자가 WebRTC를 생성하고 사용하는 데 사용하는 API 아래에는 일련의 네트워크 프로토콜 및 연결 표준이 있습니다. 이 검토는 이러한 표준을 보여주는 것입니다. WebRTC를 사용하면 노드 간 모드로 연결을 구성하여 브라우저에서 임의의 데이터, 오디오, 비디오 스트림 또는 이들의 조합을 전송할 수 있습니다. 이 기사에서는 연결 설정부터 시작하여 더 이상 필요하지 않을 때 종료될 때까지 WebRTC 세션의 수명을 살펴보겠습니다. WebRTC API 개요 WebRTC는 두 개 이상의 노드 간 데이터 및 미디어 스트림 교환을 지원하기 위해 함께 작동하는 여러 상호 연관된 API(응용 프로그래밍 인터페이스)와 프로토콜로 구성됩니다. 이 문서에서는 이러한 각 API에 대한 간략한 개요와 해당 API의 용도를 제공합니다. WebRTC 기본 사항 이 문서에서는 크로스 브라우저 RTC 애플리케이션을 만드는 과정을 안내합니다. 이 기사가 끝나면 작동하는 지점 간 데이터 및 미디어 채널을 갖게 됩니다. WebRTC 프로토콜 이 문서에서는 WebRTC API를 보완하는 프로토콜을 소개합니다. 이 가이드에서는 노드 간 연결을 사용하고 연결하는 방법을 설명합니다.