팀프로젝트를 진행하면서 로그인, Oauth, 알림기능을 구현하였습니다.
알림기능을 구현하다보니 순간 실시간 알림이 있으면 좋겠는데?라는 생각을 하였고 실시간 알림을 구현하기 위한 방법이 여러개 있다는 것을 알게되었습니다.
여러개의 방법 중 저는 실시간 알림기능을 SSE를 사용해 구현하기로 했습니다.
그 이유는 알림같은경우는 알림이 발생했을 경우에만 해당 클라이언트에게 응답해주면 되는 단방향 소통이기 때문입니다.
요청이 필요 없기때문에 웹소켓을 사용하지 않았고, 서버에 Traffic을 생각해 polling방식을 사용하지 않았습니다.
그럼 실시간 알림을 구현하는 방법들을 알아봅시다.
💡 실시간 알림 구현방법
1. polling
실시간을 흉내내는 방식입니다.
클라이언트가 일정한 시간마다 request 요청을 보내 실시간을 모방합니다.
구현 난이도는 낮지만, 클라이언트가 주기적으로 request를 보내기 때문에 클라이언트가 많아져 request가 많아진다면 당연히 서버의 부담이 높아져 Traffic이 발생합니다.
또한 실시간이라고 하기에도 애매한것이 request의 주기마다 업데이트되기 때문에 실시간이라고도 할 수 없습니다.
2. long polling
Long Polling은 Polling 방식의 단점인 부족한 실시간성을 보완할 수 있는 기법입니다.
클라이언트가 request를 보내고 서버에서 reponse가 올때까지 기다리다 reponse를 받고 바로 request를 보냅니다.
polling방식보다는 서버의 부담이 줄지만 request의 시간간격이 좁다면 polling과 별 차이가 없어 클라이언트가 많아진다면
서버의 부담이 높아져 Traffic이 발생합니다.
Web Browser에서 Server의 Event를 하나 받기 위해서는 Web Browser의 요청 과정이 반드시 필요하기 때문에 Server
의 Event가 자주 발생하면 비효율적인 Traffic 낭비가 발생할 수 있습니다. 따라서 Long Polling은 Server의 Event가 자주 발생하지 않는 환경에서 이용해야 합니다.
3. Websoket
WebSocket은 Web Browser와 Server 사이의 양방향 실시간 통신을 지원하는 기법입니다.
Web Browser와 Server는 Handshake 과정에서는 HTTP Protocol을 이용하지만,
HTTP Upgrade Protocol을 통해 HTTP Procotol -> WebSocket Protocol로 전환후에는
HTTP Protocol을 이용하지 않고, WebSocket Protocol만 이용합니다.
즉, 첫 연결만 HTTP Protocol을 사용하고 그 이후에는 WebSocket Protocol을 사용합니다.
WebSocket은 Server-sent Events에 비교하면 양방향 실시간 통신을 지원한다는 점과, Server-sent Events에 비해서 좀
더 많은 Web Browser에서 지원한다는 장점이 있습니다.
하지만 Message, Event를 주고 받을때는 HTTP Protocol을 이용하지 않기 때문에 Firewall 정책으로부터 좀더 제한된다
는 단점도 가지고 있습니다.
비용
👉 Websoket은 SSE보다 배터리 소모량이 큽니다.
4. Server-sent Events
Server-sent Events 기법은 Web Browser의 간섭없이
Server에서 Web Browser 단방향으로 Event를 전송하는 기법입니다.
💡 HTML5 표준안입니다.
Web Browser는 Server에게 특정 Event를 Subscribe하는 요청 전송하고.
이후에 Server에서는 해당 Event가 발생시 Web Browser에게 해당 Event를 전송합니다.
Server-sent Events는 WebSocket과 비교하면 Event Subscribe에 특화되어 있습니다.
단방향 통신만 지원하지만 각 Event를 Event ID를 통해 관리하고,
Network 장애시 Reconnection 과정도 WebSocket에 비해서 잘 정의되어 있습니다.
또한 HTTP Protocol 기반이기 때문에 WebSocket에 비해서
Firewall 정책으로부터 좀더 자유로운 장점도 가지고 있습니다.
비용
👉 SSE는 Websoket보다 배터리 소모량이 적습니다.
정리
앞서 말했듯이 실시간 알림기능은 SSE를 사용하기로 하였습니다.
추가적으로 소켓은 서버와 연결이 끈겼을 때 자동으로 연결해주는 기능이 없기 때문에
스스로 코드를 짜야되지만 서버사이드 이벤트 같은 경우에는 자동으로 3초마다 한 번씩 확인을 합니다.
채팅처럼 실시간 양방향 데이터 통신이 필요할 경우 websoket을 사용해야 겠다는 생각이 들었습니다.
참고
🌐 Polling / Long Polling / Server Sent Event / WebSocket 정리
서버의 event를 클라이언트로 보내는 4가지 방법 polling 클라이언트가 평범한 http request를 서버로 계속 날려서 이벤트 내용을 전달받는 방식이다. 가장 쉬운방법이지만 클라이언트가 계속적으로 re
inpa.tistory.com
Web Polling, Long Polling, Server-sent Events, WebSocket
Web Browser와 Server 사이에서 여전하 가장 많잉 이용되는 HTTP/1.1 Procotol은 Web Browser (Client)가 먼저 Server에세 요청을 전달하면 Server가 요청에 대한 응답을 전송하는 단방향 Protocol이다. 이러한 제한된
ssup2.github.io
'Project > 팀프로젝트 - 운동메이트' 카테고리의 다른 글
[Refectoring] Sse를 Strategy Pattern -> 컴포넌트(Bean)으로 리펙토링! (0) | 2023.09.19 |
---|---|
[Refectoring] Sse로직을 재사용을 해보자 (Static, 메소드 오버로딩(overloading)) (0) | 2023.09.09 |
팀프로젝트를 진행하면서 로그인, Oauth, 알림기능을 구현하였습니다.
알림기능을 구현하다보니 순간 실시간 알림이 있으면 좋겠는데?라는 생각을 하였고 실시간 알림을 구현하기 위한 방법이 여러개 있다는 것을 알게되었습니다.
여러개의 방법 중 저는 실시간 알림기능을 SSE를 사용해 구현하기로 했습니다.
그 이유는 알림같은경우는 알림이 발생했을 경우에만 해당 클라이언트에게 응답해주면 되는 단방향 소통이기 때문입니다.
요청이 필요 없기때문에 웹소켓을 사용하지 않았고, 서버에 Traffic을 생각해 polling방식을 사용하지 않았습니다.
그럼 실시간 알림을 구현하는 방법들을 알아봅시다.
💡 실시간 알림 구현방법
1. polling
실시간을 흉내내는 방식입니다.
클라이언트가 일정한 시간마다 request 요청을 보내 실시간을 모방합니다.
구현 난이도는 낮지만, 클라이언트가 주기적으로 request를 보내기 때문에 클라이언트가 많아져 request가 많아진다면 당연히 서버의 부담이 높아져 Traffic이 발생합니다.
또한 실시간이라고 하기에도 애매한것이 request의 주기마다 업데이트되기 때문에 실시간이라고도 할 수 없습니다.
2. long polling
Long Polling은 Polling 방식의 단점인 부족한 실시간성을 보완할 수 있는 기법입니다.
클라이언트가 request를 보내고 서버에서 reponse가 올때까지 기다리다 reponse를 받고 바로 request를 보냅니다.
polling방식보다는 서버의 부담이 줄지만 request의 시간간격이 좁다면 polling과 별 차이가 없어 클라이언트가 많아진다면
서버의 부담이 높아져 Traffic이 발생합니다.
Web Browser에서 Server의 Event를 하나 받기 위해서는 Web Browser의 요청 과정이 반드시 필요하기 때문에 Server
의 Event가 자주 발생하면 비효율적인 Traffic 낭비가 발생할 수 있습니다. 따라서 Long Polling은 Server의 Event가 자주 발생하지 않는 환경에서 이용해야 합니다.
3. Websoket
WebSocket은 Web Browser와 Server 사이의 양방향 실시간 통신을 지원하는 기법입니다.
Web Browser와 Server는 Handshake 과정에서는 HTTP Protocol을 이용하지만,
HTTP Upgrade Protocol을 통해 HTTP Procotol -> WebSocket Protocol로 전환후에는
HTTP Protocol을 이용하지 않고, WebSocket Protocol만 이용합니다.
즉, 첫 연결만 HTTP Protocol을 사용하고 그 이후에는 WebSocket Protocol을 사용합니다.
WebSocket은 Server-sent Events에 비교하면 양방향 실시간 통신을 지원한다는 점과, Server-sent Events에 비해서 좀
더 많은 Web Browser에서 지원한다는 장점이 있습니다.
하지만 Message, Event를 주고 받을때는 HTTP Protocol을 이용하지 않기 때문에 Firewall 정책으로부터 좀더 제한된다
는 단점도 가지고 있습니다.
비용
👉 Websoket은 SSE보다 배터리 소모량이 큽니다.
4. Server-sent Events
Server-sent Events 기법은 Web Browser의 간섭없이
Server에서 Web Browser 단방향으로 Event를 전송하는 기법입니다.
💡 HTML5 표준안입니다.
Web Browser는 Server에게 특정 Event를 Subscribe하는 요청 전송하고.
이후에 Server에서는 해당 Event가 발생시 Web Browser에게 해당 Event를 전송합니다.
Server-sent Events는 WebSocket과 비교하면 Event Subscribe에 특화되어 있습니다.
단방향 통신만 지원하지만 각 Event를 Event ID를 통해 관리하고,
Network 장애시 Reconnection 과정도 WebSocket에 비해서 잘 정의되어 있습니다.
또한 HTTP Protocol 기반이기 때문에 WebSocket에 비해서
Firewall 정책으로부터 좀더 자유로운 장점도 가지고 있습니다.
비용
👉 SSE는 Websoket보다 배터리 소모량이 적습니다.
정리
앞서 말했듯이 실시간 알림기능은 SSE를 사용하기로 하였습니다.
추가적으로 소켓은 서버와 연결이 끈겼을 때 자동으로 연결해주는 기능이 없기 때문에
스스로 코드를 짜야되지만 서버사이드 이벤트 같은 경우에는 자동으로 3초마다 한 번씩 확인을 합니다.
채팅처럼 실시간 양방향 데이터 통신이 필요할 경우 websoket을 사용해야 겠다는 생각이 들었습니다.
참고
🌐 Polling / Long Polling / Server Sent Event / WebSocket 정리
서버의 event를 클라이언트로 보내는 4가지 방법 polling 클라이언트가 평범한 http request를 서버로 계속 날려서 이벤트 내용을 전달받는 방식이다. 가장 쉬운방법이지만 클라이언트가 계속적으로 re
inpa.tistory.com
Web Polling, Long Polling, Server-sent Events, WebSocket
Web Browser와 Server 사이에서 여전하 가장 많잉 이용되는 HTTP/1.1 Procotol은 Web Browser (Client)가 먼저 Server에세 요청을 전달하면 Server가 요청에 대한 응답을 전송하는 단방향 Protocol이다. 이러한 제한된
ssup2.github.io
'Project > 팀프로젝트 - 운동메이트' 카테고리의 다른 글
[Refectoring] Sse를 Strategy Pattern -> 컴포넌트(Bean)으로 리펙토링! (0) | 2023.09.19 |
---|---|
[Refectoring] Sse로직을 재사용을 해보자 (Static, 메소드 오버로딩(overloading)) (0) | 2023.09.09 |