웹소켓과서버에서 보낸 이벤트/이벤트 소스

웹소켓과서버에서 보낸 이벤트/이벤트 소스

WebSockets와 Server-Sent Events는 모두 브라우저에 데이터를 푸시할 수 있습니다.내가 보기에 그들은 경쟁하는 기술인 것 같다.그들의 차이점은 무엇입니까?언제 둘 중 하나를 선택하겠습니까?

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

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

SSE 연결은 브라우저에만 데이터를 푸시할 수 있습니다.SSE의 혜택을 받을 수 있는 어플리케이션의 좋은 예로는 온라인 주식 시세, 타임라인 또는 피드를 갱신하는 트위터 등이 있습니다.

실제로 SSE로 할 수 있는 모든 것은 웹소켓으로도 할 수 있기 때문에 웹소켓은 훨씬 더 많은 관심과 사랑을 받고 있으며 많은 브라우저가 SSE보다 웹소켓을 지원하고 있다.

그러나 일부 유형의 애플리케이션에서는 오버킬이 발생할 수 있으며 SSE 등의 프로토콜을 사용하여 백엔드를 구현하기가 더 쉽습니다.

또한 SSE는 JavaScript만을 사용하여 네이티브하게 지원하지 않는 오래된 브라우저에 폴리필할 수 있습니다.SSE 폴리필의 일부 실장은 Modernizr github 페이지에서 확인할 수 있습니다.

Gotchas:

• SSE는 열려 있는 접속의 최대수에 제한이 있기 때문에 브라우저마다 제한이 있고 매우 낮은 수(6)로 설정되어 있기 때문에 다양한 탭을 열 때 특히 문제가 발생할 수 있습니다.이 문제는 Chrome 및 Firefox에서 "수정되지 않음"으로 표시되어 있습니다.이 제한은 브라우저 + 도메인 단위로 모든 탭에서 6개의 SSE 연결을 열 수 있습니다.www.example1.com의 SSE 을 SSE에 대한 SSE 접속은 6개입니다.www.example2.com(일부러)
• WS만이 바이너리 데이터와 UTF-8을 모두 전송할 수 있으며 SSE는 UTF-8로 제한됩니다(Chado Nihi 덕분에).
• 패킷 검사를 사용하는 일부 기업 방화벽은 WebSockets(Sophos XG Firewall, WatchGuard, McAfee Web Gateway)를 처리하는 데 문제가 있습니다.

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

서버에서 전송된 이벤트와웹 소켓

WebSockets가 아닌 Server-Sent Events를 선택하는 이유는 무엇입니까?좋은 질문입니다.

SSE가 그늘에 가려진 이유 중 하나는 WebSockets와 같은 최신 API가 양방향 전체 이중 통신을 수행하기 위한 보다 풍부한 프로토콜을 제공하기 때문입니다.양방향 채널을 갖는 것은 게임, 메시징 앱, 양방향 실시간 업데이트가 필요한 경우에 더 매력적입니다.그러나 경우에 따라서는 클라이언트에서 데이터를 전송할 필요가 없습니다.일부 서버 액션에서 업데이트가 필요합니다.예를 들어 친구의 상태 업데이트, 주식 티커, 뉴스 피드 또는 기타 자동화된 데이터 푸시 메커니즘(클라이언트 측 웹 SQL 데이터베이스 업데이트 또는 색인화됨)이 있습니다.DB 객체 저장소).서버에 데이터를 송신할 필요가 있는 경우, XMLHttpRequest는 항상 친구입니다.

SSE 는, 종래의 HTTP 를 개입시켜 주세요.즉, 작업을 수행하기 위해 특별한 프로토콜이나 서버 구현이 필요하지 않습니다.반면 WebSockets는 프로토콜을 처리하려면 전이중 연결과 새로운 웹 소켓 서버가 필요합니다.또한 Server-Sent Events에는 자동 재연결, 이벤트 ID, 임의 이벤트 전송 기능 등 WebSocket에 없는 다양한 기능이 있습니다.

---

TLDR 요약:

웹소켓 대비 SSE의 장점:

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

SSE에 비해 웹소켓의 장점:

• 실시간, 양방향 커뮤니케이션.
• 더 많은 브라우저에서 네이티브 지원

SSE의 이상적인 사용 사례:

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

SSE Gotchas:

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

caniuse.com에 따르면:

• 글로벌 사용자의 98.35%가 WebSockets를 네이티브로 지원
• 글로벌 사용자의 98.03%가 서버 전송 이벤트를 네이티브로 지원

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

• 다른 라이브러리 종속성이 없는 Remy Sharp의 EventSource(IE7+)
• jQuery.EventSource by Rick Waldron
• Event Source by Yaffle (네이티브 구현 대체, 브라우저 전체의 동작 정규화)

모든 브라우저를 지원해야 할 경우 Web-sockets, SSE, Forever Frame 및 AJAX 롱 폴링 등의 여러 전송을 지원하는 web-sockets, SignalR 또는 socket.io 등의 라이브러리를 사용하는 것을 고려해 보십시오.서버측도 변경해야 하는 경우가 많습니다.

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

• HTML5 Rocks 기사
• W3C 사양(공개 버전, 에디터 초안)

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

• HTML5 Rocks 기사
• W3C 사양(공개 버전, 에디터 초안)

기타 차이점:

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

---

웹 소켓 VS SSE

---

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

Example - Online chat application.

SSE(Server-Sent Event) - 서버 전송 이벤트의 경우 서버 간 통신만 수행되며 브라우저는 서버에 데이터를 전송할 수 없습니다.이러한 종류의 통신은 주로 업데이트된 데이터를 보여줄 때만 사용되며, 데이터가 업데이트될 때마다 서버가 메시지를 보냅니다.예를 들어 서버와 브라우저 간의 단방향 통신입니다.이 프로토콜은 덜 복잡하기 때문에 외부 라이브러리에 의존할 필요가 없습니다.JAVASCript 자체는EventSourceinterface 를 지정해, 서버로부터 송신한 메시지를 수신합니다.

Example - Online stock quotes or cricket score website.

Opera, Chrome, Safari는 SSE, Chrome, Safari는 SharedWorker Firefox 내에서 SSE를 지원하므로 XMLHttpRequest readyState를 지원하므로 EventSource polyfil for Firefox를 만들 수 있습니다.

한 가지 주의할 점은 다음과 같습니다.
웹소켓이나 회사 방화벽에 문제가 있었습니다.(HTTPS를 사용하는 것은 도움이 되지만 항상 도움이 되는 것은 아닙니다.)

https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software 를 참조해 주세요.https://github.com/sockjs/sockjs-client/issues/94

Server-Sent Events에는 그다지 문제가 없다고 생각합니다.하지만 나는 모른다.

웹소켓은 매우 재미있습니다.웹소켓(Socket 경유)을 사용하는 작은 웹게임이 있습니다.IO) (http://minibman.com)

그것들은 의미론적으로 다르다.

websocket은 "양방향 데이터 스트림"의 네이티브 의미입니다.

한편, sse는 "응답이 스트림임에도 불구하고" 또는 "요청 응답 패턴"의 네이티브 의미적 의미를 가집니다.

물론 웹 소켓을 통해 "pub-sub pattern" 또는 "req-res pattern" 레이어를 직접 구현할 수 있습니다.

2023년의 상황은 예전 같지 않다.

수년 전 IE가 여전히 상당한 시장 점유율을 차지하고 있었을 때 SSE의 한 가지 단점은 IE가 기본적으로 지원하지 않는다는 것이었습니다(WebSockets는 IE 10+에서 지원됨).caniuse.com에 따르면 현재 두 기술은 클라이언트 측에서 거의 동일하게 지원되고 있습니다. WebSockets의 98.35%와 SSE의 98.03%(이러한 통계는 글로벌 사용자를 위한 것입니다.

한 제한 중 제한 1의 경우 6의 경우 )yourapp.com많은 브라우저 탭에서 열림)은 이제 더 이상 문제가 되지 않습니다. 최신 브라우저는 모두 를 지원합니다.HTTP/2(글로벌 사용자의 97.16%) 및 서버 측HTTP/2+또, 을 웃돌아가다HTTP/1지난 몇 년 동안요

SSE와 WebSocket을 선택할 때는 다양한 사항을 고려해야 합니다.

• 한 SSE).curl을 이용하다)
• WebSockets는 양방향(전이중) 통신을 지원합니다.즉, 쌍방향 통신이 필요한 경우 SSE를 AJAX와 함께 사용할 수 있습니다.이러한 경우 WebSockets가 더 간단한 옵션이라고 하는 경우가 많지만, 이러한 일반화는 애플리케이션의 종류, 설계 방법 및 사용되는 기술에 따라 크게 달라지기 때문에 오해의 소지가 있다고 생각합니다.
• SSE는 UTF-8 문자 메시지만 지원하지만 WebSockets는 이진 데이터도 전송할 수 있습니다.
• 실용적인 관점에서 애플리케이션 서버가 각각의 기술을 얼마나 잘 지원하는지 조사할 것을 권장합니다.추가 모듈 및/또는 라이브러리에 의존하는 경우도 있습니다.예를 들어 간단한 PoC를 작성하는 것이 좋습니다.

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