WebSockets vs. 서버가 보낸 이벤트 / 이벤트 소스

838

WebSocket 과 Server-Sent Events 는 모두 데이터를 브라우저로 푸시 할 수 있습니다. 나에게 그들은 경쟁 기술인 것 같습니다. 그들 사이의 차이점은 무엇입니까? 언제 다른 것을 선택 하시겠습니까?

html  browser  websocket  server-sent-events 
— Mads Mobæk
소스
2
그들이 어떻게 경쟁하고 있는지 잘 모르겠습니다. 하나는 동기식이며 거의 실시간 데이터 xfer에 사용될 수 있고 / 다른 하나는 비동기식이며 완전히 다른 목적 (서버 측 앱에서 토스트 같은 메시지를 효과적으로 전송)을 제공합니다.
— 브라이언 드리스콜
54
WebSocket은 양방향이며 서버로 데이터를 전송할 수 있습니다.
— Andre Backlund
13
내가 SSE에 대해 정말로 좋아하는 한 가지는 문제 해결이 쉽다는 것입니다 curl.를 사용하여 SSE 서버에 요청을 열면됩니다 . HTTP를 통한 텍스트 형식이므로 진행 상황을 쉽게 확인할 수 있습니다.
— Sam
7
@BrianDriscoll-비동기 / 동기-어느 것입니까? 내가 비동기 전송을 가능하게하는 것을 이해할 수있는 한?
— Dave Everitt
5
SSE는 IE에서 작동하지 않으며 웹 소켓은 작동합니다.
— Tyler Gillies

답변:

977

웹 소켓과 SSE (Server Sent Events)는 데이터를 브라우저로 푸시 할 수 있지만 경쟁 기술은 아닙니다.

웹 소켓 연결은 브라우저로 데이터를 전송하고 브라우저에서 데이터를 수신 할 수 있습니다. 웹 소켓을 사용할 수있는 응용 프로그램의 좋은 예는 채팅 응용 프로그램입니다.

SSE 연결은 데이터를 브라우저로만 푸시 할 수 있습니다. 타임 라인 또는 피드를 업데이트하는 온라인 주식 시세 또는 트위터가 SSE의 혜택을받을 수있는 좋은 예입니다.

실제로 SSE로 수행 할 수있는 모든 것을 Websocket으로 수행 할 수 있기 때문에 Websockets는 많은 관심과 사랑을 받고 있으며 더 많은 브라우저가 SSE보다 Websocket을 지원합니다.

그러나 일부 유형의 응용 프로그램에는 무리가있을 수 있으며 SSE와 같은 프로토콜을 사용하여 백엔드를 쉽게 구현할 수 있습니다.

또한 SSE는 JavaScript 만 사용하여 기본적으로 지원하지 않는 구형 브라우저에 폴리 필 할 수 있습니다. SSE 폴리 필의 일부 구현은 Modernizr github 페이지 에서 찾을 수 있습니다 .

잡았다 :

  • SSE는 열린 연결의 최대 수에 제한이 있으며 , 브라우저마다 제한이 있고 매우 낮은 수 (6)로 설정되어 있으므로 다양한 탭을 열 때 특히 고통 스러울 수 있습니다 . Chrome 및 Firefox 에서 문제가 '수정되지 않음'으로 표시되었습니다 . 이 제한은 브라우저 + 도메인마다 적용되므로 모든 탭에서 6 개의 SSE 연결을 열 수 www.example1.com있고 다른 6 개의 SSE 연결을 열 수 있습니다 www.example2.com(Fate 감사).
  • WS 만 이진 데이터와 UTF-8을 모두 전송할 수 있으며 SSE는 UTF-8로 제한됩니다. (차도 니히에게 감사합니다).
  • 패킷 검사 기능이있는 일부 엔터프라이즈 방화벽은 WebSocket (Sophos XG Firewall, WatchGuard, McAfee Web Gateway)을 처리하는 데 문제가 있습니다.

HTML5Rocks 에는 SSE에 대한 유용한 정보가 있습니다. 해당 페이지에서 :

서버가 보낸 이벤트와 웹 소켓

WebSockets 대신 Server-Sent Events를 선택 하시겠습니까? 좋은 질문.

SSE가 섀도우로 유지 된 이유 중 하나는 WebSocket과 같은 API가 양방향 전이중 통신을 수행하기 위해보다 풍부한 프로토콜을 제공하기 때문입니다. 양방향 채널을 사용하는 것은 게임, 메시징 앱 및 양방향으로 거의 실시간 업데이트가 필요한 경우에 더 매력적입니다. 그러나 일부 시나리오에서는 클라이언트에서 데이터를 보낼 필요가 없습니다. 일부 서버 작업의 업데이트 만 있으면됩니다. 친구 상태 업데이트, 주식 시세 표시기, 뉴스 피드 또는 기타 자동화 된 데이터 푸시 메커니즘 (예 : 클라이언트 측 웹 SQL 데이터베이스 또는 IndexedDB 오브젝트 저장소 업데이트)이 몇 가지 예입니다. 서버로 데이터를 보내야하는 경우 XMLHttpRequest는 항상 친구입니다.

SSE는 기존 HTTP를 통해 전송됩니다. 즉, 작동하기 위해 특별한 프로토콜이나 서버 구현이 필요하지 않습니다. 반면에 WebSocket은 프로토콜을 처리하기 위해 전이중 연결 및 새로운 Web Socket 서버가 필요합니다. 또한 서버 전송 이벤트에는 자동 재 연결, 이벤트 ID 및 임의의 이벤트 전송 기능과 같이 WebSocket에 설계 상으로는 부족한 다양한 기능이 있습니다.

TLDR 요약 :

웹 소켓에 비해 SSE의 장점 :

  • 사용자 정의 프로토콜 대신 간단한 HTTP를 통해 전송
  • SSE를 아직 지원하지 않는 브라우저로 SSE를 "백 포트"하기 위해 Javascript로 폴리 필 가능
  • 재 연결 및 event-id 지원 내장
  • 더 간단한 프로토콜
  • 패킷 검사를 수행하는 회사 방화벽에 문제가 없습니다

SSE에 비해 웹 소켓의 장점 :

  • 실시간 양방향 통신.
  • 더 많은 브라우저에서 기본 지원

SSE의 이상적인 사용 사례 :

  • 주식 시세 스트리밍
  • 트위터 피드 업데이트
  • 브라우저에 알림

SSE 문제 :

  • 바이너리 지원 없음
  • 최대 개방 연결 제한
— 알렉스 리 캐리
소스
131
SSE로 채팅을 완벽하게 수행 할 수 있습니다. 일반 POST를 사용하여 서버에 메시지를 보낼 수 있습니다. WebSockets는 채팅을 Google Wave로 구현하는 경우에만 필요합니다.
— Kornel
135
채팅 및 기타 실시간 응용 프로그램을 SSE로 수행 할 수 있다는 것은 사실입니다. 그러나 POST를 위해서는 "대역 외"의 회신이 필요합니다. 즉, 이것은 SSE 프로토콜에 의해 제어되지 않으며 SSE와 Websocket의 차이점에 대한 기본적인 설명을위한 좋은 예는 아닙니다. 매초마다 서버를 폴링하고 새로운 응답을 POST하는 기본 HTTP로 채팅을 구현할 수 있습니다. 그렇다고해서 그것이 가장 훌륭하고 우아한 방법이라는 것을 의미하지는 않습니다.
— Alex Recarey
14
JS가 AJAX POST를 사용하여 서버에 항상 "푸시"할 수 있기 때문에 pomeL의 솔루션은 대부분의 경우 큰 절충안이라고 생각합니다. 내 경험에 비추어 볼 때 주된 문제는 일반적으로 JS가 새로운 정보를 폴링해야한다는 것이지만 SSE는이를 처리합니다. : D
— Jacob Pritchett
12
@MattDiPasquale Wave는 한 번에 완전한 메시지 대신 입력 한대로 모든 키를 개별적으로 보냈습니다. 한 번의 키 입력으로 200 바이트의 POST 오버 헤드가 발생하면 WebSocket의 경우 약 6 바이트가 낭비됩니다.
— Kornel
9
그들이 경쟁하는 기술이 아니라고 말하는 것은 조금 이상해 보인다. 그리고 그것들이 비슷한 솔루션을 달성하기 위해 사용될 수 있다고 설명하기 시작한다. 나는 그들이 경쟁하게 만든다고 말할 것입니다.
— Alex
115

caniuse.com에 따르면 :

클라이언트 전용 폴리 필을 사용하여 SSE 지원을 다른 많은 브라우저로 확장 할 수 있습니다. WebSockets에서는 가능성이 적습니다. 일부 EventSource 폴리 필 :

모든 브라우저를 지원해야하는 경우 web-socket-js , SignalR 또는 socket.io 와 같은 라이브러리를 사용하여 WebSockets, SSE, Forever Frame 및 AJAX long polling과 같은 다중 전송을 지원하십시오. 이것들은 종종 서버 쪽도 수정해야합니다.

SSE에 대한 자세한 내용은 다음을 참조하십시오.

다음에서 WebSocket에 대해 자세히 알아보십시오.

다른 차이점들 :

  • WebSockets는 임의의 이진 데이터를 지원하고 SSE는 UTF-8 만 사용합니다
— 드류 노아 케스
소스
3
2016 년에 전 세계 사용자의 95 %가 기본적으로 WebSocket을 지원한다고 지적하고 싶습니다. 모든 브라우저 및 장치는 4 년 동안 WebSocket을 지원했습니다. Socket.IO는 AJAX long polling으로 폴백하고 지원되지 않는 WebSockets 에뮬레이션의 복잡성을 처리하여 100 % 지원합니다. 2016 년에 WebSockets 이외의 것을 사용하는 경우 오래된 기술을 사용하는 것입니다.
— Nick Steele
3
@NickSteele 그것은 헛소리입니다. 구식 표준에 의존하는 것이 사용 사례를 충족하고 어떤 것이 오래되었다는 의미는 아닙니다. 다른 표준 일뿐입니다. 예 : XHR은 여전히 ​​Fetch API가 할 수없는 많은 작업을 수행 할 수 있으므로 구식이 아닙니다. 그것은 다르다. 과거에는 WS를 사용해 왔지만 경험을 통해 WS를 이해하지 못하는 경우 요청을 차단하는 노이즈 엔터프라이즈 방화벽의 형태로 혼란에 빠질 수 있다는 것을 알고 있습니다. SSE는 기능이 매우 효율적이며, 이해하기 쉽고 구현 가능하며 디버깅하기 쉽습니다. 단방향 데이터 흐름의 경우 완벽합니다.
— oligofren
@oligofren 맹세 할 필요가 없습니다. 이전 버전을 대체하도록 무언가가 설계되어 있고 업계에서 모든면에서 인정되고 더 나은 것으로 정의하면 이전 방법은 구식입니다. 원래 iPhone이 구식 인 것처럼 XHR도 마찬가지입니다. XHR은 Firefox, Chrome, 첫 번째 iPhone, YouTube, Netflix, Facebook 및 MySpace 이전에 나왔습니다. XHR이 나왔을 때 Windows 98이 최고의 OS 였고 AOL이 최고의 공급자였으며 JSON도 존재하지 않았습니다. WebSockets는 거의 10 년 전에 XHR을 대체했습니다. WS를 사용하여 걸림을 겪으면 걸림을 일으킨 것도 오래된 것입니다. 그렇게 늦어 질 변명의 여지가 없습니다.
— Nick Steele
4
BS를 하이퍼 볼로 교체 한 다음 :-) WS는 드론보다 배달 차용 XHR / HTTP를 대체하지 않습니다. 사용 사례가 다릅니다. WS는 HTTP가 아니며 다른 지점이 있습니다. 시도하면 사용자 공간에서 HTTP를 제대로 구현하지 못하게됩니다. 또한, 당신은 사실을주지 않는 것을 암시하고 있습니다 : WS는 단순히 서버 푸시를 지원하는 양방향 프로토콜입니다. 나는 어떤 디자인 문서가 그것을 대체하는 것으로 개발되고 있다고 언급 한 적이 없다. 출처? 나이 자체는 하나의 요소가 아닙니다. 선택 사항이 있으면 모든 요구 사항을 확인하는 가장 간단한 구현을 선택하십시오.
— oligofren
1
불과 2 년 전 (2017) Socket.io 코드가 IIS 프로세스에서 엄청난 메모리 조각화를 일으켜 Azure의 Node 팀과 직접 대화하는 Node JS 프로세스의 힙 덤프를 디버깅했습니다. 총 복잡성은 무료가 아닙니다. 서버에 대한 의존성으로 간단한 20 줄 스크립트를 사용하면서도 100K 클라이언트를 제공 할 수 있다면 갈 것입니다. WS의 기능은 좋아하지만 솔루션을 선택하기 전에 필요한 내용을 살펴보십시오.
— oligofren
16

Opera, Chrome, Safari는 SSE, Chrome, Safari는 SharedWorker 내부의 SSE를 지원합니다. Firefox는 XMLHttpRequest readyState 대화식을 지원하므로 Firefox 용 EventSource polyfil을 만들 수 있습니다

— 이플
소스
8

웹 소켓 VS SSE

웹 소켓- 단일 TCP 연결을 통해 전이중 통신 채널을 제공하는 프로토콜입니다. 예를 들어 서버와 브라우저 사이의 양방향 통신 프로토콜이 더 복잡하기 때문에 서버와 브라우저는 웹 소켓 라이브러리에 의존해야합니다.socket.io

Example - Online chat application.

SSE (Server-Sent Event)- 서버 전송 이벤트의 경우 서버에서 브라우저로만 통신이 이루어지고 브라우저는 서버로 데이터를 보낼 수 없습니다. 이러한 종류의 통신은 주로 업데이트 된 데이터를 표시하기 만하면 데이터가 업데이트 될 때마다 서버가 메시지를 보냅니다. 예를 들어 서버와 브라우저 간의 단방향 통신. 이 프로토콜은 덜 복잡하므로 외부 라이브러리에 의존 할 필요가 없습니다. JAVASCRIPT 자체는 EventSource서버가 보낸 메시지를 수신하기위한 인터페이스를 제공 합니다.

Example - Online stock quotes or cricket score website.
— 가우 라브 티 와리
소스
4

한 가지 알아 두어야 할 점 :
웹 소켓 및 회사 방화벽에 문제가 있습니다. (HTTPS를 사용하면 도움이되지만 항상 그런 것은 아닙니다.)

참조 https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software https://github.com/sockjs/sockjs-client/issues/94을

나는 가정 서버 전송 이벤트에 많은 문제가되지 않습니다. 그러나 나는 모른다.

WebSockets는 엄청나게 재미 있습니다. 웹 소켓을 사용하는 작은 웹 게임이 있습니다 (Socket.IO를 통해) ( http://minibman.com )

— 드류 레수 에르
소스
1
회사 방화벽에도 문제가있었습니다.
— oligofren
1
서버 전송 이벤트에서 본 한 가지 문제는 일부 프록시 / 방화벽에 Content-Length 헤더가 없기 때문에 차단할 수 있다는 것입니다.
— Drew LeSueur
2

다음 은 웹 소켓과 서버 전송 이벤트의 차이점에 대한 설명입니다. Java EE 7부터 WebSocket API는 이미 사양의 일부이며 서버 전송 이벤트는 다음 버전의 Enterprise Edition 에서 릴리스 될 것으로 보입니다 .

— 패트릭 라이터 만
소스
-3

최대 연결 제한은 http2 + sse의 문제가 아닙니다.

http 문제 1

— 사용자 1948585
소스
Http2를 사용하면 동일한 도메인의 여러 요청을 스트림으로 처리 할 수 ​​있습니다. 이 기술을 멀티플렉싱이라고합니다. 이는 도메인 당 브라우저 연결 제한을 저장하므로 사람들이 Http1을 사용하여 도메인 샤딩을 수행하는 이유입니다.
— user1948585
1
HTTP / 2 스트림의 수도 제한되어있어 단일 브라우저에 의해 서버가 공격당하는 것을 막고 브라우저가 제한된 수의 스트림으로 멀티플렉싱을 제한하도록합니다 (이 경우 HTTP / 1.1 연결과 동일). SSE 연결 제한으로 돌아갑니다.
— Myst
웹 소켓 연결도 서버 리소스를 소비한다고 가정합니다. samsaffron.com/archive/2015/12/29/websockets-caution-required . 주머니가 허용하는 한 많이 구성 할 수있는 것이 좋습니다.
— user1948585
SSE는 대부분의 서버에서 유사한 리소스를 소비 할 가능성이 높습니다 (여전히 존재하는 HTTP 스택으로 인해 더 많은 리소스가 없으면 제한 사항 임).
— Myst
1
이 대답은 맞습니다. HTTP / 2를 사용할 때 6 개의 HTTP 연결 제한이 더 이상 존재하지 않습니다. 증명 : codepen.io/dunglas/pen/yLYxdxK?editors=1010 HTTP / 2에서는 서버가 가동 중이며 클라이언트는 최대 동시 스트림 수를 협상 할 수 있습니다 (기본적으로 100).
— 케빈 던 글라스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.