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.