Spring) 알림기능 개선(1) - HTTP, SSE, WebSocket

기존의 이메일 알림기능을 개선하기 위해 여러가지 통신방식을 비교해보고자 한다. 

먼저 전통적인 상호작용 어플리케이션은 http요청을 통해 이루어진다.

http요청은 응답을 하게 된다면 연결을 끊는 비연결성과 상태를 보존하지 않아 리소스를 줄일 수 있지만

서버로부터 응답을 받기 위해서는 크라이언트의 요청이 필수적이다. 따라서 실시간 알림기능을 구현하기 위해서는 

조금은 억지스러운 방법을 사용해야한다.

 

short polling

기존 사이트에서 사용하는 방식이다. 클라이언트가 일정시간마다 서버에 요청을 보내 데이터가 갱신되었는지 확인하고 응답받는 방식이다. 이 방식을 사용하여 모니터링하였을 때 회사 전체 서비스 중 url호출량이 압도적으로 많은 것을 확인하였다. 그만큼 오버헤드가 많이 발생하였다.

- 요청 주기가 짧으면 서버의 부하가고 요청 주기가 길면 실시간성이 떨어진다

- 요청 주기를 길게 잡아도 부담이 되지 않는다면 고려할만한 방법이다.

ex)네이버 문자중계

 

long polling

 

요청을 보내고 서버에서 변경이 일어날 때까지 대기하는 방법이다. 클라이언트가 요청을 보내고 커넥션을 유지하다 트리거가 발생된다면 응답을 보내고, 클라이언트가 응답을 받으면 다시 요청을 보내는 방식이다. 커넥션 유지 시간을 잘 고려해야한다.

-트리거가 자주 발생된다면 short polling보다 서버에 부하를 줄수 있다.

ex) 소수 인원 채팅

 

 

websocekt

위의 http 방식들은 기본적으로 요청을 통해 응답을 받을 수 있기 때문에 필연적으로 오버헤드가 발생한다. 이러한 단점을 보완하기 위해 나온 것이 웹소켓이다.

웹소켓은 http와 같은 컴퓨터 통신 프로토콜이다. 실시간 서비스를 구현하기 적합하며 http가 요청과 응답을 통해 통신을 했다면 웹소켓은 양 방향통신이 가능하여 실시간으로 요청과 응답이 가능해진다.

 

-최초 웹소켓 연결을 위해 http 통신으로 요청을 한다.

- handshake과정이 이루어지고 이후 양방향통신이 가능해진다. 

- 최초 1회 연결이된다면 같은 라인을 사용하기 때문에 오버헤드를 줄일 수 있다.

- 무겁고 배터리 소모량이 크다.

ex)게임, 주식차트, 채팅

 

sse(Server-Sent-Events)

 

서버와 한번 연결을 맺고나면 일정 시간동안 서버에서 변경이 발생할 때마다 데이터를 전송받는 방법이다. 기존의 http프로토콜을 사용하고 서버에 연결되어 있기 때문에 실시간데이터 전송이가능하다. 

 

 

결론)

- 기존의 short polling은 서버에 부담이 크다.

- 이메일 알림 특성상 long polling은 short polling보다 효율적이지만 클라이언트가 응답을 받을 때마다 요청을 해야하므로 overhead가 지속적으로 발생하게 된다.

- 양방향 통신이 필요하다면 웹소켓을 고려해볼만 하겠지만 알림같은 경우 클라이언트가 요청하면 서버에서 데이터를 일방적으로 보내주는 형태이고 무겁다.

- sse 방식은 또한 기존의 http 프로토콜을 사용하기 때문에 특별한 프로토콜이나 서버구현이 필요하지 않다.

 

따라서 sse방식으로 이메일 알림기능을 구현하고자 한다. 

 

고려사항 :

1. 접속에 문제가 있으면 자동으로 재연결을 시도하지만 클라이언트가 페이지를 닫아도 서버에서 감지하기가 어렵다.

2. HTTP/1.1의 경우 브라우저당 6개의 접속만을 허가하며 HTTP/2에서는 100개까지의 접속을 허용한다.

 

https://tecoble.techcourse.co.kr/post/2022-10-11-server-sent-events/

https://www.oowgnoj.dev/post/network-websocket