ProgramingTip

WebSockets vs. Server-Sent 이벤트 / EventSource

bestdevel 2020. 9. 29. 08:10
반응형

WebSockets vs. Server-Sent 이벤트 / EventSource


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


Websocket과 SSE (Server Sent Events)는 모두 데이터를 브라우저에 푸시 할 수 있습니다 경쟁 기술은 아닙니다.

Websockets 연결은 브라우저에 데이터를 보내고 브라우저에서 데이터를받을 수 있습니다. 웹 소켓을 사용할 수있는 애플리케이션의 좋은 예는 채팅 애플리케이션입니다.

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

SSE로 수행 할 수있는 모든 작업을 수행 할 수 있기 때문에 Websockets는 많은 관심과 사랑을 받고 SSE보다 Websocket을 지원하는 브라우저가 더 있습니다.

그러나 일부 유형의 애플리케이션에서는 과도하게 사용할 수있는 SSE와 같은 프로토콜을 사용하여 백엔드를 구현하는 것이 더 쉬울 수 있습니다.

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

고차 :

  • SSE는 최대 열린 연결 수에 대한 제한으로 인해 제한이 브라우저 당 제한이고 매우 낮은 수 (6)로 설정되어 다양한 탭을 열 때 특히 고통 스러울 수 있습니다 . ChromeFirefox 에서 문제가 "해결되지 않음"으로 표시되었습니다.
  • WS만이 바이너리 데이터와 UTF-8을 모두 사용할 수 있습니다. SSE는 UTF-8로 제한됩니다. (Cado Nihi에게 감사드립니다).
  • 패킷 검사 기능이있는 일부 문제가 방화벽은 WebSocket (Sophos XG Firewall, WatchGuard, McAfee Web Gateway)을 처리하는 데 있습니다.

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

서버 전송 이벤트 대 WebSocket

WebSockets 대신 Server-Sent Events를 선택하는 이유는 무엇입니까? 좋은 질문.

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

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


TLDR 요약 :

Websocket에 비해 SSE의 장점 :

  • 사용자 지정 프로토콜 대신 간단한 HTTP를 통해 전송
  • 아직 지원하지 않는 브라우저로 SSE를 "백 포트"하기 위해 javascript로 폴리 필 할 수 있습니다.
  • 재 연결 및 이벤트 ID 지원 내장
  • 더 간단한 프로토콜
  • 패킷 검사를 수행하는 기업 방화벽에 문제 없음

SSE에 비해 Websocket의 장점 :

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

SSE의 사례 사용 사례 :

  • 주식 시세 스트리밍
  • 트위터 피드 업데이트

  • 브라우저에 대한 알림

SSE 문제 :

  • 바이너리 지원 없음
  • 최대 열린 연결 제한

caniuse.com에 따르면 :

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

모든 브라우저를 지원해야하는 경우 WebSockets, SSE, Forever Frame 및 AJAX 긴 폴링과 같은 다중 전송을 지원하는 web-socket-js , SignalR 또는 socket.io 와 같은 라이브러리를 사용하는 것이 좋습니다 . 이를 위해서는 종종 서버 측도 수정해야합니다.

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

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

기타 차이점 :

  • WebSockets는 임의의 바이너리 데이터를 지원하며 SSE는 UTF-8 만 사용합니다.

Opera, Chrome, Safari는 SSE, Chrome, Safari는 SharedWorker 내부에서 SSE를 지원합니다. Firefox는 XMLHttpRequest readyState를 대화 형으로 지원하므로 Firefox 용 EventSource 폴리 필을 만들 수 있습니다.



Websocket 대 SSE


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

Example - Online chat application.

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

Example - Online stock quotes or cricket score website.

한 가지 주목할 점
은 웹 소켓과 기업 방화벽에 문제가 있다는 것입니다. (HTTPS를 사용하면 도움이되지만 항상 그런 것은 아닙니다.)

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

나는 가정 서버 전송 이벤트에 많은 문제가되지 않습니다. 하지만 모르겠어요.

즉, WebSocket은 정말 재미 있습니다. 나는 웹 소켓을 사용하는 작은 웹 게임을 가지고 있습니다 (Socket.IO를 통해) ( http://minibman.com )


다음 은 웹 소켓과 서버 전송 이벤트의 차이점에 대한 설명입니다. Java EE 7 이후 WebSocket API는 이미 사양의 일부이며 서버 전송 이벤트는 엔터프라이즈 에디션 다음 버전 에서 출시 될 것으로 보입니다 .


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

http 1의 문제였습니다.

참고 URL : https://stackoverflow.com/questions/5195452/websockets-vs-server-sent-events-eventsource

반응형