집콕 🏠 SSE : Server-Sent-Events

들어가기에 앞서,

기존에 진행하던 비대면 모임 서비스 프로젝트에 모임 관련 알림들을 받을 수 있는 기능을 추가하기로 했어요. 알림 기능을 기획하면서 어떤 기술을 이용할지 논의하고 결정하는 과정에서 공부했던 내용들을 기록해보고자 합니다.

어려운 결정은 아니었지만, sse와 같이 많이 언급되는 web socket과의 차이점도 함께 살펴보면 좋을 것 같아요.

📍 Server-Sent-Events란 ?

서버가 클라이언트에게 단방향으로 이벤트를 지속적으로 전송할 수 있는 통신 방식

      · 단방향 통신 지원 : 서버에서 클라이언트로만 데이터 전송 가능
      · 자동 재연결 기능 : 연결이 끊어져도 클라이언트가 자동으로 다시 연결
      · 이벤트 기반 메시지 처리 : 특정 이벤트에 대한 데이터 전송 가능
      · 기존 HTTP 프로토콜 사용 : WebSockets와 달리 새로운 프로토콜을 요구하지 않음

📍 WebSocket 이란 ?

클라이언트와 서버 간에 양방향 통신을 가능하게 하는 프로토콜

      · 양방향 통신 지원 : 서버와 클라이언트가 데이터를 주고받을 수 있음.
      · Full-Duplex : 동시에 데이터를 송수신 가능
      · Connection Persistence : 한 번 연결되면 지속적인 데이터 교환 가능
      · 바이너리 데이터 지원 : JSON, 텍스트뿐만 아니라 이미지, 오디오, 비디오 전송 가능

SSE vs. WebSocket

구분	SSE	WebSocket
통신 방향	단방향 (서버 → 클라이언트)	양방향
프로토콜	HTTP 기반	별도 프로토콜
구현 난이도	비교적 단순	상대적으로 복잡
재연결 처리	브라우저 기본 지원	직접 구현 필요
주요 사용 사례	알림, 실시간 업데이트	채팅, 실시간 협업

기획했던 알림 기능의 경우 각 계정마다 알림이 쌓이는 형식으로, 단방향 전송만 필요한 상황이었기 때문에 구현 난이도가 비교적 낮은 편이고 단방향 송수신에 특화되어있는 sse가 더 적합하다는 결론을 내리게 되었어요!

Short Polling

클라이언트가 일정한 주기로 서버에 요청을 보내고, 서버가 즉시 응답하는 방식

short_polling

요청이 올 때마다 서버는 새로운 데이터가 있는지 확인한 후 응답을 반환해요. 구현은 단순하지만, 데이터가 없어도 반복적으로 요청이 발생하여 서버 요청수가 필요이상으로 많아진다는 단점이 있습니다. 즉, HTTP overhead가 증가하게 되는거죠. 이를 개선한 방법으로 Long Polling 개념이 나오게 되었습니다.

Long Polling

클라이언트가 요청을 보내면 서버가 즉시 응답하지 않고 이벤트가 발생할 때까지 대기하는 방식

long_polling

이벤트가 발생하면 서버는 응답을 반환하고, 클라이언트는 다시 요청을 보내 연결을 유지해요. 이런 방식은 Short Polling 대비 불필요한 요청 수를 줄여 HTTP overhead가 감소한다는 장점이 있습니다. 하지만 매번 연결을 새로 맺어야 하므로 여전히 비효율이 존재했어요..

SSE

반복적인 polling 요청 없이, 서버가 연결을 유지하며 이벤트 발생 시 클라이언트로 데이터를 전달하는 방식

sse

SSE는 이러한 Polling 방식의 한계를 개선하기 위해 등장하게 됐어요. 클라이언트가 한 번 요청을 보내면 서버는 연결을 유지한 채 지속적으로 데이터를 전송하게 돼요. 불필요한 재요청 없이 실시간 데이터를 전달할 수 있어 네트워크 효율이 높습니다. HTTP 프로토콜 기반이기 때문에 기존 인프라와도 잘 어울린다는 장점이 있어요.

SSE 로직

SSE는 브라우저에서 EventSource 객체를 통해 사용하게 됩니다!

📍 EventSource 란 ?

SSE 연결을 편리하게 할 수 있도록 해주는 Web API

        1. GET 요청입니다.
        2. 연결이 끊기면 자동으로 다시 연결합니다.
        3. SSE 연결 요청시, header를 수정할 수 없습니다.

EventSource 인스턴스 생성

1
2
3
const eventSource = new EventSource('/api/notifications', {
withCredentials: true, // 쿠키 기반 인증
});

클라이언트는 SSE 엔드포인트로 EventSource를 생성하여 서버와 연결해요.
EventSource을 호출에 대한 응답을 받은 시점부터 서버와의 지속적인 연결이 유지되게 됩니다.

메세지 이벤트 수신

1
2
3
4
eventSource.onmessage = (event) => {
const data = JSON.parse(event.data);
console.log('새 알림 수신:', data);
}

서버에서 기본 이벤트를 전송하면 onmessage 이벤트가 호출해요.
이곳에서 수신한 데이터를 파싱하여 알림 목록 갱신 등의 UI 업데이트를 수행합니다.

에러 핸들링

1
2
3
eventSource.onerror = (error) => {
console.error('SSE 연결 오류 발생', error);
};

네트워크 오류나 서버 연결 문제 발생 시 호출해요.
필요에 따라 재연결 로직이나 사용자 안내 처리를 할 수 있습니다.

SSE 연결 종료

1
eventSource.close();

더 이상 이벤트를 수신할 필요가 없을 경우 연결을 종료해요.
컴포넌트 언마운트 시점이나 로그아웃 시점에 주로 사용됩니다.

그렇다면 실제 프로젝트에 어떻게 적용할 수 있을까요? 🧐

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// setMessage : SSE로 전달받은 메세지를 훅 외부에서 처리하는 로직
export function useNotificationSSE(setMessage) {

    useEffect(() => {
      const eventSource = new EventSource('/api/notifications/subscribe', {
        withCredentials: true,
    });
    eventSource.onmessage = (event) => {
        setMessage(JSON.parse(event.data));
    };
      return () => eventSource.close();
    }, [setMessage]);

}

EventSource 연결하는 로직을 Hook으로 분리해서 사용하면 좋을 것 같다는 생각이 들었어요.

setMessage를 외부에서 주입하도록 작성한 이유는 재사용성과 Hook의 책임을 명확히 하기 위함이었습니다.
Hook의 호출 위치에 따라 메세지를 처리하는 방식에 차이가 있을 수 있고, Hook의 책임을 SSE 연결을 제어하는 것으로 제한하게 되면 컴포넌트에서 나머지 처리 로직을 담당하게 되기 때문에 처리 로직을 수정하거나 디버깅하기 위해 Hook을 들여다 볼 필요가 없게 되기 때문이죠..

SSE의 흐름만 이해하고 있다면, 어렵지 않게 연결할 수 있을 것 같다는 생각이 듭니다 :)