[TIL] SSE로 알람기능 구현하기 (Polling / Long Polling / Web Socket / SSE (Server Sent Event))

 

SSE를 이용해서 알림기능 구현하기

실시간으로 데이터를 업데이트 해야하는 경우에는 서버로부터 데이터를 받아와야한다.
이때는 사용할 수 있는 기술로는

1.Polling / Long Polling
2.WebSocket 
3.SSE

와 같은 것들이 있다.

 

Polling 기법

클라이언트에서 서버로 주기적, 반복적으로 HTTP 요청을 보내는 것.
주기적으로 요청을 보내다보면 만약 데이터에 변동사항이 생겼을 때 이를 확인하고 받아올 수 있음.
요청하는데 부담이 크지않거나, 요청주기를 길게 잡아도 될만큼 실시간성이 중요하지않거나, 데이터 갱신이 특정 주기를 가질 때 적합하다. 


장점:
구현이 단순하다


단점:
Http Overhead 발생
(계속 http 요청을 보내야하기 때문에 리소스 낭비가 발생한다. 
요청 주기가 짧다면 http요청이 많아져서 리소스 낭비커짐.
요청 주기가 길다면 데이터 변동사항이 생기고 이를 반영하기까지 다음 요청 주기까지 지연되는 문제가 발생한다.)

클라이언트가 많아지면 서버 부담 급증.


사용예시:
주기적으로 갱신되는 서버 데이터

-Http Overhead

정보의 신뢰성 판단을 위한 헤더 같은 정보 떄문에 오히려 데이터량이나 처리시간이 증가하는 것.

Long Polling

유지 시간을 더 길게 가진다는 점에서 Polling 기법과 차이가 있다.
즉, 요청을 보내고 서버에서 변동이 일어날 때까지 대기하는 방법
처음에 Connection이 긴 요청을 보내고, 이 지속시간동안은 실시간으로 이벤트가 감지할 수 있다.

이벤트 감지를 감지하고 나면 기존의 Connection이 닫히기 때문에 새로 연결 http요청을 보내야 한다.
이벤트가 자주 발생하면 부담이 되기때문에 실시간 전달이 중요한데 상태가 빈번하게 갱신되지 않을 때 적합하다.

 

장점: 
실시간으로 변동사항을 감지할 수 있음.
빈번한 요청이 필요없기 때문에 부담이 덜함 

 

단점:
변동사항이 빈번하게 발생하는 경우 서버 부담이 커짐. (요청-응답주기 반복)
연결 유지시간이 짧아진다면 Polling 방식과 다를게 없다.
연결 유지시간이 길다면 지속적으로 연결되어있기 때문에 다수의 클라이언트에게 동시에 이벤트가 발생하면 순간적 부담이 급증한다. 

WebSocket

서버와 클라이언트가 양방향 통신이 가능하다.
<서버->클라이언트>와 <클라이언트->서버> 양방향으로의 데이터 전송이 필요한 경우 사용한다.
실시간 상호작용이 필요한 경우에 사용.

최초 접속만 http요청을 이용한 3-way-handShaking 으로 이루어짐.
이후에는 Connection을 유지하여 연결에 필요한 불필요한 비용을 제거할 수 있다. 
연결할때는 용량이 큰 http header를 보내야하는데 이를 최초 접속시에만 보내고 더이상 보내지 않으므로 리소스면에서 이득을 볼 수 있다.
웹소켓 포트에 접속해있는 모든 클라이언트에게 이벤트 방식으로 응답할 수 있음.


장점:
양방향통신
실시간 상호작용에 유리함

단점:
별도의 프로토콜과 웹소켓 서버가 필요함.(구현비용이 많이든다)
재연결 기능을 기본제공하지 않음. 

사용예시:
온라인 게임
실시간 채팅
실시간 주식 차트

 

-Socket.io

Node.js 기반으로 만들어진 기술로 socket.io 서버를 만들고 socket.io 클라이언트와 브라우저에 구애받지 않고 실시간 통신이 가능해진다.

SSE(Server-Sent-Event)

클라이언트가 서버로부터 일방적으로 데이터를 받을때 사용하는 기술.
<서버->클라이언트>의 단방향으로 서버의 이벤트나 메시지를 클라이언트로 보내는 경우 사용된다.
HTML5 표준문서에 정의되어있음. (MDN웹사이트에 사용법 확인)

 

작동방식:
1.클라이언트가 서버에 SSE통신 http 요청을 보낸다.
2.서버가 클라이언트에게 SSE통신 수락 응답보냄.
3.이벤트 발생할때마다 클라이언트에게 메시지보냄.(클라이언트는 응답불가)
4.하나의 연결안에서 이 과정들이 이뤄지고, 연결이 끊긴다면 클라이언트가 자동으로 재연결 요청하여 통신 재개
5.작업이 끝나면 요청 중단 통보 메시지를 상대방에게 보내고 연결 중단.

장점: 
별도의 프로토콜, 서버가 필요없음.(구현 비용 적다)
HTTP기반이라 방화벽에도 친화적이다.(기존의 80, 443포트를 그대로 이용가능하다)
접속에 문제 생기면, 재연결 자동으로 주어짐
웹소켓과 달리 로드밸런싱이 되어있는 환경에서도 문제없음.
프록시환경에서도 추가작업 없음.

단점:
단방향 통신만 가능
클라이언트에서 close해도 서버에서 감지하기 어려움.


사용예시:
알림 기능

 

 

-하나의 연결을 유지하는 것이 중요한 이유

서버에서 큰 부담을 받지않고 지속적으로 이루어질 수 있기 때문이다.
http 오버헤드 발생하지않음.

 

 

SSE를 사용해야하는 이유

 

실시간 알림 기능은 
1. 서버에서 클라이언트로 데이터를 전송해야함
2. 클라이언트에서 서버로 데이터를 전송할 필요없음.
3. 실시간 기능이 필요함

실시간성이 필요하므로 Polling, Long Polling 방식은 적합하지 않고, <서버 -> 클라이언트>의 단방향 통신만 필요하므로, 구현비용이 많이드는 웹소켓기술보다 SSE가 적합하다고 판단하였다.





SSE구현




참고문헌
https://velog.io/@alswn9938/SSE%EB%9E%80
https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-Polling-Long-Polling-Server-Sent-Event-WebSocket-%EC%9A%94%EC%95%BD-%EC%A0%95%EB%A6%AC