SSE (Server-Sent Events)

노준혁·2023년 6월 19일

SSE 개요

HTTP 프로토콜의 주요 특징 중 하나는 ‘비연결성’ → 서버가 데이터를 전송하고 싶어도 클라이언트와 연결되어 있지 않으면 보낼 수 없다는 단점이 있음. → 즉, REST 아키텍처에서 클라이언트와 서버 간의 통신은 Stateless
Server-Sent Events는 대화형 작업이 필요하지 않은 실시간 데이터를 처리할 때 유용
‘업데이트 수신 대기’로 설명할 수 있는 모든 시나리오에 적합

          <이미지 출처 : https://www.pubnub.com/learn/glossary/what-are-server-sent-events/ >

폴링 혹은 롱 폴링은 일단 데이터 송수신을 원할 때 Requset 즉, 연결을 시작하는 과정이 필요하지만, SSE는 일단 연결이 되면 스트리밍 방식으로 EVENT를 읽어들일 수 있다.

SSE (server-sent-events), 폴링, 롱 폴링, 소켓 4가지 방법 중 본 글에서는 SSE에 대해 다룬다.
Server-Sent Events의 약자로, 서버가 클라이언트에게 비동기적으로 정보를 폴링하지 않고 데이터를 푸시하는 방법
SSE는 HTTP 프로토콜을 사용하여 단방향 통신을 가능하게 하며, 주로 서버에서의 실시간 업데이트를 클라이언트에게 전송하는 데 사용됨.
클라이언트가 서버로부터 데이터만 읽기 전용처럼 받을 수 있게 하는 방식
클라이언트와 서버 간에 초기 연결이 설정되면 메시지를 클라이언트로 스트리밍할 수 있지만 연결은 한 방향으로만 작동하므로 메시지를 서버로 다시 스트리밍할 수 없음.

웹소켓은 양방향, 전이중 통신을 수행할 수 있기에 SSE에 비해 더 풍부한 프로토콜을 제공할 수 있다는 측면에서 SSE보다 웹소켓이 모든 상황에서 좋다고 생각할 수 있다.
물론 게임, 채팅 앱 같이 웹소켓이 유용한 시나리오가 있지만, 클라이언트에서 데이터를 더이상 전송할 필요가 없는 경우, 이러한 웹소켓 프로토콜은 비효율적이다.
SSE는 기존 HTTP를 통해 전송된다. 즉, 필요하는 작업을 수행함에 있어 웹소켓과 달리 특별한 프로토콜 처리 혹은 서버 측면에서의 또 다른 서버 구현이 필요하지 않다. 또한, 기존 웹 인프라와 쉽게 호환된다는 장점이 있다.
SSE는 자동 재연결 기능을 제공한다. 네트워크 불안정이나 일시적인 연결 문제를 겪을 때 유용하다. 이는 웹소켓에서는 처리하지 못하는 기능이다.
SSE는 HTTP 연결을 유지하는 데 WebSocket에 비해 더 적은 서버 자원을 사용한다. 이는 많은 수의 연결을 유지해야 하는 대규모 시스템에서 중요.

HTTP 기반:
1. SSE는 기본적으로 HTTP를 사용하기에 별도의 프로토콜을 사용할 필요 없음. → 구현이 용이함.
2. 기존의 인프라와 호환성을 유지→ 방화벽이나 프록시 문제를 크게 고려하지 않아도 됨.
단방향 통신:

서버에서 클라이언트로만 데이터를 전송할 수 있습니다. 클라이언트가 서버에 데이터를 보내려면 별도의 방법(예: AJAX)을 사용해야 함.
자동 재연결:

클라이언트와 서버 사이의 연결이 끊어진 경우, 클라이언트는 자동으로 서버에 재연결을 시도한다. → 네트워크 불안정성을 대응하는 데 유용.
실시간 업데이트:

서버에서 발생하는 실시간 이벤트나 업데이트를 클라이언트에게 즉시 알릴 수 있음.

이는 주식 시세, 채팅 알림 등 다양한 애플리케이션에서 유용하게 사용된다.

          <이미지 출처 : https://www.pubnub.com/learn/glossary/what-are-server-sent-events/ >

https://github.com/nohjunh