그래서 비디오, 오디오 및 텍스트를 허용하는 채팅 앱을 만들고 싶습니다. 어느 것을 사용할지 결정하기 위해 Websocket과 WebRTC를 조사하는 데 시간을 보냈습니다. WebRTC에는 많은 비디오 및 오디오 앱이 있기 때문에 합리적인 선택처럼 들리지만 고려해야 할 다른 것들이 있습니까? 자유롭게 의견을 공유하십시오.
같은 것들:
-
새로운 WebRTC는 일부 브라우저에서만 사용할 수 있지만 WebSocket은 더 많은 브라우저에있는 것 같습니다.
-
확장 성-웹 소켓은 세션에 서버를 사용하며 WebRTC는 p2p 인 것 같습니다.
-
멀티플렉싱 / 다중 채팅방-Google+ 행 아웃에서 사용되며 구현 방법에 대한 데모 앱을 계속보고 있습니다.
-
서버-웹 소켓은 여러 시스템에 걸쳐 확장하려면 RedisSessionStore 또는 RabbitMQ가 필요합니다.
답변
WebRTC는 비디오, 오디오 및 임의 데이터의 고성능 고품질 통신을 위해 설계되었습니다. 다시 말해, 당신이 묘사 한 것과 정확히 같은 앱입니다.
WebRTC 앱은 시그널링으로 알려진 프로세스 인 네트워크 및 미디어 메타 데이터를 교환 할 수있는 서비스가 필요합니다. 그러나 일단 신호가 발생하면 비디오 / 오디오 / 데이터가 클라이언트간에 직접 스트리밍되므로 중개 서버를 통한 스트리밍 성능 비용을 피할 수 있습니다.
반면에 WebSocket은 클라이언트와 서버 간의 양방향 통신을 위해 설계되었습니다. WebSocket을 통해 오디오 및 비디오를 스트리밍 할 수 있지만 (예를 들어 여기 참조 ) 기술 및 API는 기본적으로 WebRTC와 같은 방식으로 효율적이고 강력한 스트리밍을 위해 설계되지 않았습니다.
다른 답변에서 말했듯이 WebSocket을 사용하여 신호를 보낼 수 있습니다.
WebRTC 리소스 목록을 유지 관리 합니다 . WebRTC 에 대한 2013 Google I / O 프레젠테이션 을 살펴 보는 것이 좋습니다 .
답변
웹 소켓 :
-
web-socket-js polyfill을 사용하는 모든 최신 브라우저 및 레거시 브라우저를 지원하는 IETF 표준 (6455).
-
HTTP 호환 핸드 셰이크 및 기본 포트를 사용하여 기존 방화벽, 프록시 및 웹 서버 인프라에서 훨씬 쉽게 사용할 수 있습니다.
-
훨씬 간단한 브라우저 API. 기본적으로 두 개의 콜백이있는 하나의 생성자입니다.
-
클라이언트 / 브라우저는 서버에만 해당합니다.
-
TCP가 내장되어 있기 때문에 안정적인 순서대로 전송 만 지원합니다. 즉, 패킷 삭제는 모든 후속 패킷을 지연시킬 수 있습니다.
WebRTC :
-
Chrome 및 Firefox에서 지원되기 시작했습니다. MS는 호환되지 않는 변형을 제안했습니다. DataChannel 구성 요소는 Firefox와 Chrome간에 아직 호환되지 않습니다. -
WebRTC는 이상적인 환경에서 브라우저 간 브라우저이지만 거의 항상 연결 설정을위한 신호 서버가 필요합니다. 가장 일반적인 신호 서버 솔루션은 현재 WebSocket을 사용합니다.
-
전송 계층은 연결 순서가 양호하거나 신뢰할 수있는 경우 선택할 수있는 응용 프로그램으로 구성 할 수 있습니다.
-
복잡하고 다층 브라우저 API. 더 간단한 API를 제공하는 JS 라이브러리가 있지만 젊고 빠르게 변화하고 있습니다 (WebRTC 자체처럼).
답변
웹 소켓은 TCP 프로토콜을 사용합니다.
WebRTC는 주로 UDP입니다.
따라서 Websocket 대신 WebRTC를 사용하는 주된 이유는 대기 시간입니다. 웹 소켓 스트리밍을 사용하면 대기 시간이 길거나 대기 시간이 짧은 고르지 재생이 가능합니다. WebRTC를 사용하면 대기 시간이 짧고 순조로운 재생이 가능하며 이는 VoIP 통신에 중요한 요소입니다.
이러한 기술을 네트워크 손실로 테스트하십시오 (예 : 2 %). Websocket 스트림에서 지연이 많이 발생합니다.
답변
webRTC 또는 웹 소켓? 왜 둘 다 사용하지 않습니까?
비디오 / 오디오 / 텍스트 채팅을 구축 할 때 WebRTC는 피어 투 피어 기술을 사용하므로 연결이 설정되고 실행되면 서버를 통해 통신을 전달할 필요가 없습니다 (TURN을 사용하지 않는 한).
webRTC 통신을 설정할 때는 일종의 신호 메커니즘이 필요합니다. Websockets는 여기에서 좋은 선택이 될 수 있지만 webRTC는 비디오 / 오디오 / 텍스트 정보로가는 길입니다. 대화방은 신호로 이루어집니다.
그러나 언급했듯이 모든 브라우저가 webRTC를 지원하는 것은 아니므로 웹 브라우저가 때로는 해당 브라우저에 좋은 대안이 될 수 있습니다.
답변
보안은 당신이 놓친 한 가지 측면입니다.
Websocket을 사용하면 데이터는 일반적으로 모든 트래픽을보고 액세스 할 수있는 중앙 웹 서버를 통해 이동해야합니다.
WebRTC를 사용하면 데이터가 종단 간 암호화되며 서버를 통과하지 않습니다 (때로는 TURN 서버가 필요하지만 전달하는 메시지 본문에 액세스 할 수 없음).
응용 프로그램에 따라 이것은 중요하거나 중요하지 않을 수 있습니다.
대량의 데이터를 전송하는 경우 webRTC의 P2P 아키텍처로 인한 클라우드 대역폭 비용 절감도 고려할 가치가 있습니다.
답변
websocket과 webrtc를 비교하는 것은 불공평합니다.
웹 소켓은 TCP를 기반으로합니다. 패킷의 경계는 tcp와 달리 웹 소켓 패킷의 헤더 정보에서 감지 할 수 있습니다.
일반적으로 webrtc는 websocket을 사용합니다. webrtc에 대한 시그널링은 정의되어 있지 않으며, 어떤 종류의 시그널링을 사용하고 싶은지는 서비스 제공자에게 달려 있습니다. SIP, HTTP, JSON 또는 모든 텍스트 / 이진 메시지 일 수 있습니다.
시그널링 메시지는 웹 소켓을 사용하여 송수신 할 수 있습니다.
답변
Webrtc는 피어 투 피어 연결의 일부입니다. 우리는 피어 투 피어 연결을 만들기 전에 피어 투 피어 연결을 설정하기 위해 핸드 쉐이킹 프로세스가 필요하다는 것을 알고 있습니다. 그리고 웹 소켓은 핸드 쉐이킹 프로세스의 역할을합니다.
