WebRTC 및 웹 소켓 : WebRTC가 비디오, 오디오 및 데이터를 수행 할 수 있다면 왜 웹 소켓이 필요합니까? [닫은]


221

그래서 비디오, 오디오 및 텍스트를 허용하는 채팅 앱을 만들고 싶습니다. 어느 것을 사용할지 결정하기 위해 Websocket과 WebRTC를 조사하는 데 시간을 보냈습니다. WebRTC에는 많은 비디오 및 오디오 앱이 있기 때문에 합리적인 선택처럼 들리지만 고려해야 할 다른 것들이 있습니까? 자유롭게 의견을 공유하십시오.

같은 것들:

  • 새로운 WebRTC는 일부 브라우저에서만 사용할 수 있지만 WebSocket은 더 많은 브라우저에있는 것 같습니다.

  • 확장 성-웹 소켓은 세션에 서버를 사용하며 WebRTC는 p2p 인 것 같습니다.

  • 멀티플렉싱 / 다중 채팅방-Google+ 행 아웃에서 사용되며 구현 방법에 대한 데모 앱을 계속보고 있습니다.

  • 서버-웹 소켓은 여러 시스템에 걸쳐 확장하려면 RedisSessionStore 또는 RabbitMQ가 필요합니다.

답변:


273

WebRTC는 비디오, 오디오 및 임의 데이터의 고성능 고품질 통신을 위해 설계되었습니다. 다시 말해, 당신이 묘사 한 것과 정확히 같은 앱입니다.

WebRTC 앱은 시그널링으로 알려진 프로세스 인 네트워크 및 미디어 메타 데이터를 교환 할 수있는 서비스가 필요합니다. 그러나 일단 신호가 발생하면 비디오 / 오디오 / 데이터가 클라이언트간에 직접 스트리밍되므로 중개 서버를 통한 스트리밍 성능 비용을 피할 수 있습니다.

반면에 WebSocket은 클라이언트와 서버 간의 양방향 통신을 위해 설계되었습니다. WebSocket을 통해 오디오 및 비디오를 스트리밍 할 수 있지만 (예를 들어 여기 참조 ) 기술 및 API는 기본적으로 WebRTC와 같은 방식으로 효율적이고 강력한 스트리밍을 위해 설계되지 않았습니다.

다른 답변에서 말했듯이 WebSocket을 사용하여 신호를 보낼 수 있습니다.

WebRTC 리소스 목록을 유지 관리 합니다 . WebRTC 에 대한 2013 Google I / O 프레젠테이션 을 살펴 보는 것이 좋습니다 .


2
자세한 답변 주셔서 감사합니다 ... 거의 2 년 후 업데이트가 있습니까?
— Crashalot

2
위에 링크 된 자료를 살펴 보는 것이 좋습니다 . g.co/webrtc를 참조하십시오 .
— Sam Dutton

3
또한 WebRTC는 패킷 순서와 내용에 대해 덜 엄격하게 구성 할 수 있으므로 패킷 손실 등을 신경 쓰지 않으면 훨씬 빠를 수 있습니다 (즉, 최신 데이터를 갖는 것이 모든 것을 갖는 것보다 중요 합니다) data) : stackoverflow.com/a/13051771/993683

1
나는 여기에 키워드를 생각할 때 . Socket.io의 폴링 폴백 기능이 이제 중복되므로 끔찍한 성능 비용으로 구현하기 쉬운 기능을 갖춘 웨이퍼 씬 라이브러리가 제공됩니다. 나를 시작하지 마십시오 : D.
— 누가 복음

1
@ SamDutton, 확실히 서버는 피어로 두 배가되어 RTCDataChannel 자체의 한쪽 끝을 사용할 수 있습니까? 현대 웹 프로그래밍의 경우 웹 소켓의 이점을 전혀 보지 못합니까? RTCDataChannel이 UDP / 실시간이므로?
— Pacerier

71

웹 소켓 :

  • web-socket-js polyfill을 사용하는 모든 최신 브라우저 및 레거시 브라우저를 지원하는 IETF 표준 (6455).

  • HTTP 호환 핸드 셰이크 및 기본 포트를 사용하여 기존 방화벽, 프록시 및 웹 서버 인프라에서 훨씬 쉽게 사용할 수 있습니다.

  • 훨씬 간단한 브라우저 API. 기본적으로 두 개의 콜백이있는 하나의 생성자입니다.

  • 클라이언트 / 브라우저는 서버에만 해당합니다.

  • TCP가 내장되어 있기 때문에 안정적인 순서대로 전송 만 지원합니다. 즉, 패킷 삭제는 모든 후속 패킷을 지연시킬 수 있습니다.

WebRTC :

  • Chrome 및 Firefox에서 지원되기 시작했습니다. MS는 호환되지 않는 변형을 제안했습니다. DataChannel 구성 요소는 Firefox와 Chrome간에 아직 호환되지 않습니다.

  • WebRTC는 이상적인 환경에서 브라우저 간 브라우저이지만 거의 항상 연결 설정을위한 신호 서버가 필요합니다. 가장 일반적인 신호 서버 솔루션은 현재 WebSocket을 사용합니다.

  • 전송 계층은 연결 순서가 양호하거나 신뢰할 수있는 경우 선택할 수있는 응용 프로그램으로 구성 할 수 있습니다.

  • 복잡하고 다층 브라우저 API. 더 간단한 API를 제공하는 JS 라이브러리가 있지만 젊고 빠르게 변화하고 있습니다 (WebRTC 자체처럼).


4
WebRTC 브라우저 지원이 훨씬 향상되었습니다. caniuse.com/#search=WebRTC
— tuxayo

59

웹 소켓은 TCP 프로토콜을 사용합니다.

WebRTC는 주로 UDP입니다.

따라서 Websocket 대신 WebRTC를 사용하는 주된 이유는 대기 시간입니다. 웹 소켓 스트리밍을 사용하면 대기 시간이 길거나 대기 시간이 짧은 고르지 재생이 가능합니다. WebRTC를 사용하면 대기 시간이 짧고 순조로운 재생이 가능하며 이는 VoIP 통신에 중요한 요소입니다.

이러한 기술을 네트워크 손실로 테스트하십시오 (예 : 2 %). Websocket 스트림에서 지연이 많이 발생합니다.


2
관심있는 사람들을 위해,이 물건은 여기에 더 설명되어 있습니다 : stackoverflow.com/a/13051771/993683

39

webRTC 또는 웹 소켓? 왜 둘 다 사용하지 않습니까?

비디오 / 오디오 / 텍스트 채팅을 구축 할 때 WebRTC는 피어 투 피어 기술을 사용하므로 연결이 설정되고 실행되면 서버를 통해 통신을 전달할 필요가 없습니다 (TURN을 사용하지 않는 한).

webRTC 통신을 설정할 때는 일종의 신호 메커니즘이 필요합니다. Websockets는 여기에서 좋은 선택이 될 수 있지만 webRTC는 비디오 / 오디오 / 텍스트 정보로가는 길입니다. 대화방은 신호로 이루어집니다.

그러나 언급했듯이 모든 브라우저가 webRTC를 지원하는 것은 아니므로 웹 브라우저가 때로는 해당 브라우저에 좋은 대안이 될 수 있습니다.


11

보안은 당신이 놓친 한 가지 측면입니다.

Websocket을 사용하면 데이터는 일반적으로 모든 트래픽을보고 액세스 할 수있는 중앙 웹 서버를 통해 이동해야합니다.

WebRTC를 사용하면 데이터가 종단 간 암호화되며 서버를 통과하지 않습니다 (때로는 TURN 서버가 필요하지만 전달하는 메시지 본문에 액세스 할 수 없음).

응용 프로그램에 따라 이것은 중요하거나 중요하지 않을 수 있습니다.

대량의 데이터를 전송하는 경우 webRTC의 P2P 아키텍처로 인한 클라우드 대역폭 비용 절감도 고려할 가치가 있습니다.


1
WebRTC는 P2P 프로토콜이라는 오해입니다. 서버 기반 VOIP 대안으로 업계에서 널리 사용되기 시작했습니다.
— photicSphere

또한 WebSocket을 WebRTC의 미디어 흐름으로 구현할 때 SIP를 사용하고 SIP는 VoIP에 사용 된 일반 텍스트 프로토콜입니다.
— M. Rostami

10

websocket과 webrtc를 비교하는 것은 불공평합니다.

웹 소켓은 TCP를 기반으로합니다. 패킷의 경계는 tcp와 달리 웹 소켓 패킷의 헤더 정보에서 감지 할 수 있습니다.

일반적으로 webrtc는 websocket을 사용합니다. webrtc에 대한 시그널링은 정의되어 있지 않으며, 어떤 종류의 시그널링을 사용하고 싶은지는 서비스 제공자에게 달려 있습니다. SIP, HTTP, JSON 또는 모든 텍스트 / 이진 메시지 일 수 있습니다.

시그널링 메시지는 웹 소켓을 사용하여 송수신 할 수 있습니다.


6

Webrtc는 피어 투 피어 연결의 일부입니다. 우리는 피어 투 피어 연결을 만들기 전에 피어 투 피어 연결을 설정하기 위해 핸드 쉐이킹 프로세스가 필요하다는 것을 알고 있습니다. 그리고 웹 소켓은 핸드 쉐이킹 프로세스의 역할을합니다.


3

Websocket과 WebRTC를 함께 사용할 수 있고 Websocket을 WebRTC의 신호 채널로 사용할 수 있으며 webrtc는 비디오 / 오디오 / 텍스트 채널이며 WebRTC는 TURN 릴레이에서도 UDP에있을 수 있으며 TURN 릴레이는 TCP HTTP와 HTTPS를 지원합니다. 많은 프로젝트가 Websocket과 WebRTC를 함께 사용합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.